Interoperability in Healthcare

1
Interoperability in Healthcare

• Duane Falk
• Director, Enterprise Integration
• Information Services Division, UPMC

2
Industry Definition of Interoperability

• The ability of two or more systems or components
  to exchange information and to use the
  information that has been exchanged
• Institute of Electric and Electronic Engineers
  (IEEE)

3
Areas of Opportunity for Healthcare IT

• Care givers are most effective when they have all
  pertinent data about a patient and their
  condition
• Clinicians are most efficient when all pertinent
  data is easily available to them, from one
  source
• which is part of their routine workflow process
• The chance of error is reduced if medical
  vocabularies (medication names, lab test codes
  etc.) are the same across all systems

• Clinical decision support provides value by not
  just presenting data, but also acting on it
  appropriately (i.e. triggering rules and alerts)
  those actions should occur against the full,
  pertinent set of data
• Both care and cost effectiveness are enhanced by
  being able to monitor data across the enterprise
  to identify trends in individuals or populations
  and act on those appropriately

4
ONCHIT Healthcare IT Goals

• Inform Clinicians Expand the availability and
  use of electronic health records (EHRs)
• Interconnect Clinicians Interoperability, both
  within institutions and at regional and national
  levels
• Improve Population Health Includes unifying
  public health surveillance systems
• Personalize Care The personal health record (PHR)

Office of the National Coordinator for Health
Information Technology
5
Spectrum of Clinical System Approaches
native integration
requires integration
technology
Single Clinical Suite
Best of Breed
6
Few Institutions Are 100 Integrated
native integration
requires integration
technology
mix of suite and specialty systems
Single Clinical Suite
Best of Breed
7
Interaction with Outside Agencies
Reference labs
eRx partners
Payors
Inter-institutional transfers
Regulatory requirements
8
Realized Opportunity with Diverse Systems

• Care givers are most effective when they have all
  pertinent data about a patient and their
  condition
• Clinicians are most efficient when all pertinent
  data is easily available to them, from one
  source
• which is part of their routine workflow process
• The chance of error is reduced if medical
  vocabularies (medication names, lab test codes
  etc.) are the same across all systems

• Clinical decision support provides value by not
  just presenting data but acting on it
  appropriately (i.e. triggering rules and alerts)
  and those actions should occur in all appropriate
  systems, not just the data source
• Both care and cost effectiveness are enhanced by
  being able to monitor data across the enterprise
  to identify trends in individuals or populations
  and act on those appropriately

9
Realized Opportunity with Diverse Systems

• Care givers are most effective when they have all
  pertinent data about a patient and their
  condition
• Clinicians are most efficient when all pertinent
  data is easily available to them, from one
  source
• which is part of their routine workflow process
• The chance of error is reduced if medical
  vocabularies (medication names, lab test codes
  etc.) are the same across all systems

• Clinical decision support provides value by not
  just presenting data but acting on it
  appropriately (i.e. triggering rules and alerts)
  and those actions should occur in all appropriate
  systems, not just the data source
• Both care and cost effectiveness are enhanced by
  being able to monitor data across the enterprise
  to identify trends in individuals or populations
  and act on those appropriately

10
Outcomes of Clinical System Diversity

• Not all critical data entered in one system is
  available in others
• Clinicians must go to multiple
• sources to get the full record
• Data in one system does not
• execute rules and alerts in
• other systems
• There is no umbrella layer to
• monitor and act on the overall
• picture

11
The Answer (so far) HL7 Interfaces
12
Levels of Interoperability
Level 4 Conceptual Interoperability
A common knowledge framework is established. Not
only the data but interrelationships are
understood and acted on
Level 3 Semantic Interoperability
Not only data but also its contexts, information,
can be exchanged. The unambiguous meaning of
data is defined by common reference models, I.e.
std. medical vocabularies
Level 2 Syntactic Interoperability
Data can be exchanged in standardized formats,
the same protocols and formats are supported,
I.e. HL7
Level of interoperability
Level 1 Technical Interoperability
Physical connectivity is established allowing
bits and bytes to be exchanged

