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 HIPAA for FREE!!

HL7 Releases New FHIR Update

Posted on April 3, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she’s served as editor in chief of several healthcare B2B sites.

HL7 has announced the release of a new version of FHIR designed to link it with real-world concepts and players in healthcare, marking the third of five planned updates. It’s also issuing the first release of the US Core Implementation Guide.

FHIR release 3 was produced with the cooperation of hundreds of contributors, and the final product incorporates the input of more than 2,400 suggested changes, according to project director Grahame Grieve. The release is known as STU3 (Standard for Trial Use, release 3).

Key changes to the standard include additional support for clinical quality measures and clinical decision support, as well as broader functionality to cover key clinical workflows.

In addition, the new FHIR version includes incremental improvements and increased maturity of the RESTful API, further development of terminology services and new support for financial management. It also defined an RDF format, as well as how FHIR relates to linked data.

HL7 is already gearing up for the release of FHIR’s next version. It plans to publish the first draft of version 4 for comment in December 2017 and review comments on the draft. It will then have a ballot on the version, in April 2018, and publish the new standard by October 2018.

Among those contributing to the development of FHIR is the Argonaut project, which brings together major US EHR vendors to drive industry adoption of FHIR forward. Grieve calls the project a “particularly important” part of the FHIR community, though it’s hard to tell how far along its vendor members have come with the standard so far.

To date, few EHR vendors have offered concrete support for FHIR, but that’s changing gradually. For example, in early 2016 Cerner released an online sandbox for developers designed to help them interact with its platform. And earlier this month, Epic announced the launch of a new program, helping physician practices to build customized apps using FHIR.

In addition to the vendors, which include athenahealth, Cerner, Epic, MEDITECH and McKesson, several large providers are participating. Beth Israel Deaconess Medical Center, Intermountain Healthcare, the Mayo Clinic and Partners HealthCare System are on board, as well as the SMART team at the Boston Children’s Hospital Informatics Program.

Meanwhile, the progress of developing and improving FHIR will continue.  For release 4 of FHIR, the participants will focus on record-keeping and data exchange for the healthcare process. This will encompass clinical data such as allergies, problems and care plans; diagnostic data such observations, reports and imaging studies; medication functions such as order, dispense and administration; workflow features like task, appointment schedule and referral; and financial data such as claims, accounts and coverage.

Eventually, when release 5 of FHIR becomes available, developers should be able to help clinicians reason about the healthcare process, the organization says.

Epic and other EHR vendors caught in dilemmas by APIs (Part 2 of 2)

Posted on March 16, 2017 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 first section of this article reported some news about Epic’s Orchard, a new attempt to provide an “app store” for health care. In this section we look over the role of APIs as seen by EHR vendors such as Epic.

The Roles of EHRs

Dr. Travis Good, with whom I spoke for this article, pointed out that EHRs glom together two distinct functions: a canonical, trusted store for patient data and an interface that becomes a key part of the clinician workflow. They are being challenged in both these areas, for different reasons.

As a data store, EHRs satisfied user needs for many years. The records organized the data for billing, treatment, and compliance with regulations. If there were problems with the data, they stemmed not from the EHRs but from how they were used. We should not blame the EHR if the doctor upcoded clinical information in order to charge more, or if coding was too primitive to represent the complexity of patient illness. But clinicians and regulators are now demanding functions that EHRs are fumbling at fulfillling:

  • More and more regulatory requirements, which intelligent software would calculate on its own from data already in the record, but which most EHRs require the physician to fill out manually

  • Patient-generated data, which may be entered by the patient manually or taken from devices

  • Data in streamlined formats for large-scale data analysis, for which institutions are licensing new forms of databases

Therefore, while the EHR still stores critical data, it is not the sole source of truth and is having to leave its borders porous in order to work with other data sources.

The EHR’s second function, as an interface that becomes part of the clinicians’ hourly workflow, has never been fulfilled well. EHRs are the most hated software among their users. And that’s why users are calling on them to provide APIs that permit third-party developers to compete at the interface level.

So if I were to write a section titled “The Future of Current EHRs” it could conceivably be followed by a blank page. But EHRs do move forward, albeit slowly. They must learn to be open systems.

