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!

Epic Launches FHIR-Based App Platform

Posted on March 2, 2017 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 FierceHealthcare.com 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.

It looks like Epic is getting on the FHIR train. According to an article in Modern Healthcare, Epic is launching a new program – serving physician practices and hospitals – to help them build customized apps. The program, App Orchard, will also support independent mobile app developers who target providers and patients.

The launch follows on the heels of a similar move by Cerner, which set up its own sandbox for developers interested in linking to its EMR using FHIR. The Cerner Open Developer Experience (code_), which launched in early 2016, is working with firms creating SMART on FHIR apps.

App Orchard, for its part, lets developers use a FHIR-based API to access an Epic development sandbox. This will allow the developers to address issues in connecting their apps to the Epic EMR. Previously, Epic wouldn’t let mobile app developers connect to its EMR until a customer requested permission on their behalf.

In addition to providing the API, App Orchard will also serve as an online marketplace along the lines of Google Play or the Apple app store. However, end users won’t be able to download the app for their own use — only software developers and vendors will be able to do that. The idea is that these developers will create the apps on contract to customers.

Meanwhile, according to the magazine, Epic will screen and pick an initial group of developers to the program. Brett Gann, who leads the Epic-based team developing App Orchard, told Modern Healthcare that factors which will distinguish one developer from the other include app safety, security, privacy, reliability, system integrity, data integrity and scalability.

As part of their participation, developers will get documentation listing these criteria and what they mean to Epic. The Epic team will expect the developers to commit to following these guidelines and explain how they’ll do so, Gann said.

While Epic hasn’t made any predictions about what types of apps developers will pursue, recent research offers a clue. According to new research by SMART and KLAS, providers are especially interested in apps that help with patient engagement, EMR data viewing, diagnostics, clinical decision support and documentation tasks.

One thing to watch is how Epic decides to handle licensing, ownership, and charges for participation in their Orchard Program. If they have a true open API, then this will be a good move for the industry. If instead they choose to take ownership of everything that’s created, put restrictive licenses on developers, and/or charge huge sums to participate, then it’s unlikely to see much true innovation that’s possible with an open API. We’ll see how that plays out.

Meanwhile, in other Epic news, Becker’s Hospital Review notes that the vendor is planning to develop two additional versions of its EMR. Adam Whitlatch, a lead developer there, told the site that the new versions will include a mid-range EMR with fewer modules (dubbed “utility”), and a slimmer version with fewer modules and advanced features, to be called “Sonnet.”

Whitlatch said the new versions will target physician practices and smaller hospitals, which might prefer a lower-cost EMR that can be implemented more quickly than the standard Epic product. It’s also worth noting that the two new EMR versions will be interoperable with the traditional Epic EMR (known as “all-terrain”).

All told, these are intriguing developments which could have an impact on the EMR industry as a whole.

On the one hand, not only is Epic supporting the movement towards interchangeable apps based on FHIR, it appears that the vendor has decided to give in to the inevitable and started to open up its platform (something it hasn’t done willingly in the past).  Over time, this could affect providers’ overall Epic development plans if Epic executes it well and enables innovation on Orchard and doesn’t restrict it.

Also, the new versions of the Epic could make it available to a much wider audience, particularly if the stripped-down versions are significantly cheaper than its signature EMR. In fact, an affordable Epic EMR could trigger a big shakeup in the ambulatory EMR market.

Let’s see if more large EMR vendors decide to offer an open API. If access to EMR APIs became common, it would represent a major shift in the whole health IT ecosystem.

Switching Out EMRs For Broad-Based HIT Platforms

Posted on February 8, 2017 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 FierceHealthcare.com 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.

I’ve always enjoyed reading HISTalk, and today was no exception. This time, I came across a piece by a vendor-affiliated physician arguing that it’s time for providers to shift from isolated EMRs to broader, componentized health IT platforms. The piece, by Excelicare chief medical officer Toby Samo, MD, clearly serves his employer’s interests, but I still found the points he made to be worth discussing.

