FHIR® – Fast Healthcare Interoperability Resources (hl7.org/fhir) – is a next generation standards framework created by HL7. FHIR combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and applying a tight focus on implementability.
FHIR solutions are built from a set of modular components called “Resources”. These resources can easily be assembled into working systems that solve real world clinical and administrative problems at a fraction of the price of existing alternatives. FHIR is suitable for use in a wide variety of contexts – mobile phone apps, cloud communications, EHR-based data sharing, server communication in large institutional healthcare providers, and much more...
A central challenge for healthcare standards is how to handle variability caused by diverse healthcare processes. Over time, more fields and optionality are added to the specification, gradually adding cost and complexity to the resulting implementations. The alternative is relying on custom extensions, but these create many implementation problems too.
FHIR solves this challenge by defining a simple framework for extending and adapting the existing resources. All systems, no matter how they are developed, can easily read these extensions and extension definitions can be retrieved using the same framework as retrieving other resources.
Example Resource: Patient
This simple example shows the important parts of a resource: a local extension, the human readable HTML presentation, and the standard defined data content...
I hope no one's thinking this will be an example of "UX-friendly." OK, let's just focus in on the patient name coding for a moment.
"Family?" Well (ignoring for the moment the lack of reference to a "middle name"), how many ways might we see some of these data expressed in the myriad ONC Certified EHR RDBMS dictionaries (and all manner of databases more broadly)?
I'd love to get a look at the data dictionaries for the major commercial EHRs, but they are all closely held "proprietary" structures. ONC should be able to examine them, though.
Now, were HL7 FHIR -- 'scuse me, HL7® FHIR® -- to be adopted by ONC as the comprehensive uniform data dictionary standard I have long advocated, perhaps this aspect of the Health IT problem would be largely solved.
Given that that's supremely unlikely, though, we inevitably remain faced with a huge point-to-point or hub/spoke data mapping "interoperability interface" task.
Do some combinatorial math. Recall from the dreaded undergrad stats or finite math class?
Assume, for outset simplicity, six mainstream EHRs whose names come readily to mind.
What are the maximum possible bidirectional data map interop interfaces via which to enable comprehensive data exchange? Going clockwise around the ring, starting with eCW:
- eCW -- e-MDs
- eCW -- Epic
- eCW -- Practice Fusion
- eCW -- Cerner
- eCW -- athenahealth
- e-MDs -- Epic
- e-MDs -- Practice Fusion
- e-MDs -- Cerner
- e-MDs -- athenahealth
- Epic -- Practice Fusion
- Epic -- Cerner
- Epic -- athenahealth
- Practice Fusion -- Cerner
- Practice Fusion -- athenahealth
- Cerner -- athenahealth
Easier to simply count the 15 connecting lines.
OK, let's scale up a bit, taking just today's ONC CHPL Certified EHR data, and using only the subset of "complete ambulatory and inpatient EHRs," 482 of them.
Combinatorally, we're talking 115,921 bidirectional data exchange interfaces. Were we to compute all 1,963 certified products, the number would be 1,925,703.
Several necessary observations:
- The ONC CHPL list surely overcounts the EHRs, given that the list is not "de-duped" for actual named products. It includes all versions for which a vendor's product has passed Cert. Nonetheless, to the extent a newer version of EHR "x" has data dictionary modifications, it's appropriate to count it. Suffice it to say with confidence that the problem is a huge one.
- My observations here are simply about the nominal aggregate 2-way interface numbers. Deeper down will be the myriad metadata "data typing" issues within each interface, going beyond simply the spelling of each variable name. Data types matter when it comes iterative health data exchange. Information corruption resulting from data dictionary definition variability propagates.
- Relatedly -- to use the Open EMR example (the only one I've seen readily available, given that it's open source): The Open EMR RDBMS is today comprised of 169 tables encompassing 3,731 variables. "N" number of certed EHRs, times "M" number of data cross-maps, times "V" number of vars, well, need I elaborate?
- Q: Would a hub/spoke architecture be simpler and more manageable (in particular once we expand the discussion beyond traditional EHRs and out to mobile, etc)? -- where the "hub" would be the central translation and routing service.
NEW FROM EHR SCIENCE
Dr. Carter never disappoints.
Dr. Carter responds to my heads-up:
He and I agree totally on standardizing data elements.
CODA: AND, "HOW®"
A Bestselling Author Claims To Own The Word 'How' And He's Launched A Lawsuit Over It
A best-selling author is suing Greek yogurt company Chobani for using the word "how."
Dov Seidman, who wrote a business management book called "How: Why How We Do Anything Means Everything," says that Chobani's new marketing campaign infringes on his trademark of the word...Lordy. We have far too many lawyers.
More to come...