Interoperability Workshop - E

Download Report

Transcript Interoperability Workshop - E

INTEGRATING THE
HEALTHCARE
ENTERPISE (IHE)
Orientation Workshop
International HL7 Interoperability Conference-10
Carlos Guilherme Costa, Product Manager, Alert, IHE US & Eu Connectathon
participant
Julio Carau, Director, Hospital de Clinicas "Dr. Manuel Quintela", Montevideo,
Uruguay
May, 2010
1
IHE Orientation-Rio de Janeiro
Agenda
This Morning:
Part 1: THE IHE STANDARDS ADOPTION PROCESS:
achieving practical interoperability
This Afternoon:
Part 2:
USERS AND VENDORS WORKING TOGETHER:
how can I contribute & benefit from IHE
HOW TO USE IHE RESOURCES: hands on experience
2
Agenda
Part 1: THE IHE STANDARDS ADOPTION PROCESS:
achieving practical interoperability
3
IHE: A Framework for Interoperability
A common framework for harmonizing and
implementing multiple standards
 Application-to-application
 System-to-system
 Setting-to-setting
Enables seamless health information movement
within and between enterprises, regions, nations
Promotes unbiased selection and coordinated use
of established healthcare and IT standards to
address specific clinical needs
4
Standards: Necessary…Not Sufficient
Standards are
 Foundational - to interoperability and communications
 Broad - varying interpretations and implementations
 Narrow - may not consider relationships between
standards domains
 Plentiful - often redundant or disjointed
 Focused - standards implementation guides focus only
on a single standard
IHE provides a standard process for
implementing multiple standards
5
IHE: Connecting Standards to Care
Healthcare professionals work with industry
Coordinate implementation of standards to
meet clinical and administrative needs
 Clinicians and HIT professionals identify the key
interoperability problems they face
 Providers and industry work together to develop and
make available standards-based solutions
 Implementers follow common guidelines in
purchasing and integrating effective systems
IHE: A forum for agreeing on how to implement
standards and processes for making it happen
6
Standards Adoption Process
Testing at
Connectathons
Develop
technical
specifications
Identify available
standards (e.g. HL7,
IHE
Demonstrations
Products
with IHE
DICOM, IETF, OASIS)
Timely access to
Document Use Case information
Requirements
Easy to integrate
products
7
Stakeholder Benefits
Healthcare providers and support staff





Improved workflows
Information whenever and wherever needed
Fewer opportunities for errors
Fewer tedious tasks/repeated work
Improved report turnaround time
Vendors
 Align product interoperability with industry consensus
 Decreased cost and complexity of interface installation and
management
 Focus competition on functionality/service space not information
transport space
SDOs
 Rapid feedback to adjust standards to real-world
 Establishment of critical mass and widespread adoption
