Interoperability Redux, & Redux, &...

“We really need to drop interoperability as a competitive differentiator in this industry. Once everyone comes to the table and recognizes that we have a moral obligation to provide patients with their health records, I think we’re going to be much better off.”

Zane Burke, President, Cerner Corporation

The ONC (Office of the National Coordinator for Healthcare Information Technology) issued its Draft 2017 Interoperability Standards Advisory last week. It has issued an interoperability advisory yearly since 2015, the year after it issued its 10-year vision for healthcare information technology (HIT) along with its interoperability roadmap. I reviewed these efforts at the time[1] & more recently I wrote: “In June of 2014, “The Office of the National Coordinator for Healthcare Information Technology (ONC) published its 10-year vision for health information technology (HIT) in the U.S.  Interoperability among HIT components was a primary & enabling aspect of this vision. Subsequently, they also published a roadmap for such interoperability that covered in some detail the technical, administrative & regulatory tasks & issues associated with achieving interoperability in the healthcare space (…). I was generally skeptical of what I saw as an effort that emphasized standards development & adherence as well as a certification process similar to the Meaningful Use process that I have not seen produce results other than software that is compliant with the test criteria, but not especially usable or useful for healthcare organizations (at least in my experience & opinion).”[2]

In that post, I defined interoperability (I14Y, geeky contraction) as “the design criteria that allow independent software systems to share information, function & workflow with each other”. In healthcare, we are just trying to provide information sharing, even though in other industries I’ve worked in (financial systems, discrete manufacturing: auto, aero) we have achieved functional & workflow integration as well. The ONC started specifying how important information integration is to healthcare long before it published its 10-year vision. We have been talking about & attempting to provide minimal levels of integration for at least 10-12 years. Integration is both the actual work done to achieve I14Y & the state of the systems that have this work performed. We say they are integrated. Given the focus that the ONC, HHS, CMS, DoD etc. have had on interoperability, what is our state of integration in HIT & what does the 2017 Advisory tell us about it?

The Advisory is in four sections with three appendices as follows:

1.  Section I: Best Available Vocabulary/Code Set/Terminology Standards and Implementation Specifications
2. Section II: Content/Structure Standards and Implementation Specifications
3. Section III: Best Available Standards and Implementation Specifications for Services
4. Section IV: Questions and Requests for Stakeholder Feedback
5. Appendix I – Sources of Security Standards and Security Patterns
6. Appendix II - Revision History
7. Appendix III – Responses to Comments Requiring Additional Consideration

The first three sections specify the standards that are relevant for each of the subtopics covered. Section 1: Vocabulary has 22 subsections. Section 2: Content/Structure has 14 subsections & Section 3: Services has 8 subsections. Each subsection covers a specific HIT area that is relevant to clinical use & regulatory reporting. These subsections range from such topics as care plan to ePrescribing to public health reporting. 35 separate standards are cited as being required for interoperability to be provided, i.e. for integration among systems to occur. Many of these standards, by ONC’s own admission, are in early stages of adoption – some only in the proposal stage. Standards range from established practice such as ICD-10, LOINC, SNOMED or HL7 CCD & a variety of IHE messaging standards (XDR, XDS, CHD etc.) to HL7 V3 CDS & FHIR. In addition, Appendix 1 lists nine IHE security standards & 16 other security standards (NIST, FIPP OpenID, OAuth,…) for a total of 25 security standards that are recommended. This is a total of 60 (!) standards either required or recommended by the ONC to meet interoperability (& integration) requirements.

I have been designing & developing software for 25+ years &, at least in my experience, it is not possible to provide adherence to 60 standards in any one software system. The only way this is possible is to partition the system by function (or by user) & attempt to provide standards conformance within each partition. I have done this is several singular instances, most notably with respect to the OMG interoperability standard (of which I was co-author). The result was several incompatible systems from major vendors (including Digital Equipment, IBM, Sun Microsystems & HP). As I have written elsewhere, we accepted the Sun Microsystem’s representative’s view of interoperability, which was if my system sent his system a well-formed request for data; his system could send my system an error message. The problem, not just with complex ecosystems of standards, but even with single standards is that if they apply to important function, is that vendors have already developed architectures, infrastructure & application level software that may or may not have anything to do with adherence to the “standard”. An example from healthcare that I was involved with would be the New York eHealth Collaborative (NYeC). While a (way too large) committee was working on the overall architecture for New York statewide health information exchange, individual RHIOs & HIEs were adopting vendor solutions that did not conform with, & were unlikely to conform with, the “standard”. Once adopted, deployed (& paid for…), it was very difficult to get the individual healthcare organizations or vendors involved to move toward a standard architecture that did not represent the implementations already in place. I have seen this same situation repeated several times in healthcare.

So, again, in my experience, just specifying a set of standards is not a solution for interoperability. This is especially true if many of the standards have been developed independently & not in conjunction with other standards in the proposed set, as is the case in the ONC proposal. It is also not realistic to expect vendors to conform to standards that may be less effective & performant than their current products & architectures. Providing ways of testing software against such standards often just gives testing organizations the opportunity of reporting on the lack of conformance of products that may already be in use. The situation with the ONC interoperability set is more complex.

An example would be the Consolidated Clinical Document Architecture (C-CDA). C-CDA is an extension of the HL7 Clinical Document Architecture using XML templates to represent specific clinical (patient) data. It references HL7 CDA 2.0 & HL7 V3 Reference Implementation Model (RIM). C-CDA has nine (9) sections for different data sets including: 1) continuity of care document, 2) consultation note, 3) diagnostic imaging report, 4) discharge summary, 5) history & physical note, 6)operative note, 7) procedure note, 8) progress note & 9) unstructured document. C-CDA uses XDR (external data representation) as a serialization format for data transmission (originally proposed by Sun Microsystems & now an IETF standard) & XDS (cross-enterprise document sharing), an IHE standard for document sharing as its format & network transmission standards.

