Commission on Systemic Interoperability Standards, Privacy, International

1
Commission on Systemic InteroperabilityStandards,
Privacy, International TransitionIssues /
Barriers Suggestions

• John Quinn
• CapgeminiHealth Consulting Practice CTOHL7 TSC
  Chair
• April 22, 2005

2
Messaging Data Standards
3
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.
4
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
5
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.

• Messages to
• Move a Copy a Patients Record
• Inform an ancillary departments computer system
  of an admission
• Submit a claim for reimbursement
• Order a test on a patient
• etc.
• All in the context of the action

Process
Semantec Interoperability
Syntactic Interoperability
Data
6
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).

7
The HL7 Reference Information Model

• Has component
• Is supported by

Entity
Participation
Act
1
1..

• 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

• Author
• Reviewer
• Verifier
• Subject
• Target
• Tracker

8
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
  departments 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.

9
U.S. Health Messaging Standards Development
Efforts
Data Messaging Standards
HL7(Health Level 7) 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(Nation
al Council of Prescription Drug
Producers) ADA(American Dental Association)
ANSI HISB(American National Standards
Institutes Health Informatics Standards Board)
10
HL7 Committees Special Interest Groups
Data and Messaging 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

• 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

Technical Committees, Board Committees
As of 1/23/05
11
Data and Messaging Standards

• Whats Missing? What could Change?

• An understanding by all that the HL7 V2 messages
  in use today inside of hospitals with its
  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.

12
Data and Messaging Standards

• Whats 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 Presidents 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.

13
Vendors
14
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.

15
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 Presidents Vision.
• Control of the Patients and the Physicians
  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?

16
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.

17
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).

18
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?

19
Privacy
20
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.

21
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 marketnot
  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.

22
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 patients 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 physicians workload
  or otherwise slowing the physician.

23
Observations from International Projects
24
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 UKs 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

25
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.

26
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 Spines central repository.
• The UK has elected to put private industry
  contractors on-the-hook as solution
  providersbuffering 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.

27
Transition Adoption
28
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.

29
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.

30
Questions?