The word ‘interoperability’ as used the current national healthcare dialog has a nuanced meaning.   Interoperability is generally defined as the ability of computer systems to readily exchange information.

In health care today, however, Interoperability (capitalized hereafter when I am trying to distinguish it from the general sense of the word) more closely means something like ‘the secure, standards-based integration of automated clinical and administrative health-care-related workflows across organizational boundaries to fill the gaps left by HIPAA and HITECH.’

The familiar X12 HIPAA transactions dictated by Administrative Simplification, 837 claims, 270 eligibility inquires, and so on, took care of the fundamental financial plumbing among ‘covered entities’ – payers, providers, and clearinghouses.

Once everyone was getting paid, we turned our collective national attention to clinical interoperability.

Conceptually it sounds pretty simple:  doctors should have ready access to their patients’ complete medical histories, and be able to readily collaborate in their care; consumers should have ready access to their complete medical histories, and control over who sees them; payers and providers should be able to readily collaborate in care management.

But for a number of reasons, some of which we will outline here, clinical interoperability has not yet been broadly achieved.

The history of Interoperability is a story of well-intentioned but flawed legislation, industry-led solution efforts of varying scope and success, and grassroots standards efforts with inconsistent adoption.

The result is a badly Balkanized landscape.  Large providers today may have ten or more different interoperability solutions they need to support, based on their EMR system of choice and the point-to-point, Health Information Exchange and Health Integration Network integrations they need to make to interoperate with their regional trading partners.

The current primary focus of the national Interoperability initiative is not about creating the net new next-generation standards and practices of homogenous Interoperability – although that work is happening.  The primary focus is on quilting together the work that has already been done in an attempt to achieve national clinical interoperability of electronic health records with the shortest practical time to market.

After recapping a brief history of Interoperability, we will survey the current landscape, then conclude by discussing the future of Interoperability.

A Brief History of Interoperability

The history of Interoperability is the history of three tightly intertwined threads:  legislation, standards, and solutions.

HIPAA

Our history review starts in 1996.  Bill Clinton, at the end of his first term, signed the Health Insurance Portability and Privacy Act, HIPAA.  The Administrative Simplification provisions of HIPAA mandated explicit electronic transaction types and code sets (essentially the paper transactions mapped into standard electronic supply-chain batch file formats) for core enrollment, claim and billing operations.  This was a huge lift for the nation.   It ended up taking eight years, until October 2004, to roll out the mandated interoperability standards.  The HIPAA Privacy and Security rules were enforced in 2003 and 2005.    Compliance was problematic, resulting in the 2006 HIPAA Enforcement Rule, which expanded the scope of the investigation of non-compliance to all of HIPAA, not just Privacy, and enabled stiff civil penalties for non-compliance.   In January 2012 the next version of the standard EDI transactions, 5010, was rolled out, primarily to pave the way for the mandated adoption of the ICD-10 diagnosis and procedure code standard in 2013, which 4010 plumbing couldn’t handle.

ONC

In 2004, George Bush the Younger created the Office of the National Coordinator for Health Information Technology, tasked with figuring out a National Health Information Network (NHIN) to enable nationwide Interoperability. (For a little technology context, Facebook was founded that year, and the top of the line cell was a Motorola flip phone.)

In 2007, Federal Health Architecture (FHA), an Office of Management and Budget coalition of government agencies managed out of ONC intended to advance intra-governmental health interoperability, created and open-sourced CONNECT, an API gateway interoperability hub.

Problem was, these well-intentioned, early, aggressive efforts to establish broad interoperability were premature. Before you can exchange electronic heath records (EHRs), providers actually have to have electronic health records. And their adoption rate at this time was only 3.2%. 

HITECH

Enter the 2009 Health Information Technology for Economic and Clinical Health (HITECH) Act. HITECH drove the adoption of EHRs with a carrot and a stick: the carrot was financial incentives provided for the ‘Meaningful Use’ of EHRs from 2009 to 2015; the stick was penalties after 2015 for not having adopted them.

That worked.  By 2017 86% of physician groups and 96% of hospitals had adopted EHRs.