With this perspective, Orchard looks like doubling down on an obsolete strategy. The limitations and terms of service give the impression that Epic wants to remain a one-stop shopping service for customers. But if Epic adopted the SMART approach, with more tolerance for failure and options for customers, it would start to reap the benefits promised by FHIR and foster health care innovation.

Epic and Other EHR Vendors Caught in Dilemmas by APIs (Part 1 of 2)

Posted on March 15, 2017 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 HITECH act of 2009 (part of the American Recovery and Reinvestment Act) gave an unprecedented boost to an obscure corner of the IT industry that produced electronic health records. For the next eight years they were given the opportunity to bring health care into the 21st century and implement common-sense reforms in data sharing and analytics. They largely squandered this opportunity, amassing hundreds of millions of dollars while watching health care costs ascend into the stratosphere, and preening themselves over modest improvements in their poorly functioning systems.

This was not solely a failure of EHR vendors, of course. Hospitals and clinicians also needed to adopt agile methods of collaborating and using data to reduce costs, and failed to do so. They’re sweating profusely now, as shown in protests by the American Medical Association and major health care providers over legislative changes that will drastically reduce their revenue through cuts to insurance coverage and Medicaid. EHR vendors will feel the pain of a thousand cuts as well.

I recently talked to Dr. Travis Good, CEO of Datica that provides data integration and storage to health care providers. We discussed the state of EHR interoperability, the roles of third-party software vendors, and in particular the new “app store” offered by Epic under the name Orchard. Although Datica supports integration with a dozen EHRs, 70% of their business involves Epic. So we’ll start with the new Orchard initiative.

The Epic App Store

Epic, like most vendors, has offered an API over the past few years that gives programmers at hospitals access to patient data in the EHR. This API now complies with the promising new standard for health data, FHIR, and uses the resources developed by the Argonaut Project. So far, this is all salutary and positive. Dr. Good points out, however, that EHR vendors such as Epic offer the API mostly to extract data. They are reluctant to allow data to be inserted programmatically, claiming it could allow errors into the database. The only change one can make, usually, is to add an annotation.

This seriously hampers the ability of hospitals or third-party vendors to add new value to the clinical experience. Analytics benefit from a read-only data store, but to reach in and improve the doctor’s workflow, an application must be able to write new data into the database.

More risk springs from controls that Epic is putting on the apps uploaded to Orchard. Like the Apple Computer store that inspired Orchard, Epic’s app store vets every app and allows in only the apps that it finds useful. For a while, the terms of service allowed Epic access to the data structures of the app. What this would mean in practice is hard to guess, but it suggests a prurient interest on the part of Epic in what its competitors are doing. We can’t tell where Epic’s thinking is headed, though, because the public link to the terms of service was recently removed, leaving a 404 message.

Good explained that Epic potentially could track all the transactions between the apps and their users, and in particular will know which ones are popular. This raises fears among third-party developers that Epic will adopt their best ideas and crowd them out of the market by adding the features to its own core system, as Microsoft notoriously did during the 1980s when it dominated the consumer software market.

Epic’s obsession with control can be contrasted with the SMART project, an open platform for health data developed by researchers at Harvard Medical School. They too offer an app gallery (not a store), but their goal is to open the repository to as wide a collection of contributors as possible. This maximizes the chances for innovation. As described at one of their conferences, control over quality and fitness for use would be exerted by the administrator of each hospital or other institution using the gallery. This administrator would choose which apps to make available for clinical staff to download.

Of course, SMART apps also work seamlessly cross-platform, which distinguishes them from the apps provided by individual vendors. Eventually–ideally–FHIR support will allow the apps in Orchard and from other vendors to work on all EHRs that support FHIR. But the standard is not firm enough to allow this–there are too many possible variations. People who have followed the course of HITECH implementation know the history of interoperability, and how years of interoperability showcases at HIMSS have been mocked by the real incompatibilities between EHRs out in the field.

To understand how EHRs are making use of APIs, we should look more broadly at their role in health care. That will be the topic of the next section of this article.

Schlag and Froth: Argonauts Navigate Between Heavy-weight and Light-weight Standardization (Part 2 of 2)

Posted on August 26, 2016 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 previous section of this article laid out the context for HL7 FHIR standard and the Argonaut project; now we can look at the current status.