In his column, he notes that broad technical platforms, like those managed by Uber and Airbnb, have played a unique role in the industries they serve. And he contends that healthcare players would benefit from this approach. He envisions a kind of exchange allowing the use of multiple components by varied healthcare organizations, which could bring new relationships and possibilities.

“A platform is not just a technology,” he writes, “but also ‘a new business model that uses technology to connect people, organizations and resources in an interactive ecosystem.’”

He offers a long list of characteristics such a platform might have, including that it:

* Relies on apps and modules which can be reused to support varied projects and workflows
* Allows users to access workflows on smartphones and tablets as well as traditional PCs
* Presents the results of big data analytics processes in an accessible manner
* Includes an engine which allows clients to change workflows easily
* Lets users with proper security authorization to change templates and workflows on the fly
* Helps users identify, prioritize and address tasks
* Offers access to high-end clinical decision support tools, including artificial intelligence
* Provides a clean, easy-to-use interface validated by user experience experts

Now, the idea of shared, component-friendly platforms is not new. One example comes from the Healthcare Services Platform Consortium, which as of last August was working on a services-oriented architecture platform which will support a marketplace for interoperable healthcare applications. The HSPC offering will allow multiple providers to deliver different parts of a solution set rather than each having to develop their own complete solution. This is just one of what seem like scores of similar initiatives.

Excelicare, for its part, offers a cloud-based platform housing a clinical data repository. The company says its platform lets providers construct a patient-specific longitudinal health record on the fly by mining existing EHRs claims repositories and other data. This certainly seems like an interesting idea.

In all candor, my instinct is that these platforms need to be created by a neutral third party – such as travel information network SABRE – rather than connecting providers via a proprietary platform created by companies like Excelicare. Admittedly, I don’t have a deep understanding of Excelicare’s technology works, or how open its platform is, but I doubt it would be viable financially if it didn’t attempt to lock providers into its proprietary technology.

On the other hand, with no one interoperability approach having gained an unbeatable lead, one never knows what’s possible. Kudos to Samo and his colleagues for making an effort to advance the conversation around data sharing and collaboration.

Rival Interoperability Groups Connect To Share Health Data

Posted on December 27, 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 FierceHealthcare.com 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.

Two formerly competitive health data interoperability groups have agreed to work together to share data with each others’ members. CommonWell Health Alliance, which made waves when it included Cerner but not Epic in its membership, has agreed to share data with Carequality, of which Epic is a part. (Of course, Epic said that it chose not to participate in the former group, but let’s not get off track with inside baseball here!)

Anyway, CommonWell was founded in early 2013 by a group of six health IT vendors (Cerner, McKesson, Allscripts, athenahealth, Greenway Medical Technologies and RelayHealth.) Carequality, for its part, launched in January of this year, with Epic, eClinicalWorks, NextGen Healthcare and Surescripts on board.

Under the terms of the deal, the two will shake hands and play nicely together. The effort will seemingly be assisted by The Sequoia Project, the nonprofit parent under which Carequality operates.

The Sequoia Project brings plenty of experience to the table, as it operates eHealth Exchange, a national health information network. Its members include the AMA, Kaiser Permanente, CVS’s Minute Clinic, Walgreens and Surescripts, while CommonWell is largely vendor-focused.

As things stand, CommonWell runs a health data sharing network allowing for cross-vendor nationwide data exchange. Its services include patient ID management, record location and query/retrieve broker services which enable providers to locate multiple records for patient using a single query.

Carequality, for its part, offers a framework which supports interoperability between health data sharing network and service providers. Its members include payer networks, vendor networks, ACOs, personal health record and consumer services.

Going forward, CommonWell will allow its subscribers to share health information through directed queries with any Carequality participant.  Meanwhile, Carequality will create a version of the CommonWell record locator service and make it available to any of its providers.