The HITECH Act also gave patients the right to a copy of their electronic private health information (ePHI) (at a fee to cover the provider’s operational expenses).

That did not work so well.   Recent studies show patients continue to have challenges getting copies of their records from providers.

The other thing that did not work well was the interoperability of those EHRs.   The industry had naturally turned to the major EHR vendors to go electronic.    But those vendors – Epic, Cerner, Meditech, McKesson, Allscripts (those five own 86% of the inpatient hospital market) had no economic incentive to establish standards-based interoperability among their systems.  So they didn’t.   Information was blocked from flowing.

Meanwhile the ONC’s NHIN effort had hit heavy weather.  The initial committees formed to drive it, the Health Information Technology Standards Panel (HITSP) and Health Information Security and Privacy Collaborative (HISPC), were replaced by the HIT Policy Committee and HIT Standards Committee, which focused more closely on Meaningful Use.   

Direct

In an effort to get something working – another recurring theme here – in 2010 ONC created NHIN Direct.   It had more modest ambitions: implement secure messaging for sending encrypted health data.    NHIN Direct survives today as Direct.

Blue Button

Under the Obama administration, ONC took a different tack in trying to move the larger needle, taking a more collaborative approach across the board.

The Blue Button initiative had its origins in the Markle Foundation’s workgroup on consumer engagement, with representatives from private industry, not-for-profits, and the federal government.   Instead of boiling the Interoperability Ocean, they suggested the simplest possible solution for supporting the consumer:  let them easily download their health record.   Don’t worry the format, don’t worry the interface, just give them a big button to push.  And make it blue. In October 2010 the VA and CMS enabled Blue Button data access on their websites.

Public-Private Harmony

In 2011 ONC created the Standards and Interoperability Framework, designed to foster public/private collaboration and ‘harmonize’ standards and concepts across the many unconnected projects that had been springing up across industry and government.  

Among other things they gradually pursued adding more structure and more rigor to the Blue Button standard.  Blue Button’s adoption has grown since, with many providers and payers rolling it out, and many third parties supporting integration with Blue Button data.

In December 2012, ONC continued its public/private push, abandoning the field of governance of health information exchange to entities already doing it.

Among the many public and private Interoperability projects that have emerged across the landscape:

• The EHR/HIE Interoperability Workgroup out of the New York eHealth Collaborative, founded in 2011, which created specifications around the IHE standards to promote their rapid deployment.
• The Care Connectivity Consortium (CCC), formed by the Mayo Clinic, Geisinger, Kaiser Permanente, Intermountain Healthcare and Group Health in 2011 to demonstrate national scale, secure, standards-based interoperability. 
• The eHealthExchange, a 2012 ONC public/private collaboration which turned the National Health Information Network (which had been renamed the Nationwide Health Information Network NwHIN at some point) into the eHealthExchange under the newly formed management organization Healtheway (now the Sequoia Group).
• A collaboration agreement signed in 2012 between Healtheway + CCC Coalition which gave Healtheway access to key CCC’s interoperability infrastructure services.
• Direct Trust, a new organization to support (but not administer) Direct secure messaging.
• CommonWell, a not-for-profit founded in 2013 by Cerner, McKesson, Allscripts, athenahealth, Greenway and RelayHealth
• Carequality, rolled out by the Sequoia Group (the quasi-governmental public+private org that the original ONC NHIN effort had morphed into), a ‘trust framework’ designed to connect health networks to other health networks in trusted, standards-based exchange to promote broad interoperability.
• The Strategic Health Information Exchange Collaborative, SHIEC, founded in 2014 to foster collaboration among Health Information Exchanges and their partners.  
• The National Association for Trusted Exchange, NATE, founded in 2013, which has struggled to find a role.   Their charter is to ‘address the legal, policy, and technical barriers that inhibit health information exchange between entities within a state and across states’.  Their activities historically seem mostly to consist of partnering with other group and agency activities, such as Blue Button, Get My Health Data, the Kantara Initiative’s consent work, and the Johnson Foundation’s Flip the Clinic effort. More recently they have waded into the very specific Patient Centered Medical Home interoperability space, and, even more recently, have created a framework for establishing trust for consumer-facing applications integrating with Direct.
• The CARIN Alliance, a bipartisan, multi-sector collaborative, formed by David Blumenthal, David Brailer, Aneesh Chopra, and Mike Leavitt in early 2016 to advance consumer-directed exchange of health information.
• The eHealthExchange (nee NHIN), which split off from the Sequoia Group and became an independent entity.

