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.