# Presentation: 183528

## Commission on Systemic InteroperabilityStandards, Privacy, International & TransitionIssues / Barriers & Suggestions

**John Quinn**
**Capgemini****Health Consulting Practice CTO****HL7 TSC Chair**
**April 22, 2005**

## Messaging & Data Standards

## Messaging & Data Standards

**We really have the first level standards in hand for EHR and ERx. ****NCVHS has reviewed and recommended. The standards deal with:**
**Messaging**
**Syntax**
**Optionality**
**Vocabulary**
**HIPAA, Electronic Medical Records, Electronic Prescribing**

**Optionality**** has been a necessary and practical requirement for Standards. **
**Optionality**** is also a primary barrier to interoperable electronic health records.**

## Messaging & Data Standards

**What Problems Are We Trying to Solve?**
**Ad-hoc Access to Medical Summary and Recent Clinical Data?**
**The Complete Transfer of a Clinical Record?**
**Facilitate the Use of Multiple Computer Systems that Together Automate Clinical and Administrative Processes?**
**It is important to acknowledge that the majority of our experience is on number 3.**
**Optionality has traditionally been important because clinical and administrative processes are unique:**
**Hospital to hospital**
**Nursing station to nursing station**
**Physician to physician**

**Process Optionality Significantly Complicates Standards**

## Data & Messaging Standards

**Data & Messaging Standards**

**Any given message must support a given process with a required set of data. **
**Not knowing the process that is being supported is a barrier to interoperability  just like not knowing the set of data that the target computer system needs or the vocabulary that a specific data element needs to use.**

***Process***

***Data***

**Messages to:**
**Move a Copy a Patient’s Record**
**Inform an ancillary department’s computer system of an admission**
**Submit a claim for reimbursement**
**Order a test on a patient**
***etc.***
***All in the context of the action***

***Syntactic Interoperability***

***Semantec Interoperability***

## Data and Messaging Standards

**HL7 Version 3 is designed to take a structured definition of **_***data***_** and **_***process***_** and produce a standard message based on both the **_***data***_** required and the **_***process ***_**being supported into a standard methodology giving semantic interoperability.**
**This is not easy and has taken the HL7 community *****(US and 28 international affiliates)***** the better part of 12 years to create.**
**Model based standards development is state-of-the-art.**
**The supported message syntax is XML (and has been now for at least the last four years).**
**HL7 Clinical Document Architecture R2 is now also ready as a compliment to HL7 Version3 to move electronic *****“***_***documents***_***”***** as well as *****“***_***messages***_***”*****.**
**All are based on the HL7 ANSI Standard Reference Information Model (RIM).**

## The HL7 Reference Information Model

- Referral
- Transportation
- Supply
- Procedure
- Consent
- Observation
- Medication
- Administrative act
- Financial act

- Organization
- Place
- Person
- Living Subject
- Material

- Patient
- Member
- Healthcare facility
- Practitioner
- Practitioner assignment
- Specimen
- Location

- Entity

- 1..*

- 1

- Participation

- Act

- Author
- Reviewer
- Verifier
- Subject
- Target
- Tracker

- Has component
- Is supported by

## Data & Messaging Standards

**For the most part, every HL7 version 2.x message is unique.**** **
**Modes for moving data**
**Most US hospitals use HL7 Version 2.x to *****“push”***** data in real-time between internal computer systems in response to an *****“event”***** created by a process (sometimes called and unsolicited update.)**** *****(e.g., an order message is sent from a physician order entry system to the pathology department’s system after the physician has completed and confirmed an order).***
**Few, if any, vendor clinical systems are capable of responding to “ad-hoc *****queries******”***** for clinical data. Nevertheless, we are developing models for EHR and ERx that rely on movement of data in response to a query.**
**Processing queries against complex clinical on-line data stores severely impacts on-line systems performance. Any existing system will require re-architecting and additional hardware.**

## U.S. Health Messaging Standards Development Efforts