JASON

The late 2013 JASON report ‘A Robust Health Data Infrastructure’ triggered a significant change in the Interoperability strategy advocated by ONC.   JASON is an independent group of elite scientists which has advised the US government on technology issues since the 1950s.  (They recently lost their long-term contract with the Pentagon.)  Their report was extremely critical of the level of interoperability achieved under Meaningful Use, and challenged the ONC to “define an overarching software architecture for the health data infrastructure” to “provide a logical organization of functions that allow interoperability, protect patient privacy, and facilitate access for clinical care and biomedical research.”  The JASON report called for an interoperability architecture based on the orchestration of open APIs.

The ONC response was the JASON Task Force, which considered the report and came back with a clear recommendation to focus on achieving Interoperability through a coordinated architecture of public APIs using common data and documentation types.

The Argonaut Project

In the wake of the JASON report, in 2014 private industry rallied behind FHIR API support by creating the Argonaut Project.  (Jason and the Argonauts are characters from Greek mythology, perhaps best known in America from the 1963 movie about them – from which the still above is taken.)

Argonaut included a broad coalition of companies, including among others Cerner, Epic, McKesson, Surescripts, Beth Israel, Intermountain, the Mayo Clinic, and Boston Children’s.

In 2017, Argonaut published its ‘FHIR Data and Document Query Implementation Guide’, a major step forward in the broad adoptability of FHIR.

Other implementation guides produced by Argonaut include provider directories, scheduling, SMART app authorization, and CDS Hooks implementation.  (CDS Hooks is a specification for invoking decision support from a clinician’s workflow.  SMART on FHIR is a specification for integrating applications with FHIR APIs.).

In 2018, representatives from major technology companies including Amazon, Microsoft, Google, IBM, Oracle and Salesforce went to the White House to pledge support for the Argonaut project by removing barriers to interoperability and adopting FHIR for their health-related cloud architectures.

Argonaut continues to drive FHIR adoption with ongoing work on implementation guides.

MACRA

Driven by thinking that you can’t improve what you can’t measure, and you can’t measure what you can’t define, in 2015 the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) created a federal definition of interoperability, and direct HHS to create interoperability adoption metrics.

The 21^st Century Cures Act

The 21st Century Cures Act represents the federal government’s latest attempt to move the needle on health data Interoperability.   The bill is primarily about getting the National Institute of Health $6B dollars to streamline the approval process for new drugs and medical devices.  But many other line items were thrown in, including, in Title IV, ‘Delivery’, Section 4003: ‘Interoperability’, rules making information blocking illegal, and mandating ONC to “convene appropriate public and private stakeholders to develop or support a trusted exchange framework for trust policies and practices and for a common agreement for exchange between health information networks.”

TEFCA

The first draft regulation coming out of the 21^st Century Cures act was – is – the “Trusted Exchange Framework and Common Agreement”.

It mandates the standards and agreements to create a peer-to-peer network among existing health information networks (HINs) who have adopted the TEFCA standards and signed the Common Agreement, making them “Qualified” HINs.  The draft legislation had significant gaps and had vigorous comment from the industry.   Rinse and repeat, version 2 comments are now in.  The Sequoia group has secured the initial contract to be the national Recognized Coordinating Entity managing agreements and tech across the QHINs.

ONC and CMS APIs

The second draft regulation coming out of the Cures Act, and its twin sister from CMS, are draft rules that advocate the creation of FHIR-based APIs to enable consumer access to health data (using applications).    The ONC rule mandates the adoption of the US Core Data for Interoperability data standard, a refinement of the previous Core Clinical Data Set, by those APIs.   The CMS rule also mandates that Medicare payers participate in a trusted exchange.  (The rules address a number of other issues from the Act as well.)