8
IHE Implementation Strategy
Leverage established standards to allow rapid deployment and
plan for future
Pragmatic, Ease of Evolution
Enable architectural freedom (patient vs. provider centric,
centralized vs. decentralized, scalable (from office to
enterprise to IDN to Regional and National Networks)
Configuration flexibility
Support breakthrough use cases: variety of care settings, care
coordination, public health, PHR, EHR
Interoperability for broad constituencies
IHE: Offers consistent, standards-based record
sharing for EHRs and other information systems
9
The IHE Development Domains
12 Years of Steady Growth 1998 – 2010
Radiology
since 1998
Pharmacy
NEW 2009
Cardiology
since 2004
Pathology
since 2006
Laboratory
since 2004
Eye Care
since 2006
Quality
Research & Public Health
since 2006
(Healthcare)
IT Infrastructure
since 2003
Patient Care Devices
since 2005
Radiation Oncology
since 2004
Patient Care Coordination
since 2004
10
International Growth of IHE
Switzerland



Local Deployment, National Extensions
Promotional & Live Demonstration Events
Over 300 Organizational Members (all stakeholders)
Malaysia
Turkey
China
Australia
Austria
Spain
Netherlands
Taiwan
Canada
UK
Japan
Italy
France
Germany
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
USA
11
Pragmatic global standards harmonization + best practices sharing
IHE Integration Profiles - Model
Actors in precisely defined roles
 Abstracts a specific function of information system
…Executing precisely defined transactions
 Using existing standards
……To solve real world interoperability
problems
 Specifying Integration Profiles
12
Key IHE Concepts
• Generalized Systems
-> Actors
• Interactions between Actors
-> Transactions
• Problem/Solution Scenarios
-> Integration
Profiles
• For each Integration Profile:
• the context is described (which real-world problem)
• the actors are defined (what systems are involved)
• the transactions are defined (what must they do)
13
The Product World…..
Product XYZ
from Vendor T
14
The IHE World….
Actor
Actor
IHE
Transaction
IHE Actor
IHE Actor
IHE
Transaction
IHE Actor
Transaction
15
Mapping IHE to Products
Actor
Actor
IHE
IHE Actor
Transaction Product XYZ
from Vendor T
IHE Actor
IHE
Transaction
IHE Actor
Transaction
16
Organization of Technical Frameworks
Volume 1: Integration and content
Profiles
 Describes clinical need and use cases
 Identifies :
• the actors and transactions or,
• content modules
Volume 2+ of Technical Framework
 Provides implementation specification for
transactions or content modules
17
IHE and Service Oriented Architectures
SOA is a powerful business driven design methodology
SOA “wraps” interoperability in “services”, but does not
solve interoperability:
 E.g. Web Services may or may not be used in SOA. IHE Profiles are
largely (not always) based on Web Services.
 Standardizing Services “offered” along with the “protocols” is 20
years old (Open System Interconnect). Good, but a Service
definition does not result in compatibility “on the wire”.
IHE Integration profiles are supportive of Service Oriented
Architecture, but do not “require” use of SOA. IHE is
Service Aware !

Bits have to be compatible on the wire:
No way to avoid specifying transaction & content
18
Standards Adoption Process
Testing at
Connectathons
Develop
technical
specifications
Identify available
standards (e.g. HL7,
IHE
Demonstrations
Products
with IHE
DICOM, IETF, OASIS)
Timely access to
Document Use Case information
Requirements
Easy to integrate
products
19
IHE Connectathon
Open invitation to vendor and other
implementors community
Advanced testing tools (GAZELLE)
Testing organized and supervised by
project management team
Thousands of cross-vendor tests performed
Results recorded and published
20
IHE Connectathons
Massive yearly events :
70-80 vendors
250-300 engineers
100-120 systems
….integrated in 5 days
Last Connectathon:
Chicago, USA, January 11-15, 2010
Bordeaux, France, April 12-16, 2010
Vendors do not pass…
until an IHE Project Manager attest it !
21
http://www.ihe.net/Connectathon/index.cfm
22
Leveraging IHE Integration Statements
Vendors
 Claim IHE Compliance in an explicit way
 Can rely on an objective and thorough specification
(IHE Technical Framework)
 Willing to accept contractual commitments
 Willing to correct “implementation errors”
Buyers
 Can compare product integration capabilities
 Simplify and strengthen their RFPs
 Can leverage a public and objective commitment
 Decreased cost and complexity of interface deployment and
management
23
IHE Demonstrations: NOT an IHE Connectathon
IHE Connectathon is about qualifying “real-world
implementations”. Strict process and controlled
technical testing activity.
 It is the stick !
IHE demonstration is about education and promotion
about what some “connectathon tested
implementations” can achieve.
 It is the carrot !
Implementations participating to an IHE
Demonstration are required to have passed an IHE
Connectahon. Not all vendors and products are
demonstrated.
24
HIMSS Interoperability Showcase
25
Example: 2010 HIMSS Interoperability Showcase
26
Implementation Tools (1)
Open source implementations are available for XDS,
XCA, XCPD, PIX, PDQ, ATNA, CT, and more:
Microsoft under codeplex
http://ihe.codeplex.com/
NIST under Source Forge
http://sourceforge.net/projects/iheos/
HIE-OS under Source Forge
http://sourceforge.net/projects/hieos/
FHA CONNECT
http://www.connectopensource.org
More on the next page…..
27
Implementation Tools (2)
Open source implementations are available for XDS,
XCA, XCPD, PIX, PDQ, ATNA, CT, and more, from Open
Health Tools: http://www.projects.openhealthtools.org
OHT – IHE Profiles (Charter)
https://iheprofiles.projects.openhealthtools.org
OHT – Open Exchange (Forge)
https://openexchange.projects.openhealthtools.org
OHT – Model Driven Health Tools (Charter)
https://mdht.projects.openhealthtools.org
September, 2005
28
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise and
Across Care Settings
http://www.ihe.net
29
Requirements for an open HIE/EHR
Bring trust and ease of use for healthcare professionals:
 Care delivery organizations choose information to
share:
•
Based on patient health status
•
When they see fit (discharge, end of encounter, etc.)
•
What information to share (pick relevant documents, and content elements).
 Care delivery organizations access patient info through:
•
Their own local EMR (if they have one)
•
Through a shared portal/service otherwise.
 When accessing patient info:
•
Find quickly if relevant information is available or not (single query)
•
May select among relevant records (may be done in background)
•
Among them chose to import whole or part in local patient record
30
Requirements for an open HIE/EHR(2)
Bring trust and privacy to patients:
 Only authorized organizations and authenticated
healthcare providers may transact in the HIE:
•
Each node or IT system interfaced is strongly authenticated
•
Each user shall be authenticated on the edge system
•
All traffic trough the infrastructure is encrypted
 Patient consent needs multiple choices or levels
•
Unless opt-in, no data about a specific patient may be shared
•
Several data sharing policies offered to the patient consent
•
Each shared record/document is assigned to specific policies
(or not shared) at encounter time.
•
Healthcare providers may only access records/documents
compatible with their role.
31
Categories of Healthcare Communication Services
HIEs and Shared EHRs
e.g. access to last 6
months historical
labs and encounter
summaries
Source-persisted
and attested health
records
Document
Sharing
Hospitals
e.g. get a current list
of allergies or med
list from a source
Specific info
snapshot
provided on demand
Dynamic
Information
Access
e.g. order a lab test,
track status and
receive results
2 or more entities
synchronize
a task
Workflow
Management
Patient and Provider ID Mgt
Security
32
Categories of Healthcare Communication Services
HIEs and Shared EHRs
Medical Summary
e.g. access
to last 6
e.g. get a current list
(XDS-MS)
months historical
of allergies or med
labs and encounter
list from a source
summaries
Cross-Enterprise
Source-persistedDocument Sharing
(XDS)
Specific info
and attested health
records
Document
Sharing
snapshot
provided on demand
Dynamic
Information
Access
Hospitals
e.g. order a lab test,
track status and
receive results
2 or more entities
synchronize
a task
Patient Id CrossWorkflow
Referencing (PIX)
Management
Patient and Provider ID Mgt
Security
33
IHE Profiles Specifications
Go to: www.ihe.net/Technical_framework
For XDS:Under IT Infrastructure
 E.g. IT Infrastructure Technical Framework (XDS.b)
For PIX:Under IT Infrastructure
 E.g. IT Infrastructure Technical Framework (PIX, HL7V2)
 Or PIXV3 supplement (PIX HL7 V3).
For XDS-MS: Under Patient Care Coordination
 E.g. PCC Technical framework (XDS-MS)
34
The IHE Global Standards Adoption Process
First Step:
Propose a Use case for Interoperability
35
Patient Identifier Cross-referencing for MPI
Services
Allow all enterprise participants to register the
identifiers they use for patients in their domain
Participants retain control over their own domain’s
patient index(es)
Support domain systems’ queries for mapping across
other systems’ identifiers for their patients
Optionally, notify domain systems when other systems
update identifiers mapping for their patients
36
Patient Identifier Cross-referencing for MPI
Value Proposition
Maintain and linked all systems’ identifiers for a
patient in a single location
Use any algorithms (encapsulated) to find matching
patients across disparate identifier domains
Lower cost for synchronizing data across systems
 No need to force identifier and format changes onto existing
systems
Leverages standards and transactions already used
within IHE
37
The IHE Global Standards Adoption Process
Second Step:
Propose a design and select standards for
such an IHE Profile
38
Patient Identifier Cross-referencing for MPI
Transaction Diagram
Patient Identity Source
Patient Identity Feed [ITI-8]
Patient Identity
Consumer
 PIX Query [ITI-9]
 PIX Update Notification [ITI-10]
Patient Identity Crossreference Manager
39
Patient Identifier Cross-referencing for MPI
Process Flow Showing ID Domains & Transactions
Patient Identity Feed
& Patient Identity
References
Patient
Identification
Domain A
Patient Identity
Cross-reference
Manager
Patient
Identity
Feed
Patient Identity
Source
Internal
Domain
transactions
Patient Identification
Cross-reference Domain
Patient
Identity
Cross
References
Patient Identity
Consumer
Other
IHE Actor
Patient Identification
Domain B
Patient
Identity
Feed
Patient Identity
Source
Internal
Domain
transactions
Patient
Identity
Cross References
Patient Identity
Consumer
Other
IHE Actor
Patient Identification
Domain C
40
Patient Identifier Cross-referencing for MPI
Patient Identity Cross-reference
Manager
B:X456 = C:2RT
A:123 = B:Y921 = C:3TY
B:D456
A:235 = B:DF45
A:678
Id=123
Id=235
Patient
Identification
Domain A
Id=X456
Id=Y921
Id=D456
Id=DF45
Patient Identification
Domain B
Id=3TY
Id=2RT
B:X456
C: ?
Patient
Identification
Cross-reference
Domain
B:X456
C: 2RT
Patient
Identity
Cross References
Patient Identification
Domain C
Patient Identity
Consumer
41
Patient Identifier Cross-referencing for MPI
Actors
Patient Identity Source
 Definition
•
•
•
Assigns patient identities within its own domain
Notifies Patient Identifier Cross-reference Manager of all events
related to patient identification (creation, merge, etc.)
Example: Registration (ADT) Actor in IHE Radiology Scheduled
Workflow (SWF) Profile
 Transaction Supported - Required
•
Patient Identity Feed [ITI-8] (as sender)
42
Patient Identifier Cross-referencing for MPI
Actors
Patient Identifier Cross-reference Consumer
 Definition
•
•
Requires information about patient identifiers in other domains
Requests patient identifier information from Patient Identifier
Cross-reference Manager
 Transaction Supported - Required
•
PIX Query [ITI-9] (as sender)
 Transaction Supported - Optional
•
PIX Update Notification [ITI-10] (as receiver)
43
Patient Identifier Cross-referencing for MPI
Actors
Patient Identifier Cross-reference Manager
 Definition
•
•
•
Serves a well-defined set of Patient Identifier Domains
Receives patient identifier information from Patient Identity Source
Actors
Manages cross-referencing of identifiers across domains
 Transactions Supported - Required
•
•
•
Patient Identity Feed [ITI-8] (as receiver)
PIX Query [ITI-9] (as receiver)
PIX Update Notification [ITI-10] (as sender)
44
Patient Identifier Cross-referencing for MPI
Standards Used: 2 Profiles
PIX: HL7 Version 2.5
 ADT Registration and Update Trigger Events (HL7 2.3.1)
•
•
•
•
•
A01:
A04:
A05:
A08:
A40:
inpatient admission
outpatient registration
pre-admission
patient update
merge patient
 Queries for Corresponding Identifiers (ADT^Q23/K23)
 Notification of Identifiers Lists Updates (ADT^A31)
PIX V3: HL7 V3
 Leverage Web Services (harmonized WS by IHE
Appendix V)
45
The IHE Global Standards Adoption Process
Third Step:
Engage implementers for Testing Trial Implementation
profile at Connectathons
Fourth Step:
Based on lessons learned from Connectathons
implementers, correct/clarify Profile and Publish as
“Final Text” in Domain Technical Framework.
 Will be presented in part 2
46
IHE offers a broad collection of Profiles
Use Cases addressed are specified in a series of Domain
Technical Frameworks (Volume 1)
Two broad classes of profiles: Integration (how to move
the data) and Content (what the data conveys).
A few example of “cross-enterprise” integration and
content profiles
Complete list on: www.ihe.net/technical_framework
47
Registering Health Records:IHE-XDS
Community
Clinic Record
Hospital Record
Repository of
Documents
Clinical IT System
1-Reference
to records
Specialist Record
Repository of
Documents
Index of
patients records
Health Info Exchange
Clinical Encounter
48
Access to Shared Records : IHE-XDS
Community
Clinic Record
Specialist Record
Hospital Record
Repository of
Documents
Repository of
Documents
3-Records
Returned
4-Patient data
presented to
Physician
Clinical IT System
Aggregate
Patient Info
Clinical Encounter
HIE
Index of
patients records
2-Reference
to Records
for Inquiry
49
Health Information Exchanges Interoperability:
Cross-enterprise Document Sharing
Cross-Enterprise Document Sharing simplifies clinical
data management by defining interoperable infrastructure.
Transparency = Ease of Evolution
Patients have guaranteed portability and providers may
share information without concerns of aggregation errors.
Digital Documents = Patients and providers empowerment
Supports both centralized and decentralized repository
architectures. Ease of federation nationally. Flexible
privacy, Flexibility of configurations
Addresses the need for a longitudinal healthcare data
(health records). Complements to interactive workflow or
dynamic access to data.
50
Cross-Enterprise Document Sharing (XDS)
Standards Used
Healthcare
Content Standards
HL7 CDA header extract
HL7 data types
Electronic Business
Standards
ebXML Registry, SOAP,
Web Services …
Internet Standards
HTTP, IETF, W3C, …
Implemented world-wide by over 150 vendors/open
source.
Adopted in several national & regional projects:
Italy, Austria, Canada, USA, Japan, South Africa, France, Netherlands,
etc.)
51
Why is IHE-XDS a breakthrough ?
It based on an International Standards; ebXML registry: OASIS and
ISO standard, Web Service/Soap/XML.
Sharing of digital documents as “attested by the source”, meets the
most urgent needs. A proven healthcare community data-sharing
paradigm (Feeding a central web server is view only and hinders use of EHRs).
Efficient to support all types of Health IT Systems (IDNs, Hospitals,
Ambulatory, Pharmacy, Diagnostics Centers, etc.) and all types of
information (summaries, meds, images, lab reports, ECGs, etc.),
structured and unstructured.
Meets both the needs of push communication by info sources and ondemand pull in a variety of centralized or distributed architectures.
Offer a consistent, standards-based and functional
record sharing for EHRs, PHRs & other IT Systems
52
Combining IHE Profiles
Document Content & Modes of Document Exchange
Doc Content Profiles (Semantics content)
Scanned Doc
Consent
Emergency
XDS-SD
BPPC
EDR
Imaging
Laboratory
XDS-I
XD*-Lab
PreSurgery
Functional Status
Assesment
PPHP
FSA
Discharge &
Referrals
PHR
Exchange
XDS-MS
XPHR
Document
Sharing
Reliable Pt-Pt
Interchange
Media
Interchange
XDS / XCA
XDR
XDM
Document Exchange Integration Profiles
53
Typically, a patient goes through a sequence
of encounters in different Care Settings
Long Term Care
Acute Care
(Hospital)
Other Specialized Care
(incl. Diagnostics Services)
GPs and Clinics
(Ambulatory)
Continuity of Care:
Patient Longitudinal Record
54
Building and accessing Documents
Longitudinal Record
as used
across-encounters
Documents Registry
Long Term Care
Document
Repository
Acute Care
(Inpatient)
Other Specialized Care
or Diagnostics Services
PCPs and Clinics
(Ambulatory)
Care Record systems
supporting care delivery
Submission of Document References
Retrieve of selected Documents
55
Cross-Enterprise Document Sharing (XDS.b)
Actor/Transaction Diagram
Patient
Identity Source
Patient Identity
Feed
Document
Registry
Query
Documents
Document
Consumer
Register
Document Set
Document
Source
Provide&Register
Document Set
Document
Repository
Retrieve
Document Set
56
XDS – Value Proposition
Foundation for Health IT Infrastructures: Shared
Electronic Health Record, in a community, region, etc.
Effective means to contribute and access clinical
documents across health enterprises.
Scalable sharing of documents between private
physicians, clinics, long term care, pharmacy, acute
care with different clinical IT systems.
Easy access: Care providers are offered means to
query and retrieve clinical documents of interest.
57
XDS - Value Proposition
Distributed: Each Care delivery organization “publishes” clinical
information for others. Actual documents may remain in the
source EHR
Cross-Enterprise: A Registry provides an index for published
information to authorized care delivery organizations belonging
to the same clinical affinity domain (e.g. a region).
Document Centric: Published clinical data is organized into
“clinical documents”. using agreed standard document types
(HL7-CDA, PDF, DICOM, etc.)
Document Content Neutral: Document content is processed only
by source and consumer IT systems.
Standardized Registry Attributes: Queries based on meaningful
attributes ensure deterministic document searches.
58
How real is XDS ?
Stable specification IHE Technical Framework Published
XDS.b Supplement that offers:



