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 5 Rights Aren't Wrong,... But...

"In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, & the worst thing you can do is nothing."

Theodore Rooseveldt 

In November of 2014, The ONC (Office of the National Coordinator, I liked it better when it was ONCHIT) posted guidance regarding clinical decision support (CDS). This guidance proposed “5 rights” that applications & implementations that provided CDS would have to support. The five rights[1] were defined as:

         ·      Right information (evidence-based guidance, response to clinical need)

         ·      Right people (entire care team – including the patient)

         ·      Right channels (e.g. EHR, mobile device, patient portal)

         ·      Right intervention formats (e.g. order sets, flow-sheets, dashboards, patient lists)

         ·      Right points in the workflow (for decision making action)

The ONC also stated that CDS is more than just the delivery of alerts. The 5 rights provide a good context for thinking about CDS & how it can/should be used. In particular the CDS/PI (Clinical Decision Support Collaborative/Performance Improvement) detailed “steps” table[2] seems quite useful, at least as a source of information on CDS.

A number of older, but still relevant (IMHO) academic studies provide more insight into the most effective capabilities & features of CDS systems. Specifically, Kawamoto, et al.[3] did a meta-analysis of the effectiveness of CDS systems in improving outcomes & found that four features made such systems most effective (in descending order):

       1.     Automatic provision of CDS as part of clinical workflow

       2.     Provision of recommendations rather than just assessment

       3.     Provision of CDS at the time & location of decision making, &

       4.     Provision of fully automated CDS rather than partial reliance on the provider to look up information

Other features that were significant but not at the level of these four were:

       ·      No need for additional provider data entry

       ·      Requesting explanation (from provider) of why recommendation(s) were not followed (requires    more analysis of decision by provider & may change decision)

       ·      Provision of CDS results to patient (acknowledgement of usefulness of system & transparency), & finally

       ·      Provider education (often not by vendor) for use & interpretation of CDS

Other studies e.g. Garg, et al.[4] also a meta-analysis, provide highly detailed analysis of effective features for different types of targeted CDS (diagnosis, preventive care, diabetes treatment, etc.).

My semi-recent experience on a federal grant has given me some perspective on this. I was Principal Investigator on a Department of Commerce (NIST) grant to develop a secure network with identity verification at all endpoints for clinical eReferral. This work was done with UC San Diego Medical Center & the San Diego VA. Direct network connections were set up for UCSD & its medical affiliates including a set of CHCs in the Columbia River Gorge area (OR). Part of the project was that eReferrals done through the Direct connections would include the possibility of using the ActiveHealth Management (now owned by Aetna) application for CDS. What we found was that providers, on both sides of the connection were loath to use the CDS as it required: additional &/or redundant information to be entered (usually by the provider) & going out of the Direct connect/EHR context. In addition, providers did not like that the application made recommendations & provided copious amounts of background for the recommendations, but allowed for only minimal provider input & feedback. (FYI – ActiveHealth Management never followed through on its commitments to the grant, so this capability was only tested in prototype.) The result was clear, however. Providers were not interested in CDS/recommendations if they were not fully integrated into their EHR & workflow. Even though ActiveHealth Management was considered “best-of-class” CDS at the time, it was not enough to tempt providers to use it consistently.

Other types of patient-centered recommendation systems may also be interesting & relevant here, specifically the point-of-care recommendation systems under development (& in some cases being used by) by Kaiser, Partners, Geisinger, Mayo Clinic, Cleveland Clinic etc. These systems do operate for the provider at the point-of-care & meet most of the criteria described by Kawamoto, that is:

         ·      Are provided automatically at the time & place of decision making

         ·      Make recommendations, not just summarizations/assessments, &

         ·      Do not require any additional data entry.

Of course, even though these systems make recommendations based on the analysis of many thousands - & in some cases millions – of patient records, they are only as good as the quality of the data that they analyze. Based on our experience with data quality in the Path-2-Analytics[5] project, we can make some assumptions regarding the quality of a data set with millions of records, the compilation of which started 12-15 years ago. Kaiser, for instance, has 9M+ patient records dating from 2003. These types of systems will become extremely important over the next 5-8 years, but today they are more conceptually important than functionally important.

OK – so what’s the bottom line here? The ONC, CMS etc. will continue to mandate that providers begin using clinical decision systems in their clinical practice, but what leverage do these systems actually provide? & how can providers & healthcare organizations select CDS systems that will improve their practice? The ONC defines CDS as: “Clinical decision support (CDS) provides clinicians, staff, patients or other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care. CDS encompasses a variety of tools to enhance decision-making in the clinical workflow. These tools include computerized alerts and reminders to care providers and patients; clinical guidelines; condition-specific order sets; focused patient data reports and summaries; documentation templates; diagnostic support, and contextually relevant reference information, among other tools.”[6]  

The Stage 2 Meaningful Use measure for CDS (2016-17) is:[7]

“Measure1:Implement five clinical decision support interventions related to four or more clinical quality measures at a relevant point in patient care for the entire EHR reporting period. Absent four clinical quality measures related to an EP’s scope of practice or patient population, the clinical decision support interventions must be related to high priority health conditions.

Measure 2: The EP has enabled and implemented the functionality for drug ‐ drug and drug allergy interaction checks for the entire EHR reporting period.”

As ONC points out, this set of capabilities requires the ability to access & analyze patient-specific clinical data, some type of reasoning mechanism (rules, big data analysis, human intervention etc.) to interpret the data & construct recommendations, create care plans, assess current care etc. & the ability to present information & inferences in an understandable & useful way.