Blue Button 2.0 is also rolling out – it brings Blue Button into the world of FHIR API-based software interoperability. 

Interoperability Standards

As we have seen, the history of interoperability is punctuated by the history of the evolution of interoperability standards.  

ASC X12N Healthcare

HIPAA formats were derived from the American Standards Committee (ASC) X12 electronic data interchange (EDI) standards as used in other industries.  ASC was chartered by the American National Standards Institute in 1979, and publishes standards for finance, supply chain, transportation, and government as well as insurance.

Existing paper-based standards such as the HCFA-1500 (later the CMS-1500) and UB-04 claims forms were mapped into ASCII text-based EDI data structures.  

The first generation of HIPAA standards, HIPAA 4010A, were a little ‘loose’ – they required so called ‘companion guides’ on the parts of implementers so the clients of those implementations would be able to work with them effectively.  The companion guides dictated exactly how those standards were interpreted by that particular implementer.

After more than 20 years of deliberation, the U.S. decided to adopt the International Statistical Classes of Diseases diagnostic standard version 10, ICD-10 starting in 2013 – to adopt our interpretation of it, and a companion proprietary procedure code standard.   These standards updated the previous generation ICD-9 standards, creating much finer-grained classifications.

Problem was, HIPAA 4010 did not support ICD-10.  Enter HIPAA 5010.

5010, which was rolled out in 2012, primarily laid the groundwork for the adoption of ICD-10. Another thing that HIPAA 5010 did was to bring more rigor to the specifications of the standard formats to reduce the variability of their interpretation across the industry and minimize or eliminate the need for companion guides.

HL7

On the clinical side, Health Level 7 standards have emerged as dominant.

HL7 grew out of the need for standards in early hospital data networks.   UC San Francisco developed a standard in the late 1970’s for its network.   When HL7 was founded in 1987, the UCSF protocols were adopted as its first version.   (It is called Health Level 7 after level 7 in the standard network protocol ‘stack’, where level 1 is the hardware and level 7 the application software, with switching and routing and connections and translation in between.)

HL7 is not a single, prescriptive standard.  It is more a toolbox of specifications which can be assembled as needed into a solution for a particular use case.    The recipe for such an assembly is called an ‘Implementation Guide’, or IG.

IHE

The Health Information Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA) got together in 1998 (both are headquartered in the Chicago area) to create what is now the granddaddy of clinical interoperability plumbing standards, ‘Integrating the Healthcare Enterprise’ (IHE).  The IHE standard is still in play, its adoption mandated in the current draft national Trusted Exchange Framework technical specification.

Like HL7, IHE is a large framework.   It supports different standard content formats, including HL7 Clinical Document Architecture data and DICOM (a medical imaging standard) data.

FHIR

IHE and HL7 had their roots in the mainframe era.   But with the advent of networked personal computing and the Internet in the 1980s and 1990s, new standards for general software interoperability emerged: web services.    These enable software applications to work together over the Internet.

The second generation of these are called REST services (‘REpresentational State Transfer – don’t ask : ), a standard which emerged in a backlash to the daunting complexity of the hairball the first generation standard (‘Web Services’) turned into.

By 2011, HL7 had become so huge, and so complex, that it had grown difficult to use in practice.   A task force was created to answer the question “If HL7 started again from scratch with a new specification, what would a good specification look like?”. 

Fast Health Interoperability Resources, FHIR, a lightweight, REST-based framework, grew out of that.   Graham Grieve, the primary author, posted the first version of the spec on his blog in 2011.

FHIR, like HL7, needs Implementation Guides to describe how it is to be used in a particular use case.

The Argonaut Project, emerging in response to the 2013 JASON report critical of the ONC approach to achieving interoperability, accelerated the adoption of FHIR by the industry.

FHIR, with its roots in HL7, is clinical and provider-centric.   The Da Vinci Project was founded to address the lack of FHIR capabilities supporting common payer use cases.

