Standards are both critical and frustrating. Health care standards may be where Web browsers were around 1995, as Internet access was growing explosively and new extensions to Web standards were being proposed right and left. In those years, getting your Web page to show up in readable form on every browser was a challenge that called for constant user testing. The advent of mobile phones made proper layout even more difficult, as well as more urgent. And the incompatibilities have still not been fully resolved; I have three browsers on my own system and switch between them to handle different web sites.
In health care, a thriving industry has grown up to work around the failure of standards in data storage and exchange. For instance, Validic harmonizes device data with EHRs and other apps that use it. Last week I talked to a senior developer at another company in this space, Redox. Nick Hatt, coming away from several years at Epic, was one of the earliest employees of Redox, and he explained some of the barriers his teams have overcome while getting different apps and EHRs to exchange data. Along the way he brought me up to date on the state of standards in health care. I also exchanged mail with Grahame Grieve, cofounder of the FHIR API now standardized by HL7, and with Dr. Kenneth D. Mandl, a Harvard Medical School professor who directs the Computational Health Informatics Program at Boston Children’s Hospital, and is a founder of the SMART health information standard project.
An example of an application facilitated by Redox–and in fact, the first application created by a client using their service-was an iPad app that determines the loss of blood suffered by a patient during an operation. This is an important item of data that is normally estimated and manually entered by a nurse after the procedure.
Using the app, instead, the nurse can photograph gauze from the patient, leaving it up to the app to estimate blood loss and enter the result automatically into the EHR. Redox’s biggest market at the moment comes from developers trying to exchange data over secure VPNs between on-premises EHRs and cloud-based applications.
Standards–Do I Know You?
One of the most successful standards covers e-prescribing. The standard is developed by the National Council for Prescription Drug Programs, (NCPDP), but according to Hatt, it’s really Surescripts that makes it work. The NCPDP standard, like many HL7 standards familiar to health IT staff, is loose and leaves a lot up to interpretation. If the e-prescribing market were as diverse as the EHR market, clinics could define NCPDP messages lots of different ways and we’d have the same headaches with e-prescribing as we do with patient record exchange. In e-prescribing, however, Surescripts has a near-monopoly; in fact, the FTC recently sued them over prescription routing. Whatever the economic effects of this dominance, Hatt says that Surescripts uses it to rigorously check the messages sent through it and to ensure they adhere to its view of the NCPDP standard.
Another crucial area in health care is billing, the lifeblood of the industry. Here, the standard comes from an ANSI-accredited body called X12, which defines a number of Electronic Data Interchange (EDI) standards for many industries. Although X12 presents its standards as interoperable, Hatt has found that the all-too-familiar Babyl of different implementations exists here. Hatt says that it is up to the clearinghouses that stand between the clinicians and the insurers to maintain translation tables. Along with all the other services that clearinghouses perform (and charge for) to navigate the shoals of billing, they perform a vital role similar to Redox by allowing organizations with incompatible formats to exchange data.
Now for HL7, the central standards-making body for EHRs. HL7 version 2 was notoriously ill-defined (as was the XML-based CDA) and gave rise to many incompatible versions. Hatt cites two examples of many: a visit number could be located in several places (including the patient record and the encounter record), and the list of ethnicities can be customized, which makes it hard to check for disparities or do ethnicity-based evaluations of treatment efficacy.
For the first few decades, in addition, the format was not API-friendly because it required a lot of unique programming and punctuation counting. This in turn held back analytics and automation, which we need even for such basic industry practices as prior authorization of procedures. To show why processing was difficult, here is an excerpt from an HL7 version 2 message, taken from a Ringholm white paper:
OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730|||||||||
Although the version 3 format, which placed values into well-marked XML fields, greatly simplified programming access, it’s the adoption of FHIR that really promises to bring patient records into the 21st century, analytically speaking. FHIR observes all the modern conventions for good programming, as a RESTful API accessible to all popular languages. SMART on FHIR provides a higher-level platform for exposing EHR data, and according to Mandl, is used by Apple as well as numerous other developers to connect their apps to electronic health record systems.
There will certainly be variations in FHIR, because it allows extensions for different geographic regions and because new versions–it stands currently at version 4.0–break compatibility with old ones. So one of the standard’s key achievements is to include rules that allow programmers to build validators, just as they build other tools to process health records.
Standards and Restrictions
Most health care standards in health care are expensive and hard to access for open source development. NCPDP membership is $750 per person. X12, like most standards bodies, charges for copies of its standards. But a recently added service called Glass provides the public with free access to some X12 resources, and allows X12 licensees access to all versions of X12’s EDI Standard for $180 per year.
An X12 representative wrote me, “One of the goals with X12’s licensing program is to evenly distribute the ongoing cost of developing standards so that those that accrue value from the use of the standards pay a low amount to support those standards on an ongoing basis. For example, X12 offers a developer license that grants people such as entrepreneurs rights to access all X12 products for a low cost while they develop related commercial products.”
The NCPDP did not respond to a request for comment.
These organizations probably regard their fees as crucial income. But one effect, whether anticipated or not, is to put up barriers to entry for start-ups. Furthermore, even the most trivial fee or barrier precludes open source development. Of course a company can pay for the standard and release a programming application under an open source license. And in fact, according to Hatt, one can find free X12-compatible schemas on GitHub. But without access to the standard, an outsider cannot evaluate or add to such free tools. The open source ideal of a collaborating collection of part-time volunteers does not fit with licensing fees.
Although free and open source software continues to be largely neglected in the health care space, a number of robust open source tools (notably OpenMRS, widespread in many countries) illustrates the value of free software. As I have explained elsewhere, it facilitates interoperability, quality, and cost reductions.
HL7 had similar locks on its standards for most of its existence. It took a major step in 2012 by offering standards for free download. This showed great promise, but did not turn HL7 into a free and open source organization. HL7 places restrictions on sharing and derivative works. These restrictions are modest and are intended to ensure both the integrity of the standard and HL7’s ability to monitor its use. However, they are narrow enough to disqualify HL7 standards as free software or open source.
The HL7 adoption of FHIR is even more significant because FHIR is much more than a new standard on paper. Regarded by Grieve as a public good, it comes with an open Creative Commons license. Partly thanks to this, it attracts a world-wide community of volunteers, a prerequisite for a healthy open source project.
In summary, standards can be both liberating and controlling. On the one hand, they permit interoperability and encourage the entry of new businesses to solve widespread problems. But unless they are royalty-free and released under an open license, they can remain opaque to independent, creative spirits. It may be hard for each standards organization to give up the revenue and control associated with their licensing policy. So the health care field as a whole has to come together around the realization that the tremendous innovation facilitated by open standards will provide much more benefit than the royalty fees and other perks of putting a standard behind walls.