Once the record-sharing agreement is fully implemented, it should have wide ranging effects. According to The Sequoia Project, CommonWell and Carequality participants cut across more than 90% of the acute EHR market, and nearly 60% of the ambulatory EHR market. Over 15,000 hospitals clinics and other healthcare providers are actively using the Carequality framework or CommonWell network.

But as with any interoperability project, the devil will be in the details. While cross-group cooperation sounds good, my guess is that it will take quite a while for both groups to roll out production versions of their new data sharing technologies.

It’s hard for me to imagine any scenario in which the two won’t engage in some internecine sniping over how to get this done. After all, people have a psychological investment in their chosen interoperability approach – so I’d be astonished if the two teams don’t have, let’s say, heated discussions over how to resolve their technical differences. After all, it’s human factors like these which always seem to slow other worthy efforts.

Still, on the whole I’d say that if it works, this deal is good for health IT. More cooperation is definitely better than less.

E-Patient Update: The Smart Medication Management Portal

Posted on December 16, 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 FierceHealthcare.com 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.

As I work to stay on top of my mix of chronic conditions, one thing that stands out to me is that providers expect me to do most of my own medication tracking and management. What I mean by this is that their relationship to my med regimen is fairly static, with important pieces of the puzzle shared between multiple providers. Ultimately, there’s little coordination between prescribers unless I make it happen.

I’ve actually had to warn doctors about interactions between my medications, even when those interactions are fairly well-known and just a Google search away online. And in other cases, specialists have only asked about medications relevant to their treatment plan and gotten impatient when I tried to provide the entire list of prescriptions.

Sure, my primary care provider has collected the complete list of my meds, and even gets a updates when I’ve been prescribed a new drug elsewhere. But given the complexity of my medical needs, I would prefer to talk with her about how all of the various medications are working for me and why I need them, something that rarely if ever fits into our short meeting time.

Regardless of who’s responsible, this is a huge problem. Patients like me are being sent with some general drug information, a pat on the back, and if we experience side effects or are taking meds incorrectly we may not even know it.

So at this point you’re thinking, “Okay, genius, what would YOU do differently?” And that’s a fair question. So here’s what I’d like to see happen when doctors prescribe medications.

First, let’s skip over the issue of what it might take to integrate medication records across all providers’s HIT systems. Instead, let’s create a portal — aggregating all the medication records for all the pharmacies in a given ZIP Code — and allow anyone with a valid provider number and password to log in and review it.  The same site could run basic analytics examining interactions between drugs from all providers. (By the way, I’m familiar with Surescripts, which is addressing some of these gaps, but I’m envisioning a non-proprietary shared resource.)

Rather than serving as strictly a database, the site would include a rules engine which runs predictive analyses on what a patient’s next steps should be, given their entire regimen, then generate recommendations specific to that patient. If any of these were particularly important, the recommendations could be pushed to the provider (or if administrative, to staff members) by email or text.

These recommendations, which could range from reminding the patient to refill a critical drug to warning the clinician if an outside prescription interacts with their existing regimen. Smart analytics tools might even be able to predict whether a patient is doing well or poorly by what drugs have been added to their regimen, given the drug family and dosage.

Of course, these functions should ultimately be integrated into the physicians’ EMRs, but at first, hospitals and clinics could start by creating an interface to the portal and linking it to their EMR. Eventually, if this approach worked, one would hope that EMR vendors would start to integrate such capabilities into their platform.

Now I imagine there could be holes in these ideas and I realize how challenging it is to get disparate health systems and providers to work together. But what I do know is that patients like myself get far too little guidance on how to manage meds effectively, when to complain about problems and how to best advocate for ourselves when doctors whip out the prescription pad. And while I don’t think my overworked PCP can solve the problem on her own, I believe it may be possible to improve med management outcomes using smart automation.

