Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

New ONC Scorecard Tool Grades C-CDA Documents

Posted on August 2, 2016 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

The ONC has released a new scorecard tool which helps providers and developers find and resolve interoperability problems with C-CDA documents. According to HealthDataManagement, C-CDA docs that score well are coded with appropriate structure and semantics under HL7, and so have a better chance of being parseable by different systems.

The scorecard tool, which can be found here, actually offers two different types of scores for C-CDA documents, which must be uploaded to the site to be analyzed. One score diagnoses whether the document meets the requirements of the 2015 Edition Health IT Certification for Transitions of Care, granting a pass/fail grade. The other score, which is awarded as a letter grade ranging from A+ to D, is based on a set of enhanced interoperability rules developed by HL7.

The C-CDA scorecard takes advantage of the work done to develop SMART (Substitutable Medical Apps Resusable Technologies). SMART leverages FHIR, which is intended to make it simpler for app developers to access data and for EMR vendors to develop an API for this purpose. The scorecard, which leverages open-source technology, focuses on C-CDA 2.1 documents.

The SMART C-CDA scorecard was designed to promote best practices in C-CDA implementation by helping creators figure out how well and how often they follow best practices. The idea is also to highlight improvements that can be made right away (a welcome approach in a world where improvement can be elusive and even hard to define).

As SMART backers note, existing C-CDA validation tools like the Transport Testing Tool provided by NIST and Mode-Driven Health Tools, offer a comprehensive analysis of syntactic conformance to C-CDA specs, but don’t promote higher-level best practices. The new scorecard is intended to close this gap.

In case developers and providers have HIPAA concerns, the ONC makes a point of letting users know that the scorecard tool doesn’t retain submitted C-CDA files, and actually deletes them from the server after the files have been processed. That being said, ONC leaders still suggest that submitters not include any PHI or personally-identifiable information in the scorecards they have analyzed.

Checking up on C-CDA validity is becoming increasingly important, as this format is being used far more often than one might expect. For example, according to a story appearing last year in Modern Healthcare:

  • Epic customers shared 10.2 million C-CDA documents in March 2015, including 1.3 million outside the Epic ecosystem (non-Epic EMRs, HIEs and the health systems for the Defense and Veterans Affairs Departments)
  • Cerner customers sent 7.3 million C-CDA docs that month, more than half of which were consumed by non-Cerner systems.
  • Athenahealth customers sent about 117,000 C-CDA documents directly to other doctors during the first quarter of 2015.

Critics note that it’s still not clear how useful C-CDA information is to care, nor how often these documents are shared relative to the absolute number of patient visits. Still, even if the jury is still out on their benefits, it certainly makes sense to get C-CDA docs right if they’re going to be transmitted this often.

Experiences Crafting a New API at Amazing Charts