Level 0 No interoperability
No connection is established
Tolk, A. and Muguira, J.A. (2003). The Levels of
Conceptual Interoperability Model (LCIM).
Proceedings IEEE Fall Simulation
Interoperability Workshop, IEEE CS Press
13
Level of Interoperability Achieved with Interfaces
Level 4 Conceptual Interoperability
A common knowledge framework is established. Not
only the data but interrelationships are
understood and acted on
Level 3 Semantic Interoperability
Not only data but also its contexts, information,
can be exchanged. The unambiguous meaning of
data is defined by common reference models, I.e.
std. medical vocabularies
Level 2 Syntactic Interoperability
Data can be exchanged in standardized formats,
the same protocols and formats are supported,
I.e. HL7
Level of interoperability
Level 1 Technical Interoperability
Physical connectivity is established allowing
bits and bytes to be exchanged

Level 0 No interoperability
No connection is established
Tolk, A. and Muguira, J.A. (2003). The Levels of
Conceptual Interoperability Model (LCIM).
Proceedings IEEE Fall Simulation
Interoperability Workshop, IEEE CS Press
14
UPMC interoperability Roadmap
True Interoperability Interoperability service
oriented architecture (SOA) integrates with
uniform vendor SOA. SOA-cpmpliant access to
systems
Advanced Clinical Decision Support Semantic
interoperability knowledge frameworks are
developed to derive concepts from data and apply
those concepts to CDS. Ontologies.
Unified Clinical Decision Support Appropriate
enterprise rules/alerts functions are raised
above the EMR level and run against an
enterprise-wide, harmonized data set. Access to
aggregated data, monitoring and alerting tools,
notification access to EMRs
Functional Interoperability in addition to an
integrated view of data, key clinical data is
actionable against decision support functions in
physicians preferred EMR. Midleware to exchange
key data elements among EMRs, clinical policie
and processes to manage.
Baseline Interoperability The ability to
present an integrated view of data from all
systems. Data is standardized and normalized
across multiple domains. Integrated clinical
viewer
Foundation A robust interoperability
architecture is implemented, based on standards
and interconnected with existing integration
points of EMRs and other systems. Interfaces or
apis to clinical systems, middleware, patient
identification, security, auditing.
15
Interoperability Approaches

• Shotgun Approach
• Federated Model
• Data Repository Model

16
Shotgun Approach

• Send all pertinent data everywhere through
  interfaces
• Pros
• No new technology involved
• Cons
• Significant data duplication with potential
  impact on receiving systems
• Creation and maintenance of exponentially
  increasing number of interfaces
• Doesnt enforce any standardization of data
  elements, rules/alert definitions
• No coordination of decision support across
  systems
• Business intelligence capabilities are limited by
  whats available in emrs

17
Federated (query and retrieve) Model

• Data resides in source systems, organizations
• A central registry is created to track where
  patients have data
• User queries are sent to the registry, the
  registry identifies appropriate data sources and
  fetches data from them
• Data is pulled into a temporary integrated view
  or returned to querying system

18
Federated Model, cont.
Hospital B
Hospital A
1 Updt registry with Pt IDs
2 Hospital A sends query
3 Registry identifies that pt has records at
Hosp B, sends query to Hosp B
4 Hosp B returns pertinent data
5 Registry returns query results to Hosp A
Central Registry
19
Federated Model, cont.

• Pros
• Data is stored and controlled within source
  system or organization
• No permanent duplication of data
• Cons
• Potential query impact on source systems
  performance
• Limitations of query capabilities
• No central service for monitoring, umbrella-level
  decision support, business intelligence
• Data return limited by unavailability of any
  source system

20
Data Repository Model

• Critical clinical information is duplicated from
  source systems to a central clinical data
  repository (CDR)
• A clinical viewer provides an integrated view of
  the data