Bottom line, I doubt anything will change here unless we create an HIT solution to the problem. After all, given how little time they have already, I don’t see clinicians spending a lot more time on meds. Until then, I’m stuck relying on obsessive research via Dr. Google, brief chats with my frantic retail pharmacist and instincts honed over time. So wish me luck!

Integrating With EMR Vendors Remains Difficult, But This Must Change

Posted on October 4, 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 FierceHealthcare.com 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.

Eventually, big EMR vendors will be forced to provide a robust API that makes it easy to attach services on to their core platform. While they may see it as a dilution of their value right now, in time it will become clear that they can’t provide everything to everyone.

For example, is pretty unlikely that companies like Epic and Cerner will build genomics applications, so they’re going to need to connect using an API to add that functionality for their users. (Check out this video with John Lynn, Chris Bradley of Mana Health and Josh Siegel of CareCloud for more background on building a usable healthcare API.)

But as recent research points out, some of the vendors may be dragged kicking and screaming in that direction before they make it easy to connect to their systems. In fact, a new study by Health 2.0 concludes that smaller health IT vendors still face significant difficulties integrating with EMRs created by larger vendors.

“The complaint is true: it’s hard for smaller health tech companies to integrate their solutions with big EMR vendors,” wrote Health 2.0’s Matthew Holt on The Health Care Blog. “Most EMR vendors don’t make it easy.”

The study, which was supported by the California Health Care Foundation, surveyed more than 100 small health technology firms. The researchers found that only two EMR vendors (athenahealth and Allscripts) were viewed by smaller vendors as having a well-advertised, easy to access partner program. When it came to other large vendors, about half were happy with Epic, Cerner and GE’s efforts, while NextGen and eClinicalWorks got low marks for ease of integration, Holt reported.

To get the big vendors on board, it seems as though customer pressure is still critical at present, Holt says. Vendors reported that it helped a great deal if they had a customer who was seeking the integration. The degree to which this mattered varied, but it seemed to be most important in the case of Epic, with 70% of small vendors saying that they needed to have a client recommend them before Epic would get involved in integration project.

But that doesn’t mean it’s smooth sailing from there on out.  Even in the case where the big EMR vendors got involved with the integration project, smaller tech vendors weren’t fond of many of their APIs .

More than a quarter of those using Epic and Cerner APIs rated them poorly, followed by 30% for NextGen, GE and MEDITECH and a whopping 50% for eClinicalWorks. The smaller vendors’ favorite APIs seemed to be the ones offered by athenahealth, Allscripts and McKesson. According to Holt, athenahealth’s API got the best ratings overall.

All that being said, some of the smaller vendors weren’t that enthusiastic about pushing for integration with big EMR vendors at present. Of the roughly 30% who haven’t integrated with such vendors, half said it wasn’t worth the effort to try and integrate, for reasons that included the technical or financial cost would be too great. Also, some of the vendors surveyed by Health 2.0 reported they were more focused on other data-gathering efforts, such as accessing wearables data.

Still, EMR vendors large and small need to change their attitude about opening up the platform, and smaller vendors need to support them when they do so. Otherwise, the industry will remain trapped by a self-fulfilling prophecy that true integration can never happen.

Building a Usable Healthcare API

Posted on August 31, 2016 I Written By

John Lynn is the Founder of the HealthcareScene.com 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 InfluentialNetworks.com and Physia.com. 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’ve long believed that a rock solid API is going to be required by healthcare IT software companies and EHR vendors in particular. If we want hospitals and doctors to be able to accomplish everything they need to accomplish, we need APIs to connect providers to services that will better serve the patients. EHR vendors aren’t going to do everything. With this in mind, we thought that it was time to start a discussion on how to build a usable healthcare API.

On Thursday, September 8th at 3:30 PM ET (12:30 PM PT), join us LIVE in our latest Healthcare Scene interview, as we discuss healthcare APIs with the following experts:

