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!

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

OpenUMA: New Privacy Tools for Health Care Data

Posted on August 10, 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.

The health care field, becoming more computer-savvy, is starting to take advantage of conveniences and flexibilities that were developed over the past decade for the Web and mobile platforms. A couple weeks ago, a new open source project was announced to increase options for offering data over the Internet with proper controls–options with particular relevance for patient control over health data.

The User-Managed Access (UMA) standard supports privacy through a combination of encryption and network protocols that have a thirty-year history. UMA reached a stable release, 1.0 in April of this year. A number of implementations are being developed, some of them open source.

Before I try to navigate the complexities of privacy protocols and standards, let’s look at a few use cases (currently still hypothetical) for UMA:

  • A parent wants to show the child’s school records from the doctor’s office just long enough for the school nurse to verify that the child has received the necessary vaccinations.

  • A traveler taking a temporary job in a foreign city wants to grant a local clinic access to the health records stored by her primary care physician for the six months during which the job lasts.

The open source implementation I’ll highlight in this article is OpenUMA from a company named ForgeRock. ForgeRock specializes in identity management online and creates a number of open source projects that can be found on their web page. They are also a leading participant in the non-profit Kantara Initiative, where they helped develop UMA as part of the UMA Developer Resources Work Group.

The advantage of open source libraries and tools for UMA is that the standard involves many different pieces of software run by different parts of the system: anyone with data to share, and anyone who wants access to it. The technology is not aimed at any one field, but health IT experts are among its greatest enthusiasts.

The fundamental technology behind UMA is OAuth, a well-tested means of authorizing people on web sites. When you want to leave a comment on a news article and see a button that says, “Log in using Facebook” or some other popular site, OAuth is in use.

OAuth is an enabling technology, by which I mean that it opens up huge possibilities for more complex and feature-rich tools to be built on top. It provides hooks for such tools through its notion of profiles–new standards that anyone can create to work with it. UMA is one such profile.

What UMA contributes over and above OAuth was described to me by Eve Maler, a leading member of the UMA working group who wrote their work up in the specification I cited earlier, and who currently works for ForgeRock. OAuth lets you manage different services for yourself. When you run an app that posts to Twitter on your behalf, or log in to a new site through your Facebook account, OAuth lets your account on one service do something for your account on another service.

UMA, in contrast, lets you grant access to other people. It’s not your account at a doctor’s office that is accessing data, but the doctor himself.

UMA can take on some nitty-gritty real-life situations that are hard to handle with OAuth alone. OAuth provides a single yes/no decision: is a person authorized or not? It’s UMA that can handle the wide variety of conditions that affect whether you want information released. These vary from field to field, but the conditions of time and credentials mentioned earlier are important examples in health care. I covered one project using UMA in an earlier article.

With OAuth, you can grant access to an account and then revoke it later (with some technical dexterity). But UMA allows you to build a time limit into the original access. Of course, the recipient does not lose the data to which you granted access, but when the time expires he cannot return to get new data.

UMA also allows you to define resource sets to segment data. You could put vaccinations in a resource set that you share with others, withholding other kinds of data.

OpenUMA contains two crucial elements of a UMA implementation:

The authorization server

This server accepts a list of restrictions from the site holding the data and the credentials submitted by the person requesting access to the data. The server is a very generic function: any UMA request can use any authorization server, and the server can run anywhere. Theoretically, you could run your own. But it would be more practical for a site that hosts data–Microsoft HealthVault, for instance, or some general cloud provider–to run an authorization server. In any case, the site publicizes a URL where it can be contacted by people with data or people requesting data.

The resource server

These submit requests to the authorization server from applications and servers that hold people’s data. The resource server handles the complex interactions with the authorization server so that application developers can focus on their core business.

Instead of the OpenUMA resource server, apps can link in libraries that provide the same functions. These libraries are being developed by the Kantara Initiative.

So before we can safely share and withhold data, what’s missing?

The UMA standard doesn’t offer any way to specify a condition, such as “Release my data only this week.” This gap is filled by policy languages, which standards groups will have to develop and code up in a compatible manner. A few exist already.

Maler points out that developers could also benefit from tools for editing and testing code, along with other supporting software that projects build up over time. The UMA resource working group is still at the beginning of their efforts, but we can look forward to a time when fine-grained patient control over access to data becomes as simple as using any of the other RESTful APIs that have filled the programmer’s toolbox.

Ready For a Third-Party Market for Apps on Your EHR? athenahealth Explains How (Part 2 of 2)

Posted on July 20, 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.

In part 1 of this article, I explained why EHR vendors need to attract outside developers to remain competitive, and how athenahealth’s More Disruption Please (MDP) program pursued this goal by developing open APIs. This part goes on to describe how they made their athenahealth Marketplace an actuality.

Through experimentation, API developers throughout companies and governments have found a toolbox of best practices to develop and promote their APIs. athenahealth pretty much did everything in this toolbox:

  • A prominent public announcement (in this case, coming from the CEO Jonathan Bush himself)

  • A regular set of hackathons to answer developer questions and familiarize them with the APIs,

  • An early pilot partnership that created a demonstration project and produced insights for further development, described in Part 1 of this article

  • An accelerator program that offers seed funding, free office space, mentorship, technical resources, support, and contacts with the client base

  • A commitment to support both physicians and partners, including a requirement that athenahealth developers work on API documentation

Access to the APIs is easy–for security purposes, a developer has to agree to the run-of-the-mill terms and conditions, but the process is fast and there is no charge. The athenahealth Marketplace is large and thriving, with more than 2,500 members.