Use most recent Web Services stds (MTOM/XOP)
Allow Retrieve sets of Documents in one transaction
Same services
First implementation in clinical use in region of Genoa Italy) since early 2006.
Several since: Lower Austria region, State of Vermont,
Nagoya city, South Africa region, Dutch regions, etc.
Adopted by several national programs world-wide
4 open source toolkits available, numerous product
implementations in EMRs and Infrastructure offerings.
59
IHE, Global Standards-Based Profiles
Adopted in National & Regional Projects (sample)
NETHERLANDS
Friesland
Natn’l Mamography
Wales
Imaging
Lower
Austria
France
DMP
France
Imaging
IDF
Austria
Italy
Conto Corrente
Venetto - Friuli
Suisse
St Gallen
Lausane
Quebec, Toronto,
Alberta, British Columbia
Canada Infoway
VITL-Vermont
Boston Medical
Center - MA
For more complete list see:
tinyurl.com/wwXDS
Belgium
Flemish-Leuven
Philadelphia HIE
KeyHIE
Pennsylvania
CareSpark
– TN & VA
SHARP
CA
South Africa
CHINA-Shanghai
Imaging Info Sharing
CHINA-MoH
Lab results sharing
JAPAN-Nagoya
Imaging Info Sharing,
Nationwide PDI guideline
Providence
Health System OR
THINC- New York
NCHICA – N. Carolina
660
IHE-XDS is part of a family of profiles
Regional, national, local or disease centric networks need
a consistent set of Integration Profiles
Fifthteen Integration Profiles completed and tested, plus
five ready to implement = Standards-based
interoperability building blocks for




