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