• Monitoring and clinical decision support is
  executed against the aggregated data

21
Data Repository Model, cont.
Hospital B
Hospital A
1 Source systems send selected data to CDR
3 Viewer queries CDR which finds all pertinent
data and returns to viewer
2 User queries via viewer
22
Data Repository Model, cont.

• Pros
• Limits performance impact on source systems
• Provides a central aggregation for monitoring,
  decision support, business intelligence
• Normalization of vocabularies, data can be done
  in one place
• Provides a service-oriented source for data
  queries
• Cons
• Data duplication
• Data is stored in outside of participating
  systems or organizations
• Aggregated data does not trigger rules/alerts
  within emrs
• Central point of failure

23
Which Model is Best?

• Depends on
• Interoperability goals view only or also need to
  act on aggregation of data
• Source system capabilities
• Security/IP concerns with central repository

24
UPMCs Interoperability Approach

• Build a CDR, aggregate selected clinical
  information
• Initial data set patients, encounters, labs,
  allergies, medication, problem lists,
  immunizations, documents (path, rad, encounter
  notes, DS etc)
• Standardize medical vocabularies in the CDR
• Build a clinical viewer that provides an
  integrated view from the CDR
• Build enterprise-level CDS rules and processes
• Send key data elements from the CDR to other emrs
  in order to execute critical rules within those
  emrs (e.g. allergies, meds)
• Provide or work with a registry service to
  connect CDR to community data networks (future)

25
UPMC Approach
3 User queries via viewer
4 Viewer queries CDR which finds all pertinent
data and returns to viewer
Ambulatory EMR
Inpatient EMR
1 Source systems send selected data to CDR
2 CDR sends key data to other emrs
5 CDS intelligence monitors and acts on data
Registry connects CDR to regional health record
CDR middleware integrates data into viewer
26
Components of CDR Solution
Presentation Layer (Viewer)
Business Logic
api calls
Security Auditing
Communication Layer
System Management
EMPI
Data Layer
Data Integration Layer
Legacy interface engine
Legacy Systems Data Sources
27
Foundation Considerations
Baseline
Functional
Unified CDS
Adv. CDS
Foundation

• Patient Identification
• Enterprise Master Patient Index (EMPI, or
  equivalent) is essential
• EMPI exceptions
• Data from non-EMPI registration points
• Backload data that pre-dates the EMPI
• Outside data
• Mechanisms for data validation
• Send exceptions through EMPI engine
• Follow-up search on demographics
• Thresholds or display all for manual selection
• Manual process for resolving potential duplicates
  or other discrepancies

28
Foundation Considerations
Baseline
Functional
Unified CDS
Adv. CDS
Foundation

• Data Format Database vs Document Mgmt System
• Continuity of care documents provide good
  mechanism for exchange and viewing of patient
  encounter data
• For permanent storage and CDS, database offers
  more granularity, flexibility
• Document standards
• CCR Continuity of Care Record from ASTM
• CDA Clinical document architecture, HL7 endorsed
  by HITSP (Health Info tech Stds Panel) the
• CCD Continuity of Care Document
• Content of the CCR mapped into the XML structure
  of the CDA
• Endorsed by HITSP (Health Information Technology
  Stds Panel)
• Database standards HL7 RIM (reference
  information model)-compliant
• Comprehensive, object-oriented information model
  for clinical healthcare

29
Integrated Data View
Baseline
Functional
Unified CDS
Adv. CDS
Foundation

• Provide clinicians with a single place to view
  all pertinent data on a patient
• Key Considerations
• Design screens, interaction and flow with
  clinician input
• Customizability
• Integrate with Workflow
• DO NOT add another login to clinician workflow
• Provide viewer access directly through emr or
  other clinical system, when available
• Desktop Context Management
• Synchronizing clinical viewer with emr
• CCOW (clinical context object workgroup of HL7)

30
Integrated Data View
Baseline
Functional
Unified CDS
Adv. CDS
Foundation