The fruits of Argonaut are to be implementation guides that they will encourage all EHR vendors to work from. These guides, covering a common clinical data set that has been defined by the ONC (and hopefully will not change soon), are designed to help vendors achieve certification so they can sell their products with the assurance that doctors using them will meet ONC regulations, which require a consumer-facing API. The ONC will also find certification easier if most vendors claim adherance to a single unambiguous standard.

The Argonaut implementation guides, according to Tripathi, will be complete in late September. Because FHIR is expected to be passed in September 2017, the Argonaut project will continue to refine and test the guides. One guide already completed by the project covers security authorization using OpenID and OAuth. FHIR left the question of security up to those standards, because they are well-established and already exist in thousands of implementations around the Web.

Achieving rough consensus

Tripathi portrays the Argonaut process as radically different from HL7 norms. HL7 has established its leading role in health standards by following the rules of the American National Standards Institute (ANSI) in the US, and similar bodies set up in other countries where HL7 operates. These come from the pre-Internet era and emphasize ponderous, procedure-laden formalities. Meetings must be held, drafts circulated, comments explicitly reconciled, ballots taken. Historically this has ensured that large industries play fair and hear through all objections, but the process is slow and frustrates smaller actors who may have good ideas but lack the resources to participate.

In contrast, FHIR brings together engineers and other interested persons in loose forums that self-organize around issues of interest. The process still tried to consider every observation and objection, and therefore, as we have seen, has taken a long time. But decision-making takes place at Internet speed and there is no jockeying for advantage in the marketplace. Only when a milestone is reached does the formal HL7 process kick in.

The Argonaut project works similarly. Tripathi reports that the vendors have gotten along very well. Epic and Cerner, the behemoths of the EHR field, are among the most engaged. Company managers don’t interfere with engineer’s opinions. And new vendors with limited resources are very active.

Those with a background in computers can recognize, in these modes of collaboration, the model set up by the Internet Engineering Task Force (IETF) decades ago. Like HL7, the IETF essentially pre-dated the Internet as we know it, which they helped to design. (The birth of the Internet is usually ascribed to 1969, and the IETF started in 1986, at an early stage of the Internet. FTP was the canonical method of exchanging their plain-text documents with ASCII art, and standards were distributed as Requests for Comments or RFCs.) The famous criteria cited by the IETF for approving standards is “rough consensus and running code.” FHIR and the Argonauts produce no running code, but they seem to operate through rough consensus, and the Argonauts could add a third criterion, “Get the most important 90% done and don’t let the rest hold you up.”

Tripathi reports that EHR vendors are now collaborating in this same non-rivalrous manner in other areas, including the Precision Medicine initiative, the Health Services Platform Consortium (HSPC), and the SMART on FHIR initiative.

What Next?

The dream of interoperability has long included the dream of a marketplace for apps, so that we’re not stuck with the universally hated EHR interfaces that clinicians struggle with daily, or awkwardly designed web sites for consumers. Tripathi notes that SMART offers an app gallery with applications that ought to work on any EHR that conforms to the open SMART platform. Cerner and athenahealth also have app stores protected by a formal approval process. (Health apps present more risk than the typical apps in the Apple App Store or Google Play, so they call more more careful, professional vetting.) Tripathi is certain that other vendors will follow in the lead of these projects, and that cross-vendor stores like SMART’s App Gallery will emerge in a few years along with something like a Good Housekeeping seal for apps.

The Argonaut guides will have to evolve. It’s already clear that EHR vendors are doing things that aren’t covered by the Argonaut FHIR guide, so there will be a few incompatible endpoints in their APIs. Consequently, the Argonaut project has a big decision to make: how to provide continuity? The project was deliberately pitched to vendors as a one-time, lightweight initiative. It is not a legal entity, and it does not have a long-term plan for stewardship of the outcomes.

The conversation over continuity is ongoing. One obvious option is to turn over everything to HL7 and let the guides fall under its traditional process. A new organization could also be set up. HL7 itself has set up the FHIR Foundation under a looser charter than HL7, probably (in my opinion) because HL7 realizes it is not nimble and responsive enough for the FHIR community.

Industries reach a standard in many different ways. In health care, even though the field is narrow, standards present tough challenges because of legacy issues, concerns over safety, and the complexity of human disease. It seems in this case that a blend of standardization processes has nudged forward a difficult process. Over the upcoming year, we should know how well it worked.