Having spent a lot of money for an EHR, clinicians who are growing more tech-savvy and have come to love their mobile apps will demand more and more value for the money. Vendors are coming to realize that they can’t produce all the value-added solutions and functionality their customers want.

The SMART Platform has, for several years, championed the availability of EHR data to fuel app development by EHR users and third-party companies. The recent FHIR standard has drawn enthusiasm from vendors. A number of them, including athenahealth, have formed the Argonauts project to develop shared definitions and ensure that, in an interoperable way, they can provide the most common types of data used by US clinicians.

But as explained before, supporting an API does not automatically lead to more effective, beneficial apps or services. athenahealth has gone to the next level to attract real-time, dynamic applications to its Marketplace, and in turn is reaping the benefits.

Ready For a Third-Party Market for Apps on Your EHR? athenahealth Explains How (Part 1 of 2)

Posted on July 17, 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 number of electronic health record vendors now grant access to EHR data to programmers at user sites through an application programming interface (API). Hospitals and ambulatory practices are making great use of APIs to extract data on patients and analyze it to improve care (or at least their bottom lines–it’s good for marketing to patients as well as protecting them from adverse medical events).

Far fewer EHRs allow totally new applications to be built by outsiders, suitable for sale or free distribution to health care providers. To find out more about how this can be jump-started, I talked recently to Chip Ach at athenahealth, whose outspoken CEO Jonathan Bush has committed to dealing with health care in new ways. (I reviewed Bush’s book, Where Does It Hurt?,in another article.) Chip Ach is senior architect for athenahealth’s More Disruption Please (MDP) program.

MDP is building an open, API-based ecosystem on athenahealth’s cloud-based platform for entrepreneurs to connect, collaborate, and scale more efficiently in health care. athenahealth allows both established and start-up health IT companies to sign up as partners, creating a large marketplace of innovative, third-party health care solutions. Applications solve such problems as scheduling, speeding up payments, and increasing engagement with patients.

The value of a third-party market
Let’s step back a minute to look at why both vendors and health care providers would want a marketplace for companies to write apps based on their EHR data. Start with the obscurity of the data itself: very few health care providers can find out from their EHRs which patients are frequent ER visitors or which surgeons have consistently better outcomes–data that could trigger critical interventions. Even fewer EHRs provide information to patients, and the patient portals that some providers have made available usually offer extremely limited views.

Second, most EHRs have poor interfaces, a gawkiness that becomes especially evident on the tablets and cell phones that are just as popular among clinicians as the general population. A healthy competition and atmosphere of experimentation among interface developers will greatly improve EHR usability.

Clinicians are just too diverse for one vendor to take into account all their needs. More often than now, clinicians report a drop in productivity after the introduction of EHRs, even after the users get acclimated. If an agile development process could create unique and customizable interfaces, doctors and nurses could go back to focusing on patients.

Finally, unanticipated uses for patient data can emerge from an open marketplace. The use of analytics and clinical decision support could skyrocket.

athenahealth management decided several years ago that the health care system needs a radical change toward generating and accepting new solutions to its pain points. Calling this a “Health Care Internet,” they see it as a place for health care providers to compare and “shop” for nearly any product or service they might want or need, whether it be data management, digital check-in, self-pay, mobile charge capture, or transcription. MDP and the athenahealth Marketplace are their contributions to change.

Steps toward athenahealth’s Marketplace
It takes a special program like MDP to draw developers to a platform, particularly in health care where so many developers are deterred by the field’s complexity and issues of liability. In keeping with the company vision to straighten out the operation of the health care system, athenahealth embraced an open platform, adhering to industry standards such as HL7 and investigating the publication of open APIs.

At the same time, their programmers were modularizing a rather monolithic code to reap the productivity benefits that this would offer. Modularization facilitated the design of APIs to connect one module with another. After announcing a few open APIs and seeing the program catch on, the MDP team asked itself: why not make all their modules available to outside programmers, including those that were previously considered internal?

Early in the program, they found a company eager to develop an appointment scheduling application, and worked closely with them to make it possible. Ach’s team promised to get the API working in three months, which was quite a tight deadline. None of the team had prior experience doing an open API for a market, and they needed to face a lot of new requirements that openness created–for instance, adding an authentication layer, deciding how to deliver documentation on the APIs, and offering the opportunity for developers to get a feel for using the APIs. They now have a developer’s portal open to those who sign their modest terms and conditions. There is no fee or vetting process.

To speed up delivery of an API, athenahealth developers sought out a management service and chose Mashery to do the job. In the end, after a lot of long workdays, they met their three-month deadline. The partner was so sure they’d miss the deadline that it wasn’t ready to use the API–but it caught up and successfully released the app. Along the way, the MDP team learned some of the range of data that needed to be exposed by their APIs.

Eventually, athenahealth dedicated itself to rigorously modularizing their code with well-defined interfaces between all components–like Amazon.com–and to exposing as many interfaces as they could to partners. Naturally, this was potentially frightening; both managers and programmers have to take a leap of faith. What would design decisions made years ago look like when put out in the light of day? How many changes would they have to make?

According to Ach, developers were not resistant for ego reasons (they didn’t mind showing the architecture to outsiders), but worried about their ability to seamlessly upgrade the API in the future. A lot of decisions had to be made quickly before opening the APIs to third-party developers, who would come to depend on them and assume they would remain unchanged. Ach says the teams have been happy with their choices, although early on, in the effort to keep the process moving forward, they didn’t create all their naming standards and left that to be done later.

So the process went smoothly on the inside–but how did it fare externally? That’s the subject of part 2 of this article.