2016 September - Building a Usable Healthcare API-Headshots
There are a lot of people who talk generally about an API, but very few that have executed it well in healthcare. CareCloud and ManaHealth are two healthcare companies that are trying to implement a health care API in the right way, so we’re excited to sit down with them to talk about their experience building healthcare APIs.

If you’ve never watched one of our live video interviews, you can watch it live on this YouTube page (includes Live Chat room as well) or just visit this post on the day of the event and watch the video embedded below:

We look forward to shedding more light on what it takes to build a high quality, usable healthcare API.

Be sure to Subscribe to Healthcare Scene on YouTube to be updated on our future interviews or watch our archive of past Healthcare Scene Interviews.

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 FierceHealthcare.com 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.

Wearables Data May Prevent Health Plan Denials

Posted on August 27, 2015 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 FierceHealthcare.com 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.

This story begins, as many do, with a real-world experience. Our health plan just refused to pay for a sleep study for my husband, who suffers from severe sleep apnea, despite his being quite symptomatic. We’re following up with the Virginia Department of Insurance and fully expect to win the day, though we remain baffled as to how they could make such a decision. While beginning the complaint process, a thought occurred to me.

What if wearables were able to detect wakefulness and sleepiness, and my husband was being tracked 24 hours a day?  If so, assuming he was wearing one, wouldn’t it be harder for a health plan to deny him the test he needed? After all, it wouldn’t be the word of one doctor versus the word of another, it would be a raft of data plus his sleep doctor’s opinion going up against the health plan’s physician reviewer.

Now, I realize this is a big leap in several ways.

For one thing, today doctors are very skeptical about the value generated by patient-controlled smartphone apps and wearables. According to a recent survey by market research firm MedPanel, in fact, only 15% of doctors surveyed see wearables of health apps as tools patients can use to get better. Until more physicians get on board, it seems unlikely that device makers will take this market seriously and nudge it into full clinical respectability.

Also, data generated by apps and wearables is seldom organized in a form that can be accessed easily by clinicians, much less uploaded to EMRs or shared with health insurers. Tools like Apple HealthKit, which can move such data into EMRs, should address this issue over time, but at present a lack of wearable/app data interoperability is a major stumbling block to leveraging that data.

And then there’s the tech issues. In the world I’m envisioning, wearables and health apps would merge with remote monitoring technologies, with the data they generate becoming as important to doctors as it is to patients. But neither smartphone apps nor wearables are equipped for this task as things stand.

And finally, even if you have what passes for proof, sometimes health plans don’t care how right you are. (That, of course, is a story for another day!)

Ultimately, though, new data generates new ways of doing business. I believe that when doctors fully adapt to using wearable and app data in clinical practice, it will change the dynamics of their relationship with health plans. While sleep tracking may not be available in the near future, other types of sophisticated sensor-based monitoring are just about to emerge, and their impact could be explosive.

True, there’s no guarantee that health insurers will change their ways. But my guess is that if doctors have more data to back up their requests, health plans won’t be able to tune it out completely, even if their tactics issuing denials aren’t transformed. Moreover, as wearables and apps get FDA approval, they’ll have an even harder time ignoring the data they generate.

With any luck, a greater use of up-to-the-minute patient monitoring data will benefit every stakeholder in the healthcare system, including insurers. After all, not to be cliched about it, but knowledge is power. I choose to believe that if wearables and apps data are put into play, that power will be put to good use.

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 (http://oreilly.com/) 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.

A Mature API for an Electronic Health Record: the OpenMRS Process

Posted on August 14, 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 (http://oreilly.com/) 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.

By some measures, OpenMRS may be the most successful of the open source EHRs, widely deployed around the world. It also has a long experience with its API, which has been developed and refined over the last several years. I talked to OpenMRS developer Wyclif Luyima recently and looked at OpenMRS’s REST API documentation to see what the API offers.
Read more..