C-CDA, FHIR and USCDI Data

HITECH Meaningful Use dictated the adoption of a standard clinical data format.  HL7’s Clinical Document Architecture, CDA, was adopted.  But like all of HL7’s specs, it required interpretation.   Various organizations such as IHE who had already adopted or supported it had done their own Implementation Guides for the data standard.   So ONC, as part of the ‘harmonization’ under its Standards and Interoperability Framework effort, standardized the standard.  That became the Common Clinical Data Architecture, the C-CDA.

As part of the 21^st Century Cures driven regulation, ONC has specified a ‘higher level’ common data description called the US Core Data for Interoperability, or USCDI.  USCDI is not itself a standard for data interchange.   It is a level of abstraction above that – it is a standard that formally describes the data concepts and their relationships.   It is intended to ensure the interoperability of different interchange standards such as FHIR and C-CDA – if they have to conform to USCDI, the theory is that they can be readily, and accurately, translated from one to the other for a core set of health care concepts.

Standards for managing user’s access to APIs have emerged:   OpenID Connect is the standard for secure identification, and OAuth 2 is the standard for managing authorization to access resources.  Two other standards, User Managed Access and client authorization grants under the Unified Data Access Profiles, are in development to manage consent.

The Current Interoperability Landscape

We’ve described the current landscape as a patchwork of solutions.   While that is true, it does not mean we have not achieved some level of interoperability regionally and nationally.

HIEs

As a nation we have made significant progress in Interoperability.  A recent SHIEC survey shows that overall our Health Information Exchanges are serving 92% of Americans.

Direct

Direct just passed the 1B secure health messages served bar.

Cerner versus Epic

CommonWell and Carequality, which had been a thinly-veiled competition between Cerner and Epic, the two leading EHR vendors, for connectivity (with another major vendor, athenahealth, apparently playing both sides against the middle), have had a rapprochement.  They agreed in 2016 to have CommonWell become a Carequality implementer, create a Carequality-compliant version of its record locator service.   The connectivity was realized in January 2019 – now all CommonWell participants can interoperate with all of the other HINs that are part of Carequality.

To put the Carequality numbers in the graph in context, the American Hospital Association says there are about 6200 hospitals in the US.  So Carequality ‘touches’ about a fifth.   (It is much harder to figure out its penetration for providers and clinics.  The Census Bureau reported 25,750 outpatient clinics in 2002.  Statista.com reports 870,900 active doctors of medicine in the US in 2015.  The AANP reports 270,000 nurse practitioners.  The Journal of Nuclear Medicine reports 34,000 radiologists. The American Chiropractic Organization reports more than 70,000 chiropractors.)

Exchange EHRs Now

Clearly there has been a lot of bottom-up work on Interoperability since Administrative Simplification.  But the overall objective remains for every health care entity to be able to interoperate with every other entity when necessary.

As I mentioned in the introduction, the current primary focus of the national Interoperability initiative is on quilting together work that has already been done in an attempt to achieve national clinical Interoperability of electronic health records with the shortest practical time to market.

There are two key pieces of evidence supporting this.

First, in the 21st Century Cures Act itself, there is careful language supporting leveraging existing infrastructure:

• the trusted exchange framework is to be “develop[ed] or support[ed]”;
• the trusted exchange framework shall “take into account existing trusted exchange frameworks and agreements used by health information networks to avoid the disruption of existing exchanges between participants of health information networks”;
• and “the Secretary shall ensure the consideration of activities carried out by public and private organizations related to exchange between health information exchanges to avoid duplication of efforts”.

Second, in the second version of the draft TEFCA agreement, the technologies prescribed, and the use cases which survived, are those already supported by Carequality and Direct.  The 20+ year old IHE integration standard, not FHIR, is required plumbing.  The first production version of TEFCA effectively reads as a papal blessing of Carequality’s current state.   (A week after this was first drafted, ONC announced that the Sequoia Group, parent of Carequality, had been selected as the Recognized Coordinating Entity, RCE, for TEFCA.  The RCE is responsible for developing the Common Agreement TEFCA participants will be bound by, creating the detailed technical and legal requirements, and choosing and monitoring the Qualified Health Information Networks (QHINs) which can join TEFCA.)