**ACR/NEMA *****(DICOM)******(American College of Radiologists /******  ******National Electrical Manufacturers Association)******(Digital Image Communications)***
**X12 *****(X12N)***
**ASTM (E31)*****(American Society of Testing Materials)***
**IEEE*****(Institute of Electrical and Electronic Engineers)***
**NCPDP*****(National Council of Prescription Drug Producers)***
**ADA*****(American Dental Association)***

**ANSI HISB*****(American National Standards Institute’s Health Informatics Standards Board)***

**U.S. Health Messaging Standards ****Development Efforts**

**Data & Messaging Standards**

## HL7 Committees & Special Interest Groups

**Arden Syntax**
**Attachments**
**Architecture Review Board****
**CCOW***
**Clinical Decision Support***
**Clinical Genomics**
**Clinical Guidelines**
**Community Based Health Services**
**Conformance**
**Control/Query***
**Education****
**Electronic Health Records***
**Electronic Services****
**Financial Management***
**Government Projects**

**Imaging Integration**
**Implementation***
**International Affiliates****
**Java**
**Laboratory**
**Laboratory, Automated & Point of Care Testing**
**Marketing****
**Medical Records/ Information Management***
**Modeling & Methodology***
**Orders & Observations***
**Organization Review****
**Outreach for Clinical Research***
**Patient Administration***
**Patient Care***
**Patient Safety**
**Pediatric Data Standards**

**Pediatric Data Standards**
**Personnel Management***
**Pharmacy**
**Process Improvement****
**Public Health & Emergency Response**
**Publishing***
**Regulated Clinical Research Information Management (RCRIM)* ****(formerly Clinical Trials)**
**Scheduling & Logistics***
**Security & Accountability**
**Structured Documents***
**Technical Steering Committee****
**Templates**
**Tooling****
**Vocabulary***
**XML**

*** Technical Committees, ** Board Committees**

**As of 1/23/05**

**Data and Messaging Standards**

## Data and Messaging Standards

***What’s Missing? – What could Change?***

**An understanding by all that the HL7 V2 messages in use today inside of hospitals with it’s “data-only” capabilities is not going to deliver a Portable EHR across the continuum of care.**
**Implementation Guides that describe Process and Data movement to support Defined EHR Events **
**Medical Summary Transfer**
**Patient Referral and Transfer**
**Vendor Buy-In and required support **_**in delivery**_**... not just promises or statements of support.**

## Data and Messaging Standards

**What’s Happening?**
**HL7 Electronic Health Record Special Interest Group (EHR SIG) is moving as fast as it can...**
**DHHS and NLM is moving on implementation guides...**
**	*****...******but...***
**ANSI Standards Processes are consensus-driven, deliberative and collaborative ... none of these easily support the President’s time line.**
**DHHS / ONCHIT involved leadership could minimize some of the infighting that is now occurring between vendors and standards organizations (but only in the US Realm!) ...**
**The “alignment of interests” in the commercial world slows down consensus driven processes.**

## Vendors

## Vendors

**With few notable exceptions at primarily academic institutions, all healthcare information technology in this country is delivered by a relatively small group of vendors.**
**Clinical IT development only started in earnest after IT systems to support administrative processes (i.e., billing, finance, payroll) occurred first.**
**IT Technology to support clinical processes is relatively new and, as the Office of the National Coordinator of Health Care IT has pointed out in July, not very well deployed where most healthcare is delivered (i.e., primary care physician offices, small group practices, ambulatory care clinics).**
**With only a couple of exceptions, vendors of HCIT in this country do not delivery clinical IT solutions to both hospitals and primary care physician offices. This is true in the US and in other countries (e.g., UK) as well.**

## Vendors

**Given all of the above, it is surprising to see the amount of sometimes fierce competition that exists among / between vendors.**
**Cost of sales is very high, sales cycles are very long and vendors want to place as much of their product as possible in any “won” customer.**
**A number of factors make it difficult or impossible for the management of a provider organization to replace a vendor that does not deliver on their promises.**
**Promises are in place now in the industry for products that have not been delivered that could easily take longer than the remaining 8+ years left to deliver on the President’s Vision.**
**Control of the Patient’s and the Physician’s Desktop (i.e., the web portal) has become a recent point of skirmish. We have no agreements (or even serious initiatives) resolving the question: “How does a web portal deliver information sourced from multiple vendor solutions to a single unified view?”**

## Vendors

**What Needs to Happen?**
**Leadership that sets out a clear roadmap to the vendor community.**
**What products need to support**
**When they need to support it**
**Independent Organizational Leadership**
**Standards groups such as HL7 have served as a forum for solving detailed technical problems—(i.e., the *****how***** once the what and when have been defined).**
**The vendors and the market in general will eventually find their own way. However, the time and monies required to do it this way are well outside of our goals.**

## Vendors

**Vendor organizations (including standards organizations) are prone to “misuse” of process and are better known for slowly moving to a desired goal instead of direct and decisive movement.**
**Imagine what would have happened if NASA had not taken control of the moon landing program but instead just funded efforts for private industry to get us there... would we still be waiting for a moon landing?**
**EHRVA is a good idea by the major vendors that work in this market. It is not, however, likely to produce decisive leadership that will get us all implementing portable Electronic Health Records.**
**HL7 EHR SIG is already demonstrating the problems of competitive pressure in a consensus driven process. (One or more vendors are willing to take the appeals process to the limit if it could force inclusion of features that they believe would give them a competitive advantage in an EHR function profile definition).**

## Vendors

**Suggestion: ****We have a working model for sharing patient information in Indianapolis. It was largely funded over a long period of time by public funds. “What would it take to turn this model into our model?”**

## Privacy

## Privacy

**No single issue will derail Portable Electronic Health Records or Electronic Prescribing faster than Privacy.**

**The American Public is very sensitive to this issue.**
**The speed and severity of Congress in rescinding the HIPAA Person Identifier demonstrates how quickly a statutory requirement can disappear.**
**By and large, the medical industry in this country seems to take a different view on the mechanics of privacy when compared to countries like the United Kingdom. **

## Privacy

**The good news is that HIPAA already defines the rules around Privacy for us.**
**The bad news is that it is largely a “covered entity” policy based and we do not have the technology-based implementation of that policy to rely on for EHR or ERx.**
**Some vendors have implemented mechanisms for controlling access and dissemination of protected health information (PHI). However, by and large, I have not seen this technology implemented. There is especially little if any interest in enabling what appears as cumbersome technology in individual or small physician group practice offices.**
**This is very unfortunate because there needs to be a reliable and industry-wide way to record and distribute PHI policy to the whole market...not just as it applies to a particular institution.**
**In short, privacy policy is rooted inside of the “covered entity” and we have no particular way to:**
**Communicate an agreement between patient and covered entity to a third party (i.e., the recipient of PHI).**
**Assume that the recipient can “electronically” act on the privacy policy information.**

## Privacy

**What Needs to Happen?**

**Privacy Requirements need to be part of the “What and When” implementation guides and overall strategy description of both EHR and ERx.**
**Technology-based privacy protection needs to understand what we are doing with PHI and how it is going to be used.**
**Are we “pushing” data or are we responding to an external “query” for data?**
**If the query is a web screen requesting “medical summary” information that will be displayed in an ER, how can we protect a patient’s privacy while at the same time responding quickly and not encumber the ER physician?**
**In either case, how do we know the requestor? How do we know that privacy policy of the source entity can or will be respected by the requestor? In short, how to we “normalize” privacy policy across provider organizations while not significantly adding to the physician’s workload or otherwise slowing the physician.**

## Observations from International Projects

## International Projects

**Most are aware that similar efforts are underway in countries outside the US to support portable electronic health records.**
**Many have been working on these efforts a lot longer than the US**
**Most are financially sponsored by their national governments**
**All have a healthcare delivery and ownership model that is different than the US (and in more subtle ways different than each other too).**
**The differences in organization make financial comparisons difficult. For example, projecting the October, 2004 UK’s NHS expected 10 year expenditures for NPfIT (or NHS Care Record) onto the US would deliver a US cost of 148 B$. However, since the US DHHS does not own the US healthcare delivery system (as the UK DOH owns the NHS) it is not at all clear how you would apply the same monies in the US.**
**Nevertheless, there are some lessons that can be taken away...**

## International Projects

**For the most part the major country governments have settled on HL7. Furthermore, HL7 Version 3.0 and CDA seem to be the preferred vehicle for the movement of clinical information.**
**All other countries have chosen some form of hierarchical data organization at either the country or province level (with the notable exception of the plans in the Netherlands).**
**All have expected that vendor “off-the-shelf” solutions will play a very large role in their architectures.**
**Not withstanding #3, at least Canada (initially) and the UK have elected to write contracts with the vendors (many US based) that effectively require major modifications or whole-sale re-writes of their applications in order to meet the technical requirements of the contracts.**

## International Projects

**The UK specifically expects to map HL7 v2 messages that are now generated by systems inside of hospital to HL7 v3 on the “Spine” to and from the Spine’s central repository.**
**The UK has elected to put private industry contractors “on-the-hook” as solution providers—buffering the NHS from the vendors.**
**In all cases, the responsible government entity (national or provincial) has become very prescriptive of exact function and process that IT systems must support in order to be part of the program.**

## Transition & Adoption

## Transition and Adoption

**Transition**
**It is important to recognize that there is a small percentage but nevertheless sizeable investment in IT in the healthcare industry today.**
**While most primary care physicians have not automated clinical records, all reference labs, most or radiology, almost all retail pharmacy and many departments in individual hospitals have invested in and routinely depend on information technology for patient clinical data.**
**It is not practical to move the entire country to a new set of government set (or even industry set) standards at one time.**
**A transition plan to phase in function and technology over time needs to be created.**
**The transition plan needs to deliver incremental benefits and, at the same time, strongly encourage the acquisition of new technology that moves us all forward at the same time to a stated goal.**

## Transition & Adoption

**Adoption**
**Clinical Healthcare IT systems frequently fail. Failure is defined as the lack of use of the system. In short, the intended uses (i.e., physicians) refuse to make use of the IT system when it is finally implemented.**
**Sometimes failure is technically partial but nevertheless devastating in overall outcome (e.g., “we did not go-live on computerized physician order entry, but rather reverted to a unit-clerk based orders communications application).**
**Ultimately, physicians and other clinical professionals (e.g., nurses, pharmacists, etc.) must use both the end applications and the proposed infrastructure if EHR and ERx are to be successful.**
**There is a gap today in the technology and planning vs. the general understanding by physicians and the clinical professionals that will use these services. The clinical community needs to be more aware and more involved. **

## Questions?