I’ve had a good deal of experience with C-CDA, most deeply as a technology consultant to a start-up doing medication reconciliation. As part of their certification to be able to use SureScripts data, they had to be able to pass SureScripts C-CDA testing. We (myself & a team of the CTO & two programmers) worked for about 4 months to get to the point where this was possible. The majority of the issues we had were with the substantial ambiguity in the C-CDA standard, the huge verbosity & redundancy in the C-CDA format & issues with how different EHRs used XDR/XDS. I knew at the time that our experience was not unique, but it was with mixed feelings that I read the SMART C-CDA Collaborative study[3] that sampled information exchange from 107 healthcare organizations using 21 different EHRs. Using two different testing regimes, they found 615 errors in their sample across six broad error categories. They concluded: “Although progress has been made since Stage 1 of MU, any expectation that C-CDA documents could provide complete and consistently structured patient data is premature. Based on the scope of errors and heterogeneity observed, C-CDA documents produced from technologies in Stage 2 of MU will omit key clinical information and often require manual data reconciliation during exchange.” This is just one example of the ONC proposed standards being ineffective &/or premature.

OK – interoperability is not totally easy (although it’s not as hard as we have made it in healthcare). How have we solved this issue in other industries? I know, we can’t compare healthcare to other industries,… well actually most of the people who have asserted that to me haven’t worked in other industries, & I believe that we have a good deal to learn from how other industries have addressed technical issues.

I have been involved with I14Y efforts in several other industries, most notably in aerospace (Boeing Commercial Airplane Company, BCAC), Auto manufacturing (General Motors) & financial services (Goldman Sachs as a consultant to Ernst & Young Global Financial Services). The two projects in discrete manufacturing were quite similar. Boeing was attempting to develop a completely digital design process for the 777 series. Up until this time, their design process had used a combination of paper designs, digital (mostly CAD-based) designs, massive bill-of-material spreadsheets used in paper form & several very large bill-of-materials database systems (~80,000 tables). I was the architect for Digital Equipment’s relational database, Rdb/VMS at V1 & V2 that Boeing was using, so they approached me to assist with this project. There were on the order of 100 different digital & paper-based systems that needed to be consolidated into formats & applications so they could be stored & operated on digitally. A diverse team that included design engineers, manufacturing engineers, engineering-manufacturing experts, front-end data specialists, database specialists & even pilots & managers was assembled. Work proceeded on three paths: 1) standard definitions for resources across design, engineering & manufacturing silos, 2) standard formats for all resources, 3) programming interfaces (APIs), transport protocols & workflows for information storage & sharing. The effort was lead by a Boeing Engineering Fellow & an Executive VP. Definitions & formats were developed & reviewed in about nine months, APIs & workflows were available in about a year & a testbed was in place & functioning after about 14 months (from the start of the project).  This effort produced an integrated system that functioned to align the design, engineering & manufacturing process for the 777 commercial airplane. It included thousands of definitions & data formats, a small number of APIs & allowed information across organizational & functional silos.

The effort at General Motors, called C4, was similar in structure. GM created the C4 “car company” – nothing got done at GM at that time unless it was done by a “car company”. C4 was responsible for developing a paperless design system that shared information with engineering & manufacturing. The difference with the BCAC effort was that the GM organizations were not well aligned & many, such as Powertrain, were not committed to the C4 goals or project. C4 never got very far despite a very large commitment of resources (financial & organizational) from GM.

The Goldman Sachs effort was smaller. Its purpose was to be able to integrate the results from several trading systems to be able to produce a synthesized view of capital flows, gains & losses in near real-time. The project was a must have & was initiated by Goldman’s then Chairman & CEO John L. Weinberg, who made it clear that this was to get done. Ernst & Young was brought in to provide project expertise & project management & I served as a consultant to E&Y (I was at Digital Equipment at the time). The project was similar to the ones in discrete manufacturing as it emphasized standardized vocabulary & formats as well as an information bus to share data & function. The whole project took 9 months & resulted in a system that was in use for about 10 years before it was rewritten to be web-centric.

What are the similarities among these projects that we can learn from, both positively & negatively