Consumerism Drives Change

This focus on backwards compatibility with existing Interoperability infrastructure, while necessary in the near term, has bifurcated our national strategic focus and introduced a tension that will have to be resolved.

As we all know, the rise of consumerism in health care and the concomitant rise in consumers’ use of smartphone, tablets and PCs is driving more radical change in the health care economy.

The question of how best to serve the Interoperability needs of connected consumers has a much different answer than the IHE-plumbed, backwards-looking first draft of TEFCA can provide.

The JASON report first clearly pointed out the right direction.  The ONC and HIT’s consumer API regulation is directionally correct.  The work of CARIN is directionally correct.

The key battleground of the resolution of the stream of provider-focused Interoperability which has issued since IHE was founded, and is now channeled through TEFCA, and the stream of Health 2.0 applications serving consumer needs via the API economy, will be in identity, consent and privacy management.

The regulatory stance for identity is the mandated adoption of the NIST 2-level (IAL2, AAL3, FAL2) standards for identity proofing, authentication, and federation.     Achieving IAL2 requires the review of proof-of-identity evidence such as drivers’ licenses and passports.   While most providers can do this in person, companies whose consumers are remote, such as payers and Health 2.0 software vendors, will be challenged to acquire and deploy the capability to do such identity evidence validation remotely.  Solutions in the identity space will continue to evolve.    The dialog around national unique health identifier is spinning back up.   But the timing with respect to achieving the mandated NIST standards may well prove problematic.

Privacy and Consent Center Stage

Privacy and consent issues have also moved to the fore.  

The HIPAA Privacy Rule, which has been in effect for over 15 years, provides both regulation and guidance for covered entities with respect to the use and disclosure of personal health information without patient authorization.  For treatment, payment, and health care operations, the Privacy Rule does not, however, require patient consent to be obtained.

Interpreting and applying the aging HIPAA regulation in the situations arising in today’s technology world has attorneys poring over the regulation like Kabbalists trying to interpret the sacred texts.

Making it even more complicated, there is a landscape of overlapping federal and state regulation beyond HIPAA that may apply in a given situation depending on the parties involved and the nature of the data.

There is a worldwide trend to give individuals more control over their private data.

The European Union’s  General Data Protection Legislation, GDPR, effective in May 2018, and California’s similar consumer privacy regulation the California Consumer Privacy Act, CCPA, which becomes effective 1/1/2020, give citizens the right to know what data is being collected about them, to be able to access it, to know if it is being disclosed, and to whom, to opt out of  having their data sold, to have their personal identity data deleted on demand.   California’s law applies to businesses with over $25M gross yearly revenues, those who possess personal information of 50k or more individuals, and those which earn more than 50% of their revenue from selling personal identity data.

Nevada and Maine have already passed similar legislation.   And over 20 other states have introduced or considered legislation around consumer privacy this year.   Among Regence’s four states, Washington considered legislation (modeled more after the GDPR than the CCPA) but is failed to emerge from the Washington House and will be reconsidered next year.

In health care, HL7 (and FHIR’s) Data Segmentation for Privacy, DS4P, speaks to how to structure data to make privacy protection actionable, a necessary prerequisite to implementing privacy policies around its access.

The IHE framework provides for what it calls basic and advanced patient privacy consent management.  But privacy and consent management look to be the least-finished parts of the draft TEFCA legislation, and many concerns about them were raised in comments to ONC.

In the context of the consumer API legislation, identity and authorization to access data are effected with the Open ID Connect and OAuth 2.0 standards.  But conformance with the HIPAA privacy laws is the established bar.

The Future of Interoperability

We have five or more years of continuing churn to expect in Interoperability.

TEFCA will achieve some level of national provider interoperability.   But the API efforts under the current draft ONC and CMS regulation, coupled with new Trusted Payer Exchanges, will bypass TEFCA in its current form and begin to deliver broad FHIR-based interoperability without the IHE overhead.