It should also be pointed out that the Stage 2 criteria are also linked to interventions related to to the CMS clinical quality measures, that is some action must be taken based on input from a CDS (alert, etc.) that is related to a quality measure as described by CMS[8]. There are currently 64 of these measures ranging from HbA1c measures to colorectal cancer screening to pediatric asthma screening

There are many standalone CDS products, most of which are focused on a specific clinical area. Examples are: interpretation of tumor imaging for specific types of tumors, interpretation of retinal imaging for treatment of macular degeneration, tracking of quality measures for individual patients & alerting provider when measures fall outside of guidelines & many, many others. There are very few general CDS systems, the best-known being ActiveHealth Management, a system that relied on a set of clinicians & human experts that continuously reviewed medical journals & other material to extract the latest information on treatment patterns & outcomes. This information was then translated into a rule set that was used to interact with provider input (or automated input through CDS) regarding specific patients. Treatment recommendations & treatment plans were then suggested to the provider. Very few CDS except for ActiveHealth & the point-of-care recommendation systems using big data analytics work like this. Most are much more targeted. Most CDS function provided by EHRs is in the form of reminders & alerts, although this is starting to change.

So how does a healthcare organization select a CDS that will work to improve outcomes & not just meet meaningful use requirements? Here are some steps:

          1.     Determine what data you have available to serve as the base for decision support. This will include your EHR & PM systems as well as other internal data. It may also include external data as relevant. External data may include clinical data from other sources (HIE, eReferral etc.) or public &/or private clinical datasets.

         2.     Determine what type of decision support you require & who the recipient of this support will be. Are you looking for general point-of-care diagnostic & treatment planning support (order sets, procedure lists etc.)? or are you looking for specific support in particular types of image interpretation or other highly specialized support?

         3.     Develop a set of expectations, goals, requirements, users & use cases for your CDS system.

         4.     Evaluate what CDS capabilities you already have in your EHR or other HIT systems. Identify the gaps in the capabilities you have versus your requirements.

         5.     Research & identify CDS systems that will fill these gaps. Make sure you determine compatibility of any systems you are researching with your existing HIT systems. Also make sure you understand the skills required to use these systems & what training is required (including but not limited to vendor supplied training as your staff may need more general training on decision making & decision support).

        6.     Evaluate & test the system(s) you have identified using the real use cases you described in Step 3. Use data that is as realistic as possible, that is as close to your clinical data as possible (in some cases, it may be possible to actually use your own data).

       7.     Work with the vendor to make sure that the system you will purchase is customizable &/or configurable the way you need & that it is fully compatible with your other software.

       8.     Arrange for a test period & do a series of tests that exercise your use cases. Work with the vendor to remediate any issues you find.

        9.     Arrange for any training that the vendor &/or external organizations can provide.

At this point you are ready to purchase your CDS system.

OK, you say,… that seems like a lot to go through, especially since my EHR vendor assures me that their product provides clinical decision support that is compliant with meaningful use, PCMH, MIPS & any other regulation or guideline you have asked about. My experience, as I’ve already stated, is that the CDS associated with EHR products is mostly limited to alerts that are programmed to fire when specific clinical measures are above guidelines or when a series of values trend above guidelines. More recently, they can also make recommendations for & enable ePrescription of specific drugs or even propose order sets (for CPOE). This is all good, in fact much better than not providing such capabilities at all, but if you have determined a broader set of requirements, then your EHR may not provide everything you need. The bottom line is CDS that actually meets the ONC’s definition is not provided by any current EHR or in fact even by any combination of EHR & dedicated CDS application. It is most closely approached by the point-of-care recommendation systems that are under development & in preliminary use by organizations such as Kaiser Permanente, Geisinger, Partners etc. These systems combine ultra-large data sets with advanced deep learning & pattern recognition capabilities that will be in general use in the next 3-5 years, but today are the exception.

I believe that the best we can do today is a combination of CDS provided by your EHR along with a more specialized system that addresses some of the additional requirements you have identified. EHR decision support will get better only if it is required to, but Stage 2+ meaningful use requirements as well as the proposed Stage 3 (maintaining the two requirements for Stage 2 with additional emphasis on appropriate position of CDS in the clinical workflow[9]) do not push for CDS as described by the ONC except to say that CMS wants to encourage innovative development & use of decision support beyond alerts & notifications. We have a long way to go before CDS is a really effective addition to the care of patients… No number of definitions, usage descriptions of reports by Federal agencies will make it happen. Vendors will develop effective CDS only if it is required, so it is up to providers, policy experts & healthcare organizations to both push for this development & to produce their own definitions, descriptions, use cases & even prototypes as appropriate & possible. Now is the time to start…

---

[1] https://www.cms.gov/Regulations-and Guidance/Legislation/EHRIncentivePrograms/Downloads/ClinicalDecisionSupport_Tipsheet-.pdf

[2] https://sites.google.com/site/cdsforpiimperativespublic/CDSQI-stepbystep

[3] K. Kawamoto, C. Houlihan, E.A. Balas, D.F. Lobach. Improving clinical practice using clinical decision support systems: A systematic review of trial to identify features critical to success. BMJ, doi:10.1136/bmj.38398.500764.8F (published 14 March 2005)

[4] A.X. Garg, et al., Effects of computerized decision support systems on practitioner performance & patient outcomes. JAMA. 293(10). P. 1223-1238.

[5] Path-2-Analytics Project: Process & Results Review, Association of Clinicians for the Underserved Annual Meeting. Washington, D.C, June 2015.

[6] https://www.healthit.gov/policy-researchers-implementers/clinical-decision-support-cds

[7] https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/EP_ObjectiveMeasuresTable-.pdf

[8] https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms/ecqm_library.html

[9] https://www.healthit.gov/providers-professionals/how-attain-meaningful-use