Posted on August 21, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site ( and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

A couple months ago, Amazing Charts announced an upcoming API for their new electronic health record, InLight. Like athenahealth, whose API I recently covered, Amazing Charts is Software as a Service (SaaS), offering its new EHR on the Web.

The impetus toward an API wasn’t faddish for Amazing Charts; they had a clear vision of what they wanted to achieve by doing so. They found that their interactions with various health care providers–payers, labs, radiologists, and others, along with accepting medical device data–has been hampered by reliance on common standards that involve HL7 messaging and EDI. The HL7 standards are inconsistently implemented and EDI is non-standardized, so each interface requires weeks of work.

I talked to Prayag Patil, product manager of patient engagement solutions at Amazing Charts. (They also offer patient portals to the institutions they serve.) For all their data exchanges, he said, they expect a RESTful API to provide standardization, speed, and simplicity in implementation. It should also be more suited to quick, fine-grained data transfers.

One of the common complaints of the older HL7 standards such as the CCD-A is that they are monolithic. EHR vendors and healthcare providers shove a lot into them without deciding what the recipient really needs. As Patil says, “it makes the 80% use case hard to do.” Nor is the standard used consistently by all correspondents (labs, practice management systems, devices, etc.), so extracting what’s really important at the receiving end is harder.

They’ve found that sluggish exchange has real effects on patient safety. For instance, a set of lab results, medications, and other information from a hospital discharge should be available immediately. If you wait, the patient their primary care provider won’t have it just after discharged, when its value is often critical, and the patient might lose interest and not bother to look at it later.

Amazing Charts, like athenahealth, also recognizes the value of a third-party marketplace. Patil says that innovation tends to “come from the smaller, scrappier vendors” that are enabled to produce useful apps by open APIs. The company already has a third party marketplace for apps in care coordination, revenue cycle management, patient engagement, and other tasks. But up to now the APIs weren’t published, so their developers had to work individually with any vendor who came to them, offering tools and the help needed to integrate with Amazing Charts’ service.

The company plans to introduce a patient engagement platform that will be open and accessible, with a focus on using standardized RESTful APIs to enable third party app developers to offer solutions. The company also plans to increase participation by creating thorough documentation for the APIs, and standardizing them. They are looking forward to standards such as FHIR, SMART-on-FHIR, and OpenID/OAuth, which are better specified and more consistently implemented than the currently available interfaces.

Here are the lessons I draw for others who are looking enviously at projects with APIs: going forward without all the pieces in place will be like driving on one flat tire. You just won’t get the results that you hoped for when investing in the project.

I applaud Amazing Charts for taking the difficult first steps toward API access, and doing it with good goals in mind. Their experience shows that an open API is still a hard process to get going–even as more and more companies take the leap–and one that calls for coordinated efforts throughout the organization in software design, publicity, documentation, and support.

Taking a New Look at the Lamented Personal Health Record: Flow Health’s Debut

Posted on June 8, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site ( and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

After the disappointing lack of adoption suffered by Google Health and Microsoft HealthVault, many observers declared personal health records (PHRs) a non-starter, while others predicted that any progress toward personal control over health data would require a radically new approach.

Several new stabs at a PHR are emerging, of which Flow Health shows several promising traits. The company tries to take advantage of–and boost the benefits of–advances in IT standards and payment models. This article is based on a conversation I had with their general counsel, David Harlow, who is widely recognized as the leading legal expert in health IT and health privacy and who consults with companies in those spaces through the Harlow Group.

Because records are collected by doctors, not patients, the chief hurdle any PHR has to overcome is to persuade the health care providers to relinquish sole control over the records they squirrel away in their local EHR silos. Harlow believes the shift to shared risk and coordinated care is creating the incentive for doctors to share. The Center for Medicare & Medicaid Services is promising to greatly increase the role of pay-for-value, and a number of private insurers have promised to do so as well. In short, Flow Health can make headway if the tangible benefit of learning about a patient’s recent hospital discharge or treating chronic conditions while the patient remains at home start to override the doctor’s perception that she can benefit by keeping the patient’s data away from competitors.

The next challenge is technically obtaining the records. This is facilitated first by the widespread move to electronic records (a legacy of Meaningful Use Stage 1) and the partial standardization of these records in the C-CDA. Flow Health recognizes both the C-CDA and Blue Button, as well as using the Direct protocol to obtain records. Harlow says that FHIR will be supported when the standard settles down.

But none of that is enough to offer Flow Health what the doctors and patients really want, which is a unified health record containing all the information given by different providers. Therefore, like other companies trying to broaden access to patient data, Flow Health must deal with the problem that Dr. Eric Topol recently termed the Tower of EMR Babel. They study each format produced by different popular EHRs (each one using the C-CDA in slightly incompatible ways) and convert the data into a harmonized format. This allows Flow Health to then reconcile records when a diagnosis, a medication list, or some other aspect of the patient’s health is represented differently in different records.

What’s next for Flow Health? Harlow said they are preparing an API to let third parties add powerful functionality, such as care coordination and patient access from any app of their choice. Flow Health is already working closely with payers and providers to address workflow challenges, thus accelerating the aggregation of patient health record data for access and use by clinicians and patients.

A relative of mine could have used something like Flow Health recently when her eye doctor referred her to the prestigious Lahey Clinic in the Boston area. First of all, the test that led to the referral had to be repeated at the Lahey Clinic, because the eye doctor did not forward test results. Nor did anyone provide a medication list, so the Lahey Clinic printed out a five-year old medication list that happened to hang around from a visit long ago and asked her to manually update it. There was also confusion about what her insurer would cover, but that’s a different matter. All this took place in 2015, in the country’s leading region for medical care.

It seems inevitable that–as Flow Health hopes–patients will come to demand access to their medical records. A slew of interesting experiments will proliferate, like Flow Health and the rather different vision of Medyear to treat health information like a social network feed. Patient-generated data, such as the output from fitness devices and home sensors, will put yet more pressure on health care providers to take the patient seriously as a source of information. And I’ll continue to follow developments.

Risk of Interoperability is Worse Data

Posted on July 17, 2014 I Written By

John Lynn is the Founder of the blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I’m a huge fan of healthcare interoperability. I think it needed to happen yesterday and that we could solve a number of our cost issues with healthcare data interoperability and we could save lives. Both of these are very worthy goals.

While I’m a huge fan of healthcare data interoperability, we also have to be careful that we do it right. While there are huge potential benefits of exchanging healthcare data, there are also huge risks involved in it as well. We have to address those risks so that interoperability doesn’t get a black eye because it was poorly implemented.

A great example of the potential risk of interoperability is making sure that we process and connect the data properly. Some might argue that this isn’t that big of an issue. Healthcare organizations have been doing this forever. They get a medical record faxed to their office and the HIM team lines up that medical record with the proper patient. I’m sure the medical records folks could tell us all sorts of stories about why matching a faxed medical record to a patient is a challenge and fraught with its own errors. However, for this discussion, let’s assume that the medical records folks are able to match the record to the patient. In reality, they’re certainly not perfect, but they do a really amazing job given the challenge.

Now let’s think about the process of matching records in an electronic world. Sure, we still have to align the incoming record with the right patient. That process is very similar to the faxed paper record world. For the most part, someone can take the record and attach it to the right patient like they did before. However, some EHR software are working to at least partially automate the process of attaching the records. In most cases this still involves some review and approval by a human and so it’s still very similar. At least it is similar until the human starts relying on the automated matching so much that they get lazy and don’t verify that it’s connecting the record to the correct patient. That’s the first challenge.

The other challenge in the electronic world is that EHR software is starting to import more than just a file attached to a patient record. With standards like CCDA, the EHR is going to import specific data elements into the patient record. There are plenty of ways these imported data elements could be screwed up. For example, what if it was a rule out diagnosis and it got imported as the actual diagnosis? What if the nurse providing care gets imported as a doctor? Considering the way these “standards” have been implemented, it’s not hard to see how an electronic exchange of health information runs the risk of bad health data in your system.

Some of you may remember my previous post highlighting how EMR perpetuates misinformation. If we import bad data into the EMR, the EMR will continue to perpetuate that misinformation for a long time. Now think about that in the context of a interoperable world. Not only will the bad data be perpetuated in one EMR system, but could be perpetuated across the healthcare system.

Posts like this remind me why we need to have the patient involved in their record. The best way to correct misinformation in your record is for the patient to be involved in their record. Although, they also need a way to update any misinformation as well.

I look forward to the day of healthcare data interoperability, but it definitely doesn’t come without its own risks.

Direct Messaging: The Logistics of Exchange

Posted on June 12, 2014 I Written By

Julie Maas is Founder and CEO of EMR Direct, a HISP (Health Information Service Provider) whose mission is to simplify interoperability in healthcare through the use of Direct messaging EHR integration and other applications. EMR Direct works with a large developer community to enable Direct for MU2 and other workflows using a custom, rapid-integration API that's part of the phiMail Direct Messaging platform. Julie is passionate about improving quality of care and software user experience, and manages ongoing interoperability testing within DirectTrust. Find Julie on Twitter @JulieWMaas.

Once you enable digital health data exchange via Direct instead of by fax, you’ll want to share your address with other providers, so you no longer have to deal with all those pesky scanned attachments, subtly linked to electronic patient records.

Direct directories are enabling address lookup to meet this need, and you can also let your most common business partners know your address by including it on document templates you already exchange today, so they can begin to exchange with you via Direct when they’re ready.  You can also contact your referring docs using another method you trust (such as the fax where you usually send them medical records, or their business phone number) to ask for their Direct address.

It’s wise to confirm expectations with exchange partners about the use cases/data payloads for which you intend to exchange via Direct, as Direct isn’t used just like email by everyone.  Some will use Direct solely for Transitions of Care and patient Transmit, others may use it for Secure Messaging with patients, and still other providers will be happy to conduct general professional correspondence with patients and other providers over Direct.  This service information may or may not be reflected in the first provider directories.  And even within the Transitions of Care use case, if standards aren’t implemented for optimal receiving, a sending system may generate a CCDA (Continuity of Care Document) with a subtly different structure than a receiving system is able to completely digest.  So, just a heads up as you receive your first message or two from a system with whom you haven’t exchanged before: you’ll want to carefully monitor what data is incorporated by the receiving system and what is not, and you may need to iterate slightly between sender and receiver to get the data consumption right.  You’ll still be miles ahead of the custom interfaces model.

All in all, Direct is easy to use and is working much better than the naysayers would have you believe.  Direct software follows the specification outlined in the document lovingly known in the industry as the “Applicability Statement”, crafted by consensus through a public/private collaborative effort known as the “Direct Project” and led by the Office of the National Coordinator of Health Information Technology (ONC).   Direct Project volunteers have also written reference implementations following this specification which have been used by many HISPs and EHRs as the basis for their own Direct offerings.  Other private entities have developed their own APIs and implementations of the protocol from scratch.  These different systems and varying configurations regularly test and collaborate with each other, to make Direct work as seamlessly as possible for the end users.  Because the whole system only works as well as our joint efforts, HISPs (Health Information Service Providers who provide Direct services) within the DirectTrust Network take interoperability seriously and work together to iron out any kinks.

A tremendous amount of collaboration is taking place to bring interoperability to fruition for Direct’s well-established standards and policies, and this work is producing a larger and more robust network each day.