• But thats not what I saw when I looked at the
  record
• CDR is dynamic, data and view may change over
  time
• How do you audit what was seen by a given user at
  a given time?

31
Integrated Data View
Baseline
Functional
Unified CDS
Adv. CDS
Foundation

• Recreation of a given view requires three
  elements

database status
viewer properties
security policies
32
Managed Exchange of Data
Functional
Unified CDS
Adv. CDS
Foundation
Baseline

• Exchange key data elements among emrs so
  critical rules execute against a full dataset
• Considerations
• EMR system capability to accept and process data
  from inbound interfaces as though it were entered
  in that system
• Vocabulary standardization
• Clinical policies and procedures are vital
• Authority and precedence
• By system
• By clinician role
• Auto commit in emr or hold until approved
• Display all or resolve conflicts

33
Unified Clinical Decision Support
Unified CDS
Adv. CDS
Foundation
Baseline
Functional

• Develop CDS at an enterprise, umbrella level
• Considerations
• Criteria for extracting rules from emrs
• Rule relies on data beyond what is in emr (i.e.
  notice to physician that a patient has been
  admitted to a hospital)
• Type of decision that is not handled by the emr
• How does the umbrella layer interact with emrs
  for synchronous rules
• Asynchronous rules that fire outside of the
  workflow and send notification (i.e. Patient A
  has been admitted to Hospital B)
• Synchronous decision support rules that execute
  and require resolution during the course of
  workflow or data entry (I.e. duplicate order
  check)
• Balancing value against overload
• Number of rules firing
• Duplication of rules notifications
• Minimize number of locations clinician has to
  check for notifications

34
Advanced Clinical Decision Support
Adv. CDS
Foundation
Baseline
Functional
Unified CDS

• Monitor the CDR using knowledge framework
  concepts, identify and act on appropriate
  conditions using business intelligence and
  advanced clinical decision support rules
• i.e. Identify that a minor has been seen at four
  different EDs within the last six months
• i.e. If a patient matches conditions for
  diabetes, compare best practice steps identified
  in clinical pathway against actual occurrence and
  notify PCP of deviations
• Considerations
• Development of knowledge frameworks or ontologies
• Overload of notifications
• Capturing clinical documents (e.g. rad reports,
  encounter notes) in a CCD or CDA format allows
  extraction of individual data elements for
  presentation and CDS

35
Additional Goals

• Improve IT efficiency and reduce redundancy
• Replace multiple departmental databases
• Provide SOA-compliant apis for application
  developers
• Decrease the 600 HL7 interfaces in production

36
UPMCs Interoperability Project

• Partnered with clinical interoperability solution
  vendor
• 3-year project, with phased delivery
• Joint clinical and IT project with dedicated
  clinical leadership part of UPMCs eRecord
  program
• Core interoperability implementation
• Implement interoperability foundation
• Provide an integrated clinical viewer
• Provide api access for physician referral center
• Implement vocabulary standardization and
  normalization
• Manage exchange of key data among emrs
• Parallel development efforts
• Advanced clinical decision support engine
• Knowledge frameworks

37
UPMC Project Delivery Phases

• Foundation Integrated Data View
• Support CDS within emrs
• Develop umbrella CDS
• Advanced CDS
• Support IT Standards
• (i.e. CCD)
• SOA (i.e. std api access)

• Phase II, rel 1 (2/08), rel 2 (7/08)
• Phase III, exchange of key data, 2009
• Joint development, 3-yr timeline
• Joint development, 3-yr timeline
• Phase II
• Phase II

38
Personal Health Record

• Is it part of the electronic health record?
• Approaches to PHRs
• Sponsored, web-based PHR
• Patient-owned software program
• Personal storage PHR
• Mechanisms for capturing data
• Security considerations
• Viewing limited to clinician with whom patient
  shared info, or part of the general EHR
• Validity How is PHR data treated against emr
  source data

39
Questions?