The current conceptualization of Interoperability is based on the exchange of data.  This is an artifact of the batch-file data exchange perspective we all share from our legacy computing past, the focus on exchanging EHRs that has been a key driver since Meaningful Use, and the appetite for large datasets we all have to meet our emerging analytics needs.

Interoperability is about establishing automated business processes that span organizational boundaries.   Our focus will increasingly turn to identifying, establishing, and maintaining those processes, not just on the data part of them.   Those processes will increasingly become near real time.

Identity and privacy management will demand the creation of a national healthcare identity and associated electronic credential.  (Please refer to an earlier post for my rationale on the need for the credential.)   Our path until its emergence, which, given the political opposition to it, will take years, will consist of short-lived solutions which address parts of the overall problem.  State-level electronic credentials will emerge before a national healthcare credential – California has already implemented one – so those electronic state credentials will become defacto health care credentials.

The key interim technology need is for a mechanism for dynamically establishing trust in a federated Identity Provider (IdP).    Unlike the European Union, where a small number of national IdPs makes it possible to configure each in advance, in the US we will have hundreds or thousands to start with (though they will tend to aggregate over time until There Is Only One).  A consumer using one of a zillion apps will come knocking at the door of a resource provider – a Service Provider (SP) in the identity security lingo – and say, here is the IdP I use, who can authenticate me and provide details about my identity.   Obviously, given potentially hundreds of IdPs, the SP needs to be able to dynamically vet the quality of identity and quality of authentication that IdP serves up.   So we start with a Good Housekeeping Seal of Approval such as the Kantara Trust Mark, then evolve it into a verifiable credential that can be used to quantify the quality of identity and auth according to NIST 63.3 standards (for now – they are still pretty coarse-grained.)

HIPAA privacy laws will be necessarily superseded by newer federal legislation that speaks to the emerging strong consumer privacy mandates across the country.

Technology evolves faster than law.   This is an across the board challenge for regulation of all kinds, not just health care.

Current legislation around interoperability attempts to deal with this in part by making the laws themselves generic, and deferring the specifics to regulation, which evolves more quickly.   But regulation has its own overhead, and its own yearly cadence.     The ONC is working to address this challenge.

In the current environment, the legislation of specific technology serves as a sea-anchor:  it provides much needed stability, as the cost of slowing progress.

HIPAA transaction standards are based on a now over 40-year-old model.   

FHIR, the current poster-child for Interoperability standards, is based on the REST service methodology.  But REST is not the longer-term future of Interoperability:  REST is already giving way to newer standards which address REST’s shortcomings, such as gRPC+protobuf and Thrift.

By the time FHIR has widespread adoption, it will be another sea anchor.

What will necessarily emerge to replace the legislation of specific technologies will be the legislation of technology-independent concepts and relationships and the logical rules which describe their interactions.   These concepts and rules may be implemented in any number of technologies.

The United States Core Data for Interoperability specification moves in this direction – it is not a specific implementation standard, instead describing core health care data elements in a more generic way.

In HIMSS’s definition of Interoperability, they speak to four levels of  interoperability:  foundational, structural, semantic, and organizational.   (To be clear, all four levels are necessarily present in every interoperability solution – HIMSS is talking about the explicit management of a level in a broad, standards-based way.)  Interoperability legislation currently targets the foundational and structural levels.   It will mature to address the semantic level.

We will see the emergence of a national health care ontology – a national knowledge graph – to meet that need.    This may come out of Google, whose Knowledge Graph in support of the web is already mature, and whose AI leadership is strongest among the major software companies.

Stay tuned.

(I am indebted to the redoubtable Margarit Gur-Arie, whose 2013 ‘Game of Interoperabilties‘ blog post is the single best resource I found for the ‘insider’ history of Interoperability.) Mark Lukaszewski has published an informed perspective on the history in the Bulletin of the American College of Surgeons. Cerner’s John Glaser wrote an interesting article in 2016 for HH&N analyzing the evolutionary path of Interoperability. Micah Zirn’s 2019 Wharton thesis on FHIR provides a detailed, cogent technical and historical context.)