Interoperability in Healthcare - PowerPoint PPT Presentation

1 / 39
About This Presentation
Title:

Interoperability in Healthcare

Description:

Interoperability in Healthcare – PowerPoint PPT presentation

Number of Views:1899
Avg rating:3.0/5.0
Slides: 40
Provided by: duane3
Category:

less

Transcript and Presenter's Notes

Title: 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?
Write a Comment
User Comments (0)
About PowerShow.com