Rich Document Content for end-to-end application interoperability.
Patient identification management
Security and privacy
Notification and data capture
IHE-XDS + related IHE Integration profiles provide a
complete interoperability solution
61
IHE Integration Profiles for Health Info Nets
What is available and in trial implementation
Clinical and PHR Content
Emergency Referrals
Format
of the Document Content
PHR
Extracts/Updates
and
associated
coded vocabulary
ObGyn
Documents
Format
of the
Document Content
and
associated
coded vocabulary
Lab
Results
Document
Format of the Document Content
Content
Scanned
Documents
and associated
coded vocabulary
Format of the Document Content
Format
of theInformation
Document
Imaging
and associated
coded Content
vocabulary
Medical
Format
of theSummary
Document Content
and(associated
codedPbs)
vocabulary
Meds, Allergies,
Format of the Document Content
and associated coded vocabulary
Security & Privacy
Basic Patients Privacy
Consents
Establish Consents & Enable
Access Control
Cross-Enterprise User
Assertion
Provides Trusted Identity
Document Digital
Signature
Patient ID Mgmt
Patient Demographics
Query
Patient Identifier
Cross-referencing
Map patient identifiers across
independent identification
domains
Attesting “true-copy and origin
Health Data Exchange
Cross-Enterprise
Document Sharing
Registration, distribution and access
across health enterprises of clinical
documents forming a longitudinal record
Cross-Enterprise Document
Pt-Pt Reliable Interchange
Cross-Enterprise Document
Media Interchange
Cross-Community Access
Audit Trail & Node
Authentication
Centralized privacy audit trail and node
to node authentication to create a
secured domain.
Consistent Time
Coordinate time across networked
systems
Other
Request Form
for Data Capture
External form with custom
import/export scripting
Document
Subscription and
Notification
Final Text Approved
62
Trial Implementation-2009– Final Txt 2010
XDS-MS Medical Summary or PHR Extract Exchange
Profile based on HL7 CDA Rel 2 and HL7 CCD IG
Structured and Coded Header
Patient, Author, Authenticator, Institution,
Time of Service, etc.
St r u c t u r ed Co n t en t w i t h c o d ed s ec t i o n s :
 Reason for Referral
 Vital Signs
 Medication