• Executive understanding & sponsorship is essential. No project as complicated multisystem integration will succeed without this. Buy-in must also occur at operational levels so that priorities & resources are properly set & utilized.
• The Boeing project had both executive sponsorship & operational buy-in. It was solving a problem that everyone agreed was in the interest of the company to be solved.
• The Goldman Sachs project also had this & even though it was a smaller project, it was both technically complex & organizationally & culturally challenging, so the CEO’s imperative was necessary & effective.
• The GM project had executive buy-in, but not much focus. It did not have operational buy-in in the car companies (Chevrolet, Cadillac, GMC, etc.) or in the functional units (Design, Powertrain, Components & Subassembly, GM Research etc.). The primary operational manager was a long-time GMer from Pontiac racing & Chevrolet, but not even he could get the various groups to cooperate.
• My experience on this aspect of the issue in healthcare is that it is more complicated. None of the private sector projects had regulatory requirements to meet (except for Federal & international safety standards) or that specified what standards were appropriate. There is no one “CEO” who can decide to “make it happen”. Instead, thousands of CEOs must be convinced of the necessity of integration. Often this is only through the leverage provided by regulation. Vendors have much more leverage in healthcare – there are many more of them & they are already established in many segments of the industry. If you are a CAD vendor, losing Boeing’s or GM’s business could be catastrophic. If you are Epic or Cerner, losing a single healthcare organization’s business is not as big a deal (unless it’s the VA or DoD or maybe Partners or Kaiser, although Kaiser seems pretty set).
• Normalization matters! – No integration project can succeed without the effort to develop & agree on a common vocabulary & common formats for static storage & use of data. The same is true for in-transit formats & processes.
• The Boeing project spent more time on this than any other aspect including coding & deploying the solution, & it was the primary reason (IMNSHO) that the project was as successful as it was.
• A recent study that I lead[4] looked at data quality in EHRs & readiness for analytic capability at Federally Qualified Health Centers (FQHCs). One of the primary issues with data quality found in the study was the use of non-standard definitions for core concepts (patient, encounter etc. even though the Bureau of Primary Care (Health Resources and Services Administration, HHS) publishes & requires standard definitions for the reporting that FQHCs do. The only health centers in the study that generally did not have issues with normalization were the ones that had done substantial work on this in order to populate a data warehouse. 
• Broad participation improves design & practice. – Including stakeholders & end-users as well as technical specialists ensures that the function developed is both usable, that is easy & convenient to use, perhaps even transparent & useful, that is it solves the users’ & stakeholders’ problem, not the problems of interest to the technical experts.
• Again, the Boeing project was the leader here as the project committees all had very broad representation from both the user base & technology groups. The model really was that all perspectives were welcome. Did this work perfectly in practice?... No, of course not, but it worked well enough that the solution when deployed was used as intended.
• The GM project had an interesting aspect that I was involved with. The EVP who was the head of the “C4 car company” contracted with the urban & industrial anthropology group at Wayne State University & Marietta Baba (then Professor of Anthropology at WSU, Assistant Professor of Anthropology at Michigan State University) ran a project to study GM groups as separate cultures[5]. The results of this study allowed me (& other technologists to design technology adoption & transfer processes that were much more effective than if we knew nothing about the organizations.
• None of these successful projects were “standards-based” except to the extent that standards already existed & were in general use. The Boeing project used some definitional & functional standards where they provided better ways of solving a problem, but the Goldman Sachs project was proprietary.
•  Neither the Boeing nor the Goldman Sachs projects required the development of products or applications that needed to support standards other than those that were already in use by the organizations. No new standards were required. Among the many reasons that the GFM C4 project failed was its requirement of many new standards, not all of which were already in use as well as the adoption of a new operating system (Berkeley Unix).
• While it could be argued that the majority of the ~60 standards referenced in the HHS I14Y roadmap are already in use, it is actually the case that many of the transport & security standards are not currently in use in healthcare, and that even many of the “healthcare” standards are not in general use. Several of the are also controversial, such as C-CDA, even though they are required. As a whole, this standards ecosystem is not in use as a coherent whole in healthcare at this time.

So what do these lessons tell me about interoperability in healthcare,… here’s some thoughts:

• We need more than the ONC or CMS to mandate interoperability. Regulations cannot ensure that we’ll meet this goal in 2017, 2018 or at any time… We need a bottom-up movement toward it because thought & operational leaders have decided to make it a priority. This not just true of I14Y, but of any goal we expect to actually achieve.
• We need a roadmap that is not a listing of standards, but rather a compilation of tasks that need to be done first to get ready for interoperability & then to achieve it. Foremost among these is the development of consensus around definitions & processes. It may appear that this is not possible, but I believe that if we have the will to develop such a consensus, we can & will do it. Once this is in place, I14Y becomes much simpler, if it is not, then any interoperability of information exchange has to be done on a one-to-one basis, essentially as a one-off effort that will need to be changed whenever a definition needs to be added or modified.
• We need to include a broader range of people in the effort to understand, plan & achieve I14Y. This ensures that the capabilities that are developed & deployed meet the actual needs of the people who will use the information provided by the integration.
• In light of this, we need to have better understanding of the operational & business models that require integration. HIEs, ACOs etc. have not had compelling operational models & have presented less than successful financial & business models. I believe there are compelling reasons to develop this capability – we just need to agree on them.
• Finally, we need pragmatic approaches to a solution. Trying to provide general solutions for all possible situations is not possible. We need to develop some specialized solutions (some that may be able to be generalized), deploy them & get experience using them in order to understand what is needed, how the solution will be used & how to provide it.
• Direct is an excellent example of this. The use of Direct for provider-to-provider exchange of clinical (& other) information has been successful because it provides a (relatively) simple solution to a specific problem.
•  FHIR may be another example. The recent announcement by the Regenstrief Institute that it will develop & test a “point-to-point? HIE using the HL7 FHIR technology is an example of the type of experimentation & innovation that will provide solutions to the integration conundrum. Providing practical ways of addressing specific critical problems will go a much longer way toward creating an integrated healthcare ecosystem than requiring the use of multiple, overlapping standards & counting on vendors to implement products that are compliant (in some vaguely defined way).

We need to agree on why we are focusing on I14Y, not just that we have to. Once we are agreed on motivation & the practical uses & advantages of interoperability, it will be much easier to develop & deploy the technologies that will enable these advantages.

---

[1] http://posttechnical.blogspot.com/2014/07/the-onc-interoperability-vision-opinion.html, The ONC Interoperability Vision: An Opinion, & http://posttechnical.blogspot.com/2014/07/the-learning-healthcare-system.html, The Learning Healthcare System. Both in July 2014.

[2] http://posttechnical.blogspot.com/2016/02/healthcare-information-technology-next_17.html, Healthcare Information Technology: The Next 10 Years. February 2016.

[3] D'Amore, J.D. et al. 2014. Are Meaningful Use Stage 2 certified EHRs ready for interoperability? Findings from the SMART C-CDA Collaborative. DOI: http://dx.doi.org/10.1136/amiajnl-2014-002883 1060-1068 First published online: 1 November 2014

[4] c.f. Path2Analytics Project: Process & Results Review. Association of Clinicians for the Underserved Annual Conference. Washington, DC. June 1-3, 2015.

[5] c.f. https://msu.edu/~mbaba/documents/MajorApplicationProjects.pdf. Also: https://msu.edu/~mbaba/

Healthcare Information Technology: The Next 10 Years

   “Black holes, we all know, are these regions where if an object  falls in, it can't get out, but the puzzle that many struggled with over the decades is, what happens to the information that an object contains when it falls into a black hole. Is it simply lost?”

  Brian Greene, Professor of Physics & Co-Director, Institute for Strings, Cosmology & Astroparticle Physics, Columbia University


  (1)

In June of 2014, The Office of the National Coordinator for Healthcare Information Technology (ONC) published its 10-year vision for health information technology (HIT) in the U.S. (2)  Interoperability among HIT components was a primary & enabling aspect of this vision. Subsequently, they also published a roadmap for such interoperability that covered in some detail the technical, administrative & regulatory tasks & issues associated with achieving interoperability in the healthcare space. (3) I reviewed these proposals in several blog posts last year.(4) I was generally skeptical of what I saw as an effort that emphasized standards development & adherence as well as a certification process similar to the Meaningful Use process that I have not seen produce results other than software that is compliant with the test criteria, but not especially usable or useful for healthcare organizations (at least in my experience & opinion). In any case, it’s six months later & I wanted to review what was proposed, what I thought about it & where I think we’ll actually be in mid-2024 with respect to HIT & healthcare in general.
First, a review… The 10-year vision is described as follows in the ONC vision document:“An interoperable health IT ecosystem makes the right data available to the right people at the right time across products and organizations in a way that can be relied upon and meaningfully used by recipients. By 2024, individuals, care providers, communities, and researchers should have an array of interoperable health IT products and services that allow the health care system to continuously learn and advance the goal of improved health care. This “learning health system” should also enable lower health care costs, improved population health, truly empower consumers, and drive innovation. For example, all individuals, their families, and care providers should be able to send, receive, find, and use health information in a manner that is appropriate, secure, timely, and reliable. 
Individuals should be able to securely share electronic health information with care providers and make use of the information to support their own health and wellness through informed shared decision-making. An interoperable health IT ecosystem should support critical public health functions such as real-time disease surveillance and disaster response, and data aggregation for research and value-based payment that rewards higher quality care, not necessarily a higher quantity of care.” 
The salient points of this description are an HIT system that:

• Provides fully interoperable products & services
• Exhibits continuous learning such that the system is able to:
• provide higher quality care to individuals
• lower the cost of this care
• improve population health
• empower consumers
• Provide appropriate security & privacy for all functions
• Provide data aggregation for both research of various types & develop/use of value-based payment

My choice of the image & quote at the beginning of this article was deliberate. I do think that we are in danger of a trying to overachieve by dumping a huge amount of information & effort into what is essentially a black hole – OK, so maybe that’s an exaggeration, but not much of one.

The ONC’s vision is all about integration & learning systems. These are good foci, but does the vision actually mean to design & implement a system that enables integration? Or one that “learns”? So we have to define what we mean by integration (& then learning…), first integration. There are really two technically relevant terms here - integration & interoperability. The first has been the object of a huge amount of discussion, writing, prototyping & product development, while the second, & arguably the more important capability, has barely been mentioned. OK - it hasn’t been mentioned at all. This is another example of the scope of people working in healthcare who have not worked in other industries (just as healthcare isn’t a market, it also isn’t an industry, but that’s a topic for another day…). 

Some time ago , I wrote about the interrelationship of interoperability, integration & standards. As a software architect who has designed & led the implementation of a number relatively successful systems  & consulted on the development of many others, I have come to my own understanding of these terms as follows:

• Interoperability – the design criterion that allows independent software systems to share information, function & workflow with each other – This “ility” has to be designed in from the beginning (or a good deal of cost for redesign & reimplementation can be incurred).
• Integration – the work done to implement the interoperable design – When performed effectively, independent software systems can & do effectively share information, function & workflow at both user & system levels.
• Integration has often been seen as an after-the-fact issue. To this end, a whole category of systems has been developed – integration busses. These systems do point-to-point connection & usually proprietary translation & sharing of data, often through standards such as HL7 (at least in healthcare)
• Standards – the set of guidelines for the design & implementation of a (software) system so that some specific purpose, such as informational interoperability, can be realized.

My current view is that a substantial amount of attention has been paid to integration & standards in the ONC’s vision, but very little to actual interoperability. Standards are seen, in the vision, as the mechanism for providing integration of data. What does this actually mean? & Why is it important? As long as I have been developing software, I have been involved in standards efforts . Even the most successful of these, for instance the development of the V1 SQL standard in 1986, was marred by considerable acrimony & noncompliance which resulted in a flawed (IMHO) standard that because it was so useful was able to both enable substantial improvements in query efficiency & effectiveness for relational databases even as it cemented the differences among “compliant” (& brand-based) implementations. My personal favorite questionable inclusion (that I opposed) in the SQL standard is the allowance of stored procedures which have been used both to very good effect & also made many query programs opaque & impossible to debug &/or interpret. Another favorite example, that I’ve written about before, occurred during the “debate” over CORBA interoperability when the representative from another company (Sun Microsystems) told me (I was representing Digital Equipment) that his definition of interoperability was that my system could send his system a properly structured request for information & his system could send mine a (properly structured) error message… “See, we’re interoperable”.

Personal anecdotes aside, the development of standards, like the development of software systems, is done by individual engineers & programmers who work for some entity (it could even be themselves) that has a vested (commercial &/or personal belief) interest & therefore an agenda that may or may not be aligned with creating the most effective & productive design for users. Even in open source development, an individual’s personal beliefs & biases are often imposed on a design to the detriment of its overall effectiveness (as witness what is happening in the Bitcoin community currently) . A good example of this of this is the work that was done on the SHIN-NY (State Healthcare Information Network – New York) architecture, developed by the New York eHealth Collaborative (NYeC), & intended to “enable widespread interoperability among disparate healthcare systems”  & to promote healthcare information exchange. The architecture was a multi-layer, integration bus dependent design that provided for connectivity, data modeling & storage, data exchange, interoperability orchestration & data integration. It was based on the functionality defined by ONC/HHS for the NHIN (later called NwHIN ) & depended on XML for data definition & transport (SOAP & WSDL) as well as the UDDI (universal Discovery & Description Interface) . At the time, I was acting as a consulting architect to the SHIN-NY committee. The committee was an issue in itself (over 30 members from hospitals, vendors, consultants, etc.), but that’s another story. The real issue (IMNSHO) was that the RHIOs (Bronx RHIO) & HIEs (BHIX, LIPIX, now both Healthix) & others had substantial grants from New York State & had already selected vendors to provide information management & exchange capabilities. Of course, all of these selections changed (many times) subsequently, but that is another issue & did not affect the point here,… which is that all of these vendors already had product & exchange architectures that were for the most part based on proprietary technologies that they considered their leverage (& which in all cases performed much better than the SHIN-NY prototypes). These vendors were not going to change their products or their deployments to match the design of the NYeC, especially since they had already been paid (with State money). The analogy with current ONC interoperability is, to me, striking & instructive. Current EHR systems have, almost exclusively, been designed as independent products. In fact, many EHR products do not “integrate” well (share data) with other offerings from the same vendor. Real work is needed to have such products share data in any meaningful or useful (choice of words deliberate…) way. This is despite the standards compliance claimed by many EHR products. At a minimum, C-CDA documents may be created, messaged to another system (often by the Direct protocol), & partially consumed or at least displayed by the second system. This would be fine if C-CDA provided an unambiguous data stream, but as John Loonsk (previously Director of Interoperability & Standards at the ONC & now at the Bloomberg School of Public Health, Johns Hopkins University) says: “…the C-CDA can be many things. It is almost infinitely extensible and the C-CDA support process does not have a history of providing strong constraints. As a direct result of the lack of a technical plan or architecture that targets the functional need, we now have numerous C-CDA variants, gigabyte-sized C-CDAs that providers rebel at receiving, at least five groups seeking to constrain C-CDA messages (will these be five new standards?), and we have few of the potential interoperability benefits. The C-CDA is not the target; it is a tool that if properly used could help get to it. A technical plan would clarify this relationship.”  Now we are looking at FHIR based on the REST protocol, but again, most vendors do not use FHIR, REST, JSON etc. & do not plan to convert their products anytime soon.
We haven’t even begun talking about functional & workflow interoperability. This is important because of the large number of data & information sources that healthcare organizations will need to access in order to be able to actually operate in the near-future care environment. As care transition becomes more & more important (& measured as part of pay-for-quality systems), the ability to share application function & user workflows across organizations will need to be addressed. eReferral is more than just sending a Direct message out into space (even if that space includes dual-endpoint identity verification). It requires the ability to seamlessly pass off data, functional capability & a shared workflow to the consultant & to receive it back. No systems (that I’m aware of) are currently planning for this, although it certainly should be part of a 10-year vision.
Let’s talk about learning for a minute. I wrote about the learning healthcare system back in 2014 . At that time, I discussed what a learning system might be, what work had been done historically & what types of systems already existed. In that piece, I wrote, “…learning can be thought of as “the ability to develop new knowledge & strategies for using that knowledge based on an understanding of current & previous results & information”. This ability is continuous & ongoing, the implication for a healthcare system is that whenever an actor (provider, patient, caregiver &c.) is using a part of the system, the system is moderating the user’s context (usage) & anticipates what information & analysis may be relevant. The system may then give the user the opportunity to request this information; which can be diagnosis, treatment suggestions, data on treatment, analysis of alternatives, public health implications, information & recommendations on amelioration of social determinants & many other possibilities.” This seems like a lot, so let’s break it down into what capabilities such a system would have to have:

• Ability to identify context (patient interaction, diagnosis process, provider request, patient request, research request etc.) & identify information & analysis relevant to this context
• Ability to access to substantial amounts of both healthcare & non-healthcare related data
• Ability to analyze & interpret this information in useful ways
• Use of statistical & BI type analyses
• Use of analytics for ultra-large data set analysis (structured & unstructured data)
• Formation of hypotheses & hypothesis testing
• Ability to make recommendations in multiple contexts (clinical, operational, financial,…) using these analyses
• A user experience level that works for multiple contexts & user types (providers, researchers, patients, caregivers, public health & policy workers, etc.)

Obviously, at least to me, we are not quite there yet with respect to this list of capabilities, but where are we? The closest HIT systems we have to this are the point-of-care recommendation systems being developed & evolved by several large healthcare organizations (Kaiser, Partners, Geisinger, Mayo,…). These systems analyze & look for patterns in conditions, treatment plans & outcomes in very large clinical data sets & make recommendations for diagnosis & treatment when an individual patient’s data is entered, usually at the point-of-care. Systems like “Dr. Watson” (IBM) also provide capabilities like this. The learning takes place as patterns are recognized & classified & these patterns are reused to make recommendations. Several of these systems, Watson is the best example, develop hypotheses based on data & related patterns & do hypothesis testing based on these intermediate constructs in order to determine a “best” set of recommendations. Eventually similar systems will be available (or the current systems will evolve onto commercial versions) that will allow healthcare providers to utilize the results of this learning for both research & treatment purposes. We are looking at 3-5 years (IMHO) before these systems are broadly available. There are, of course, other paths to learning in HIT systems, but this is the least resistance path I can see right now…
So the ONC vision concentrates on integration & learning for its 10-year roadmap. These are interesting & appropriate foci, but… I think there are much higher priority issues that must be addressed during this 10-year timeframe in order for HIT to evolve to be truly useful to all parties involved in healthcare relationships. What are these issues & where are we with respect to them? I thought you’d never ask:

• HIT systems, & especially EHR systems must be rethought, redesigned & reimplemented. EHR systems, as they currently exist, are designed primarily as billing, reimbursement & compliance measurement systems. They have very little to do with patient treatment, care transitions, preventive medicine & in particular they are not at all aligned with provider workflows. In addition they are difficult to navigate & do not facilitate best clinical practice… OK, tell us what you really think. I know that many vendors will speak endlessly about how their products do many or all of these things adequately, but talk to providers (note to ONC, CMS etc. – can’t we just say doctors, nurses & other healthcare professionals) who use them & you will hear a different story. I talk to docs & healthcare people all the time & I have yet had one tell me that their EHR facilitates the care model they use or is easy to use. Clinical information systems have to be designed so that they provide appropriate clinical function including such things as seamless information sharing, care transition, medication reconciliation, access to external clinical data, clinical decision support & facilitation of best practices – in short, they must be redesigned to do all of the clinical & sociocultural things that go into supporting the best patient care possible. Everything else, cost savings, quality & performance scoring, billing & reimbursement etc. are secondary priorities for the clinical systems. They are primary priorities for another set applications focused on these dimensions of healthcare. These applications might be interoperable clinical information systems, but it is impossible, at least in my experience, to design an application that has five first priorities & performs all of them at a high level.
• Each of these applications has to be designed & implemented for a specific user & role. User Interfaces of current EHR products are general & generally not suited for any one specific user category. UIs & workflows for billing & reimbursement applications should be different than clinical applications. Detailed work needs to be done to align the UIs & workflows of each application type with the needs & work processes of each user type.
• The current design of HIT systems is highly influenced by our current pay-for-procedure reimbursement system, Yes, I know this is changing… but, we have to accelerate this change & be serious about it. Current institutions cannot be allowed to maintain the status quo or we will not make progress on this. New payment models such as MIPS (Merit-Based Incentive Payment System  must be designed not as check-the-box quality measure systems or standards-compliance systems as these criteria tend to promote a race-to-the-bottom where everyone is meaningful use certified or PCMH compliant but few are meaningfully using HIT systems or actually providing care through a medical home model.
• What we know about patient health, patient care & outcomes is encoded in the EHR data. This data needs to be as accurate as possible in order for care provision & medical decision-making to be effective, but we know from many studies  that there are multiple types of errors reflected in EHR data. The redesign of HIT systems has to emphasize data quality & governance practices so that we can be confident in the accuracy of EHR & HIT data.
• Applications need not only to be interoperable, but need to be aware of classes of external data that may be important for the performance of strategic analysis. These applications will need to be able to acquire, store, manage & analyze very large amounts of heterogeneous data, including unstructured data such as text & image. Current HIT infrastructure is not adequate to provide these capabilities for both the large amounts of data that will be required & for the many different types of data that will also be necessary . In particular, the storage, maintenance & analysis capabilities provided by relational databases are already outdated. New types of infrastructure starting with ultra-large distributed file systems (Hadoop, Spark), associated analytic infrastructure (MapReduce, Yarn, Spark) & analysis facilities (Impala, Hive, R, Pig Latin etc.) are now required & will evolve over the next 3-5 years to be easier to use than current relational database & data warehousing facilities (this would not hard…). Healthcare organizations need to begin to make this transition now before their current infrastructure begins to fail.
• Healthcare applications also need to be smarter. This is where the ONC’s learning comes in. Machine learning as well as intelligent search, classification, pattern recognition & reasoning capabilities will need to become core parts of HIT systems to provide the kind of smart interaction with each user type that will facilitate improved care, better financial performance, provision of appropriate privacy & security & all of the performance areas we talk about with respect to HIT. Much of this capability is already under development or in prototype but, the right connections need to be made among designers, developers, users & other relevant parties so that these capabilities do get built into HIT systems.

The bottom line is that we have the possibility of creating a useful & effective HIT ecosystem by 2024, but in order to do so we need to stop emphasizing the recording & scoring of quality measures, meaningful use criteria, PCMH requirements etc. All of these measures are a part of how we think about healthcare information system, but they are not the core reason to develop & use them. If we keep emphasizing that the core reason for the development & use of these systems is the improve patient & population health, & we emphasize those things that are commensurate with that goal, we’ll have intelligent, interoperable systems that provide care with high measureable quality & low(er) cost without having to impose HIT systems designed to enforce policy requirements that do not always align with long-term care improvement. HIT systems will be designed & implemented by vendors over the next ten years to be in line with their commercial goals & a compliant with healthcare regulations as adherence to their first principle permits. If we do not want to continue the current chaotic ecosystem, we need to start now to deliberately move to a more care oriented design for HIT. Tomorrow, next week or next year is too late.

(1) The black hole at the center of our galaxy, Sagittarius A* (© NASA)
(2) https://www.healthit.gov/sites/default/files/ONC10yearInteroperabilityConceptPaper.pdf
(3) https://www.healthit.gov/sites/default/files/nationwide-interoperability-roadmap-draft-version-1.0.pdf
(4) http://posttechnical.blogspot.com/2014/07/the-onc-interoperability-vision-opinion.html (3 July 2015) & http://posttechnical.blogspot.com/2014/07/the-learning-healthcare-system.html (18 July 2015)
(5) The term “care providers” is broadly inclusive of the care continuum, reflecting primary care providers, specialists, nurses, pharmacists, physical therapists and other allied care providers, hospitals, mental health and substance abuse services, long- term and post-acute care facilities, home and community-based services, other support service providers, care managers, and other authorized individuals and institutions (original footnote)
(6) ONC vision document, pp. 2,3
(7) I understand that patients are consumers if you consider healthcare a true market, but I believe that using this language defocusses the actual goal(s) of healthcare. For my opinion on healthcare as a market, see: http://posttechnical.blogspot.com/2014/05/healthcare-as-market.html
(8) Interoperability, Integration & Standards or Why can’t I get the information I need when I need it? Financial Operations/Information Technology Conference, National Association of Community Health Centers, 10/2008.
(9) Rdb/VMS generated ~$1B total revenue over 10 years (bought by Oracle, 10/1994), DEC Objectbroker generated ~$600M revenue (bought by BEA, 1995?) both from Digital Equipment Corporation, Riverton HOW (500 customers in 6 months), & many others…
(10) ANSI X3H1 Committee, SQL standard V1, 1986; OMG, co-author of the CORBA Interoperability Standard, 1998 & many others...
(11) http://www.coindesk.com/hard-fork-developers-scaling-bitcoin/
(12) State Healthcare Information Network for New York (SHIN-NY) Technical Architecture Overview, V0.1 Draft, October 15, 2008
(13) https://www.healthit.gov/policy-researchers-implementers/nationwide-health-information-network-nwhin
(14) All W3C or Oasis standards at the time, now mostly superseded by REST protocol, JSON etc.
(15) Loonsk, J. 6 Reasons to Plan Architecture for Interoperability. GovernmentHealthIT. http://www.govhealthit.com/news/6-reasons-plan-architecture-ahead-interoperability, 24 September 2014.
(16) The Learning Healthcare System. PostTechnical Strategist. http://posttechnical.blogspot.com/2014/07/the-learning-healthcare-system.html. 18 July 2014.
(17) https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/Value-Based-Programs/MACRA-MIPS-and-APMs/MACRA-MIPS-and-APMs.html
(18) c.f. Improving Diagnosis in Healthcare, IOM; https://iom.nationalacademies.org/Reports/2015/Improving-Diagnosis-in-Healthcare.aspx;Deploying Analytics in the Healthcare Safety-Net, http://posttechnical.blogspot.com/2016/01/deployment-of-analytics-into-healthcare.html & references, Many others…
(19) Data as an Asset: The Evolution of Healthcare Information Technology. The PostTechnical Strategist. 9/2015. http://posttechnical.blogspot.com/2015/09/data-as-asset-evolution-of-healthcare.html

The Learning Healthcare System

The ONC has proposed a ten-year vision[1] for interoperability in healthcare information technology that divides this time into three periods. Years 1-3 are devoted to achieving technical interoperability & sharing of healthcare information; while years 4-6 focus on using this shared information to improve quality & lower cost. Years 7-10 are labeled the “learning health system” & described as “Individuals, care providers, public health (officials) and researchers contribute information and learn from information shared across the health IT ecosystem, with rapid advancement in methods for deriving meaning from data without sharing PHI.[2]” What “learn” might mean in this context is an interesting question… First, let’s look at what the ONC appears to mean to by it, & then we’ll look more broadly.

The ONC lists a number of characteristics of the healthcare system during this timeframe (2021-2024) in no particular order:

1.        Enhanced healthcare information contribution & sharing across clinical (provider & patient), public health & research areas
2.      More functional technical tools available to apply to this data- search & visualization are examples
3.      General availability of “patient-centered” outcomes research results
4.      Continuous learning through predictive & retrospective analysis of aggregated data
5.      Availability of patient-specific clinical decision support taking into account the patient’s genetic profile, clinical history, local public health trends & relevant socio-cultural trends (social determinants)
6.      Improved public health surveillance integrated with point-of-care decision support

This is actually quite a good list, but much of it is either already available or will be available in the near future (18-24 months). Let’s review where (I think) we are with this list, & then let’s explore some of the possibilities for a learning healthcare system in the ONC’s 10-year timeframe. The issue is, as William Gibson famously observed, “The future is already here, it’s just not evenly distributed”[3]

•       Point 1 - Enhanced information contribution & sharing across different healthcare contexts, is what the ONC’s years 1-3 are about. A high level of data interoperability will allow contribution of information from a variety of sources, including patients, for a variety of purposes. Interoperability is a frustrating issue today, as many vendors can’t effectively share data across their own product lines. Hopefully this will change in the next three years. We have achieved high levels of data interoperability in other industries, & notwithstanding that many people working in healthcare believe its data to be substantially more complex & sensitive to error than data in, say… banking or aerospace design, I think that with a pragmatic approach, not just to standards & certification, but also to vendor architecture, API development & in the field data sharing, that we can achieve appropriate levels of interoperability in this timeframe.

•         Point 2 - We have many advanced functional tools available today; we’re just not using them. This is often because HIT vendors are loath to integrate their systems (practice management, EHR, lab reporting etc.) with external tools, but prefer to develop tools themselves. This doesn’t always work for several reasons: the vendor may not have the necessary skill &/or resources to develop such tools, the vendor’s business model may not include such development, the vendor may have allocated this development to partners who have their own agenda & business model(s) & many other factors. There is another much larger issue; most of these HIT systems are architected on an enterprise model that is not as scalable or flexible as contemporary designs. As HIT products migrate to contemporary infrastructure (Hadoop, NoSQL etc.), interoperability & integration will become possible at larger & larger scale.

•        Point 3 – The American Health Information Management Association provides a good introduction to the variety of healthcare research data already available[4]. In addition the Agency for Healthcare Research & Quality (AHRQ, HHS) & the Healthcare Information Management Systems Society (HIMSS) both make a good deal of data available. The Centers for Medicare & Medicaid has also recently made a substantial amount of claims & provider payment data available[5]. This trend will continue, especially as large healthcare organizations begin making public the results of analyses of ultra-large data sets (see immediately below).

•         Points 4-5 – These points are linked, especially at the point-of-care. Continuous learning, in this context, is the ability to develop new knowledge & strategies for using that knowledge based on an understanding of current & previous results & information. Many systems currently perform retrospective (& in some cases predictive) analysis of large amounts of healthcare data to determine patterns in both clinical & operational areas for healthcare organizations (Point 4). When this type of analysis is done based on specific patient characteristics at the point-of-care, diagnosis & treatment planning can be based on the empirical data & learning is brought forward with each analysis (Point 5). Examples include:

o   Mayo Clinic - AWARE “bedside consulting” system (5M patient records over 15 years)

o   Beth Israel Deaconess Medical Center (Boston) – Clinical Query system (2.2M patient records)

o   Kaiser Permanente – Natural language query system (9.1M patient records over 10 years)

o   Partners Healthcare (MA) – Queriable Inference Patient Dossier

o   IBM/Wellpoint – “Dr. Watson”, deep understanding system applied to healthcare information (cancer diagnosis)

•         Point 6 – Systems today used analysis of regional to hyperlocal trends in disease patterns to characterize the public health context of specific locations. These analytic results can be combined with point-of-care recommendation systems to improve diagnosis & treatment. An example would be Google Flu Trends although there are many apps such as Healthify[6] that provide hyperlocal services recommendations based on EHR encounter information.

To summarize: current & near future HIT systems can provide appropriate levels of data interoperability, new architectures & tools are already making HIT & the analysis of HIT data much more scalable & performant, large amounts of research data is already available, even to patient & consumers, ultra-large scale pattern matching in healthcare data sets can provide the basis for both continuous learning by systems & their human users, this learning is already being applied to point-of-care recommendation systems that draw from millions of patient records & finally current & near future HIT systems are reporting large amounts of public health data which is being analyzed to provide better understanding of large scale health phenomenon & eventually integrated with point-of-care recommendation systems.

OK – so what isn’t being done? & What could be done? One major thing is that the more information you include in these analyses, the better the results are, so a broader range of inputs should be included. Such information streams as public social media, data on social determinants, even online & conventional shopping data can be important in understanding a person’s health profile. A recent story in Bloomberg Business Week[7] described the use of credit card purchasing data to supplement providers information about patient behavior – are you actually picking up your prescriptions, buying a lot of junk food, shopping at Big & Tall etc. Marketers use this kind of data routinely in other industries, so why not in healthcare[8]? There are almost an infinite number of information sources that could be used productively, once the sociocultural issues are understood & ameliorated.

There are also new kinds of analysis that are being developed. An example would be work at Oxford University[9] where an algorithm analyzes ordinary photographs & can predict genetic anomalies & diseases. Hundreds or more of such new uses of information are being developed & will be available (& more evenly distributed) in the near future.

But what about learning, I hear you say… A recent issue of Health Affairs was devoted to the theme of “big data”. One of the articles reviewed work on a learning health system, talked about impediments & made some predictions[10]. This work used the following definition of a rapid learning healthcare system,  “a health system that learns as quickly as possible about the best treatment for each patient—and delivers it. This kind of system draws on a much faster knowledge production process: from discovery science, to new therapies and clinical science that can inform personalized medical care, to better-informed physicians and patients.” This idea of a rapid learning health system was first proposed in 2007[11], & the Rapid Learning Project & others have done a good deal of work, mostly workshops & policy papers. As we have seen, however, this vision of deep analytics applied at the point-of-care to diagnosis & treatment of individual patients is already in place in a number of settings. This is a lot, but a learning healthcare system has to be more than this.

As already stated, learning can be thought of as “the ability to develop new knowledge & strategies for using that knowledge based on an understanding of current & previous results & information”. This ability is continuous & ongoing, the implication for a healthcare system is that whenever an actor (provider, patient, caregiver &c.) is using a part of the system, the system is moderating the user’s context (usage) & anticipates what information & analysis may be relevant. The system may then give the user the opportunity to request this information; which can be diagnosis, treatment suggestions, data on treatment, analysis of alternatives, public health implications, information & recommendations on amelioration of social determinants & many other possibilities. In order to do this, the system would have to have access to a great many data sources as well as have deep understanding, hypothesis testing & recommendation capability (in the Dr. Watson mode) & an interface that allowed substantial interaction with the user in a manner that was non-threatening & productive. In addition, the system would serve as an information source & liaison for public health & social systems as well as healthcare systems at other organizations (that the user might be associated with). It might communicate with the user through a variety of devices & in a context (app or portal) that they were used to. We’re obviously not there yet.

Can we get there? I believe that we can, but we have to focus. The we, here, is not only the producers of software & systems, but providers, patients, caregivers & healthcare organizations (if corporations can be people, so can healthcare organizations)[12].  Here is my (partial) list of what’s important:

•         Facilitate real interoperability for healthcare systems – The development & adoption of standards does not automatically convey interoperability[13]. A lot of really hard work has to be done to ensure that even things like standard documents (like C-CDA) can be assimilated by multiple system & that the data, once imported, makes sense. This could easily take more than the three years the ONC has allowed.
•         Develop learning in the healthcare context – Learning is not just analyzing ultra-large information “lakes” to do pattern matching & make diagnosis & treatment recommendations. It is creating new knowledge & new strategies for developing & using knowledge. In this sense, it is more like IBM’s Watson, that attempts a semantic understanding of material & then forms & tests hypotheses to answer questions about that material than it is like most of the point-of-care recommendation systems currently in use or under development. These systems do some form of pattern matching to an initial set of data about a patient, & if their information source is large enough, may discern patterns that can be translated into recommendations with a very high “probability” of relevance (if not correctness, based on the analyzed data).

An aside is relevant here. The current point-of-care systems we are talking about are not conventional rule-based systems. They do not have domain-specific heuristics about cancer diagnosis & therapy (as an example). The heuristics that they have are about semantic normalization, general pattern matching, visualization etc. They operate by taking input on a patient’s condition & comparing that to (potentially) millions of patient records to determine what the most effective diagnoses & treatment plans have been for those specific inputs. Earlier “expert” systems operated quite differently by taking the input on patient condition & executing a set (sometimes as large a set as 10s-of-thousands) of domain-specific rules. These systems often had relatively high percentages of effectiveness – Mycin,[14] an expert system (with approximately 600 rules) that made recommendations for treatment of bacterial infections, developed at Stanford University in the 1970s, had an effectiveness of 69% which was higher than that of medical experts surveyed. Current point-of care systems have an effectiveness of (close to) 100% relative to their information base. This is a quite different kind of effectiveness than that of a rule-based system (& discussion of the causes of this difference are beyond the scope of this current blog).

Learning in healthcare systems won’t come about by itself. It will have to be facilitated by government-public-private partnerships & specifically funded. Real prototypes & production systems will have to be subsidized & deployed for testing & feedback. A project similar to that which produced the NwHIN (originally NHIN) needs to be planned & quickly started so that working groups can begin describing the functionality of healthcare learning & companies can be selected to begin prototyping. Standards will not be as important initially in this effort (as they were in NHIN development) as innovation will be more important. The companies should not just include the usual suspects (IBM, Google, Microsoft, etc.) although they are important, but should also include some smaller organizations with different ideas that may (or may not) be layered on the infrastructure provided by their larger brethren.

A learning healthcare system is a great goal, but it won’t happen without a lot of support (funding) & leadership. Let’s start now.

---

[1] Connecting Health and Care for the Nation: A 10-Year Vision to Achieve an Interoperable Health IT Infrastructure. ONC. June 2014. http://healthit.gov/sites/default/files/ONC10yearInteroperabilityConceptPaper.pdf, accessed 25 June 2014.

[2] ONC. 2014. P.8

[3] William Gibson, interview in The Economist, 4 December 2003.

[4]http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_050345.hcsp?dDocName=bok1_050345

[5] http://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/Medicare-Provider-Charge-Data/

[6] https://www.healthify.us/en

[7] http://www.businessweek.com/articles/2014-07-03/hospitals-are-mining-patients-credit-card-data-to-predict-who-will-get-sick?utm_content=buffer7874a&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

[8] Privacy issues are the first reason to think twice about it, but we have already ceded our privacy when Amazon or Google makes purchasing suggestions for us.

[9] Ferry, Q. et al. 2014. Diagnostically relevant facial gestalt information from ordinary photos - See more at: http://elifesciences.org/content/3/e02020#sthash.c8S7Tm7d.dpuf

[10] Etherege, L.M. 2014. Rapid Learning:A Breakthough Agenda. Health Affairs. vol. 33 no. 7 1155-1162. July 2014.

[11] Etheredge LM.A rapid-learning health system. Health Aff (Millwood). 2007;26(2):w107–18. DOI: 10.1377/hlthaff.26.2.w107.

[12] The doctrine of corporations as people has been established in the U.S. as early as 1819 (Dartmouth College vs. Woodward, 17 U.S. 518 (1819) & as recently as Burwell vs. Hobby Lobby (573 U.S. ___ 2014)

[13] As I stated in my last post, during the development of interoperability standards for CORBA, a rep from one of the other vendors (I was representing the Digital Equipment Corporation) told me he would be compliant if my system sent his system a message & his system sent my system back an error message!

[14] http://en.wikipedia.org/wiki/Mycin