Text Structure
Entry
Coded Section
Entry
Level 1
Level 2
Level 3
 Studies
 Allergies
Text Structure
Entry
Coded Section
Entry
 Social History
 Problems
Text Structure
Entry
 Care Plan
Coded Section
Entry
Level 3
Header always structured and coded
Title-coded sections with non-structured
nor coded content (text, lists, tables).
 Simple Viewing (XML Style sheet)
Med, Problems and Allergies
as highly structured text.
Text easy to import/parse
Med Problems and
Allergies have a
fine-grain structure with
optional coding. Coding
Scheme explicitly identified.
XDS-MS and XPHR enable both semantic
interoperability & simple viewing ! 63
Use of a shared XDS infrastructure to access
Radiology Reports and Images (XDS-I)
Between Radiology and :
• Imaging specialists
• Non-imaging clinicians
Hospital
PACS Y
Radiology -toRadiology
Radiology -toPhysicians
Physician Practice
PACS Z
Imaging Center
Same XDS Infrastructure (Registry and Repositories)
for medical summaries and imaging information !
64
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise
And Across Care Settings
 Intra Hospital Workflows and Information Access
http://www.ihe.net
65
IHE Solutions within the Enterprise
EMR - HIS
Enterprise
IT Infrastructure
eMPI
User Auth
RIS
CIS
LIS
Eye Care
Pathology
Img Acq
PACS
Cath
Cardiology
Radiology
Therapy Plan
Img Acq
Treatment
Radiation Therapy
Established
Feb 2009
Pharmacy
ECG
Auto Mgr
Analyzer
Laboratory
Nursing Station
Home
Hub
Devices
Devices
Intensive Care Unit
Devices
66
IHE Solutions within the Enterprise
Example: Cardiology
EMR - HIS
Enterprise
IT Infrastructure
eMPI
User Auth
RIS
CIS
LIS
Eye Care
Pathology
Img Acq
PACS
Cath
ECG
Cardiology
Radiology
Auto Mgr
Analyzer
Laboratory
Cardiology Integration Profiles
Therapy Plan
Img
Treatment
Cardiac Catheterization Lab Workflow
Echocardiography Lab Workflow
Established
Retrieve ECG
for Display
Acq
Displayable Reports
Feb 2009
Cath and Echo Evidence Documents
Radiation Therapy
Pharmacy
Nursing Station
Home
Hub
Devices
Devices
Intensive Care Unit
Devices
67
IHE Solutions within the Enterprise
Example: IT Infrastructure
Enterprise
IT Infrastructure
eMPI
EMR - HIS
User Auth
RIS
Img Acq
Radiology
Therapy Plan
IT Infrastructure Integration Profiles
CIS
LIS
Patient Administration Management
Patient Demographics Query
Patient Identifier Cross-referencing
Retrieve
for Display
ECG
PACSInformation Cath
Enterprise User Authentication
Consistent Time Cardiology
Patient Synchronized Applications
Audit Trail and Node Authentication
Personnel White Pages
Shared Value Sets
Img Acq
Treatment
Radiation Therapy
Established
Feb 2009
Pharmacy
Eye Care
Pathology
Auto Mgr
Analyzer
Laboratory
Nursing Station
Home
Hub
Devices
Devices
Intensive Care Unit
Devices
68
IHE Solutions within the Enterprise
Example: Radiology
EMR - HIS
Enterprise
IT Infrastructure
eMPI
Radiology Integration Profiles
RIS
Img Acq
PACS
Radiology
Therapy Plan
Img Acq
Treatment
Radiation Therapy
Radiology Scheduled Workflow
User Auth
Patient Information Reconciliation
Access to Radiology Information
Portable Data for Imaging
LIS
Consistent CIS
Presentation of Images
Eye Care
Key Image Note
Pathology
Presentation of Grouped Procedures
Analyzer
ECG
Auto Mgr
Cath
Evidence
Documents
AuditCardiology
trail and Node AuthenticationLaboratory
(Rad option)
Teaching Files and Clinical Trials Export
Post-processing Workflow
Home
Reporting Workflow
Nursing Station
Hub
Charge
Posting
Established
Simple Image and Numeric Reports
Feb 2009
Pharmacy
Devices
Devices
Intensive Care Unit
Devices
69
IHE Solutions within the Enterprise
Example: Laboratory
Enterprise
IT Infrastructure
eMPI
EMR - HIS
User Auth
RIS
CIS
Laboratory
IntegrationCath
Profiles
Img
Acq
PACS
Laboratory Testing Workflow
Laboratory Information Reconciliation Cardiology
Radiology
Laboratory Point Of Care Testing
Laboratory Device Automation
Laboratory Code Set Distribution
Laboratory BarCode
Therapy Plan
Img Acq
Treatment
Radiation Therapy
Established
Feb 2009
Pharmacy
LIS
Eye Care
Pathology
ECG
Auto Mgr
Analyzer
Laboratory
Nursing Station
Home
Hub
Devices
Devices
Intensive Care Unit
Devices
70
Laboratory Testing Workflow (LTW)
& Laboratory Device Automation (LDA)
Placer order
Order Placer
Order Filler
Filler order
Results
Work order
Results
Automation
Manager
Order Result
Tracker
LTW
Work Order Steps
Query & download
modes
Tests
results
Pre/post
processor
Analyzer
LDA
Profiles based on HL7 V2.5.1
Solid implementation experience
71
IHE Solutions within the Enterprise
Example: Patient Care Devices
EMR - HIS
Enterprise
IT Infrastructure
eMPI
User Auth
Patient Care Devices Profiles
Device Enterprise Communication (DEC)
RIS
CIS
Alarm Communication Mgt (ACM)
Img Acq
Subscribe to Patient Data (SPD)
Patient Identity Binding (PIB)
Rosetta Terminology Mapping (RTM)
PACS
Cath
Cardiology
Radiology
Therapy Plan
Img Acq
Treatment
Radiation Therapy
Established
Feb 2009
Pharmacy
LIS
Eye Care
Pathology
ECG
Auto Mgr
Analyzer
Laboratory
Nursing Station
Home
Hub
Devices
Devices
Intensive Care Unit
Personal
Devices
72
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise
and Across Care Settings
http://www.ihe.net
73
Agenda
Part 1: THE IHE STANDARDS ADOPTION PROCESS:
achieving practical interoperability
This Afternoon:
Part 2:
USERS AND VENDORS WORKING TOGETHER:
how can I contribute & benefit from IHE
HOW TO USE IHE RESOURCES:
hands on experience
74
See you for Part 2, this afternoon
May, 2010
75
IHE Orientation-Rio de Janeiro