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

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

3. Agenda
Part 1: THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability 3 3

4. 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
What is IHE?
Optimal patient care requires efficient access to comprehensive electronic health records (EHRs). The Integrating the Healthcare Enterprise (IHE) initiative accelerates the adoption of the information standards needed to support EHRs. More than 100 vendors have implemented and tested products based on IHE.
IHE improves patient care by harmonizing healthcare information exchange. IHE provides a common standards-based framework for seamlessly passing health information among care providers, enabling local, regional and national health information networks. 4

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

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

7. Standards Adoption Process
Testing at Connectathons
IHE Demonstrations
Develop technical specifications
Products with IHE
Identify available standards (e.g. HL7, DICOM, IETF, OASIS)
Timely access to information
Easy to integrate products
Document Use Case Requirements

8. Stakeholder Benefits Healthcare providers and support staff Vendors
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

9. 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 and the Electronic Health Record (EHR)
IHE has defined a common framework to deliver the basic interoperability needed for local and regional health information networks. It has developed a foundational set of standards-based information exchange Integration Profiles with three interrelated efforts:
Cross-Enterprise Document Sharing (XDS) support for document content interoperability. This supports a standards-based EHR across clinical encounters and care settings.
A security framework for protecting the confidentiality, authenticity and integrity of patient care data.
Cross-domain patient identification management to ensure consistent patient information and effective searches for EHRs.
IHE: Offers consistent, standards-based record sharing for EHRs and other information systems

10. 12 Years of Steady Growth 1998 – 2010
The IHE Development Domains
12 Years of Steady Growth 1998 – 2010
Pathology since 2006
Radiation Oncology since 2004
Radiology since 1998
Cardiology since 2004
Patient Care Devices since 2005
Patient Care Coordination since 2004
Eye Care since 2006
Quality Research & Public Health since 2006
Laboratory since 2004
Pharmacy NEW 2009
(Healthcare) IT Infrastructure since 2003

11. 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
Germany
France
USA
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
Pragmatic global standards harmonization + best practices sharing 11 11 11

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

13. 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)
Generalized the systems because there are many ways vendors can bundle products.
Some PACS may include a Report Creator, others may not.
Some Modalities may include a Print Composer, others may not.

14. Product XYZ from Vendor T
The Product World…..
Product XYZ from Vendor T

15. The IHE World…. IHE Transaction IHE Transaction IHE Actor IHE Actor

16. Mapping IHE to Products
Product XYZ from Vendor T
Actor
Actor
IHE Transaction
IHE Transaction
IHE Actor
Actor
IHE Actor
IHE Transaction

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

18. 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
Key messages
Meeting the requirements of the healthcare professionals when exchanging patient clinical information is critical: trust in the information and ease of access is paramount.

19. Standards Adoption Process
Testing at Connectathons
IHE Demonstrations
Products with IHE
Timely access to information
Easy to integrate products
Develop technical specifications
Identify available standards (e.g. HL7, DICOM, IETF, OASIS)
Document Use Case Requirements

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

21. IHE Connectathons Massive yearly events : 70-80 vendors
engineers
systems
….integrated in 5 days
Vendors do not pass…
until an IHE Project Manager attest it !
Last Connectathon:
Chicago, USA, January 11-15, 2010
Bordeaux, France, April 12-16, 2010

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

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

25. HIMSS Interoperability Showcase

26. Example: 2010 HIMSS Interoperability Showcase

27. Implementation Tools (1)
Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more:
Microsoft under codeplex
NIST under Source Forge
HIE-OS under Source Forge
FHA CONNECT
More on the next page….. 27

28. Implementation Tools (2)
Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more, from Open Health Tools:
OHT – IHE Profiles (Charter)
OHT – Open Exchange (Forge)
OHT – Model Driven Health Tools (Charter)
September, 2005

29. Working Together to Deliver Interoperable Health Information Systems
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise and
Across Care Settings

30. 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
Key messages
Meeting the requirements of the healthcare professionals when exchanging patient clinical information is critical: trust in the information and ease of access is paramount.

31. 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.
Meeting the requirements of the patient when exchanging its information is critical: trust in the information and protecting the privacy and confidentiality for the consumer is paramount.

32. Categories of Healthcare Communication Services
HIEs and Shared EHRs
Patient and Provider ID Mgt
Hospitals
e.g. access to last 6 months historical labs and encounter summaries
e.g. get a current list of allergies or med list from a source
e.g. order a lab test, track status and receive results
Security
Document
Sharing
Dynamic
Information
Access
Workflow
Management
Source-persisted and attested health records
Specific info snapshot
provided on demand
2 or more entities
synchronize
a task
The different services performing health information exchange fall in three categories. Hospitals have traditionally use primarily Workflow Mgt type and Dynamic Query services. Document Sharing, little used in hospitals, is however one of the primary mode of information exchange is the sharing of persisted and attested health records among independent organizations. We will focus on Document sharing in the next few slides.

33. Categories of Healthcare Communication Services
HIEs and Shared EHRs
Patient and Provider ID Mgt
Hospitals
Medical Summary (XDS-MS)
e.g. access to last 6 months historical labs and encounter summaries
e.g. get a current list of allergies or med list from a source
e.g. order a lab test, track status and receive results
Security
Cross-Enterprise Document Sharing (XDS)
Document
Sharing
Dynamic
Information
Access
Workflow
Management
Source-persisted and attested health records
Specific info snapshot
provided on demand
2 or more entities
synchronize
a task
Patient Id Cross-Referencing (PIX)
The different services performing health information exchange fall in three categories. Hospitals have traditionally use primarily Workflow Mgt type and Dynamic Query services. Document Sharing, little used in hospitals, is however one of the primary mode of information exchange is the sharing of persisted and attested health records among independent organizations. We will focus on Document sharing in the next few slides.

34. IHE Profiles Specifications
Go to:
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)

35. The IHE Global Standards Adoption Process
First Step: Propose a Use case for Interoperability 35 35

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

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

38. The IHE Global Standards Adoption Process
Second Step: Propose a design and select standards for such an IHE Profile 38 38

39. Patient Identifier Cross-referencing for MPI Transaction Diagram

40. Patient Identifier Cross-referencing for MPI Process Flow Showing ID Domains & Transactions

41. Patient Identifier Cross-referencing for MPI
Identity
Patient
Cross References
B:X456 C: ?
B:X456 C: 2RT

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

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

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

45. Patient Identifier Cross-referencing for MPI Standards Used: 2 Profiles
PIX: HL7 Version 2.5
ADT Registration and Update Trigger Events (HL )
A01: inpatient admission
A04: outpatient registration
A05: pre-admission
A08: patient update
A40: 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)

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

47. 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: 47 47

48. Registering Health Records:IHE-XDS
Clinic Record
Community
Specialist Record
Hospital Record
Health Info Exchange
Repository of Documents
1-Reference
to records
Repository of Documents
Index of
patients records
Clinical Encounter
Clinical IT System
Then any edge systems, such as this clinical systems, may query the document registry (Step 2), and then retrieve documents of interest through their pointer provided by the registry (Srep 3). Finaly, the resulting information is presented to the resuesting physician in our example (Step 4).

49. 4-Patient data presented to Physician
Access to Shared Records : IHE-XDS
Clinic Record
Community
Specialist Record
Hospital Record
HIE
Repository of Documents
3-Records
Returned
Repository of Documents
Aggregate Patient Info
4-Patient data presented to Physician
Index of
patients records
Clinical Encounter
Clinical IT System
Then any edge systems, such as this clinical systems, may query the document registry (Step 2), and then retrieve documents of interest through their pointer provided by the registry (Srep 3). Finaly, the resulting information is presented to the resuesting physician in our example (Step 4).
2-Reference
to Records for Inquiry

50. 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.
Behind XDS, there are rather fundamental principles that ensure a cost-effective and flexible infrastructure that supports a broad range of centralized and decentralized configurations.

51. 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.)
XDS relies on an array of solid and world-wide adopted standards. Since its initial definition, XDS has been widely implemented and now reached full maturity. Adoption by national and regional projects, is now significant and continues to expand.

52. 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 on-demand pull in a variety of centralized or distributed architectures.
Offer a consistent, standards-based and functional record sharing for EHRs, PHRs & other IT Systems

53. Combining IHE Profiles Document Content & Modes of Document Exchange
Doc Content Profiles (Semantics content)
Scanned Doc
XDS-SD
Consent
BPPC
Emergency
EDR
Pre- Surgery
PPHP
Functional Status Assesment
FSA
Imaging
XDS-I
Laboratory
XD*-Lab
Discharge & Referrals
XDS-MS
PHR Exchange
XPHR
Document Exchange Integration Profiles
Document
Sharing XDS / XCA
Reliable Pt-Pt Interchange
XDR
Media Interchange
XDM
IHE Integration Profiles offer flexibility in that they can be mixed and matched to meet a broad range need.
This slide illustrates that not only XDS may be used to exchange documents, by interchange media such as USB keys and CDs are specified by the XDM Integration Profile. Likewise a varity of content

54. Patient Longitudinal Record
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

55. Building and accessing Documents
Documents Registry
Longitudinal Record as used across-encounters
Document Repository
Long Term Care
Acute Care (Inpatient)
Other Specialized Care or Diagnostics Services
Care Record systems supporting care delivery
PCPs and Clinics (Ambulatory)
Submission of Document References
Retrieve of selected Documents

56. Cross-Enterprise Document Sharing (XDS.b) Actor/Transaction Diagram

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

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

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

60. IHE, Global Standards-Based Profiles Adopted in National & Regional Projects (sample)
Lower
Austria
NETHERLANDS
Friesland
Natn’l Mamography
Italy Conto Corrente
Venetto - Friuli
France DMP
VITL-Vermont
Austria
Suisse St Gallen
Lausane
Quebec, Toronto, Alberta, British Columbia Canada Infoway
Wales
Imaging
France Imaging IDF
Boston Medical Center - MA
For more complete list see: tinyurl.com/wwXDS
Philadelphia HIE
Belgium
Flemish-Leuven
KeyHIE Pennsylvania
South Shore Hospital, NY
Boston Medical Center, MA
Vermont Information Technology Leaders, VT
KeyHIE/Geisinger Health System, PA
Lower Austria Region (near Vienna)
Friesland Cardiology Network
North Carolina Healthcare Information and Communications Alliance,NC
CareSpark, TN
Azienda Sanitaria Locale n. 4 Chiavarese
USA - NHIN
Austria-ELGA
France-DMP
Providence Health System, OR
South-Africa-Gauteng
Montreal McGill - Quebec
Toronto East Network - Ontario
British Columbia
Alberta
Project Doge
Italy Friuli Region
Ireland - National PACS
Japan-Nagoya
Shanghai
Kobe-Stroke Mgt
Cardiology Network Groningen
Amsterdam Radiology Network
Rotterdam HIE
Flemish Hospital Network
Dutch Mammo Screening
Mayo Clinic, MN
New York Presbyterian, NY
Italy-Health Optimum
IHE North American Connectathon, USA
CareSpark – TN & VA
SHARP CA
South Africa
THINC- New York
NCHICA – N. Carolina
Providence Health System - OR
CHINA-Shanghai
Imaging Info Sharing
CHINA-MoH
Lab results sharing
JAPAN-Nagoya
Imaging Info Sharing,
Nationwide PDI guideline
6060 60 60

61. 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
XDS is one integration profile among a consistent and growing family of profiles. When used together these profiles provide a solid basis for building a health information exchange.
IHE-XDS + related IHE Integration profiles provide a complete interoperability solution

62. IHE Integration Profiles for Health Info Nets What is available and in trial implementation
Security & Privacy
Clinical and PHR Content
Patient ID Mgmt
Emergency Referrals
Format of the Document Content and associated coded vocabulary
PHR Extracts/Updates
ObGyn Documents
Lab Results Document Content
Scanned Documents
Format of the Document Content
Imaging Information
Medical Summary
(Meds, Allergies, Pbs)
and associated coded vocabulary
Consistent Time
Coordinate time across networked systems
Audit Trail & Node Authentication
Centralized privacy audit trail and node to node authentication to create a secured domain.
Basic Patients Privacy Consents
Establish Consents & Enable Access Control
Document Digital Signature
Attesting “true-copy and origin
Cross-Enterprise User Assertion
Provides Trusted Identity
Patient Demographics Query
Patient Identifier Cross-referencing
Map patient identifiers across independent identification domains
Document Subscription and Notification
Request Form for Data Capture
External form with custom import/export scripting
Health Data Exchange
Other
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
Final Text Approved
Trial Implementation-2009– Final Txt 2010

63. XDS-MS Medical Summary or PHR Extract Exchange Profile based on HL7 CDA Rel 2 and HL7 CCD IG
Structured and Coded Header
Level 1
Patient, A
uthor, Authenticator, Institution,
Header always structured and coded
Time of Service, etc. S S t t r r u u c c t t u u r r e e d d C C o o n n t t e e n n t t w w i i t t h h c c o o d d e e d d s s e e c c t t i i o o n n s s : :
Level 2
Title -
coded sections with non -
structured
Reason for Referral
nor coded content (text, lists, tables).
Vital Signs
 Simple Viewing (XML Style sheet) M M e e d d i i c c a a t t i i o o n n
Text Structure
Entry
Med, Problems and Allergies
as highly structured text.
Text easy to import/parse
Level 3
Med Problems a nd
Allergies have a
fine-grain structure with
optional coding. Coding
Scheme explicitly identified.
Coded Section
Entry
Level 3
Studies A A l l l l e e r r g g i i e e s s
One of the most common information exchange neeed is to create an summary of a patient chart and share for other care provider to import. In this type of document, it is clear that the information content is not only textual information, but highly structured information for the most important information, medication, allergies, diagnosis, and patient demographics informations. This IHE medical summary, XDS-MS is based on the HL7 CDA release 2 standard, just like the PHR extract, XPHR, which is aligned on the ASTM/HL7 CCD implementation guide.
Social History P P r r o o b b l l e e m m s s
XDS-MS and XPHR enable both semantic interoperability & simple viewing !
Care Plan

64. 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 -to- Radiology
Radiology -to- Physicians
PACS Z
Imaging Center
The very same IHE XDS infrastructure used to share medical summaries, may alos be used to share diagnosis images and imaging reports. This is specified by the XDS-I integration proifile.
Physician Practice
Same XDS Infrastructure (Registry and Repositories) for medical summaries and imaging information !

65. in the Enterprise Interoperable Health Information Systems
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
And Across Care Settings
 Intra Hospital Workflows and Information Access
in the Enterprise

66. IHE Solutions within the Enterprise
EMR - HIS
eMPI
User Auth
Enterprise IT Infrastructure
Radiology
RIS
PACS
Img Acq
Laboratory
LIS
Auto Mgr
Analyzer
Cardiology
CIS
Cath
ECG
Eye Care
Pathology
Home Hub
Therapy Plan
Nursing Station
Established Feb 2009
Img Acq
Treatment
Devices
Devices
Devices
Radiation Therapy
Pharmacy
Intensive Care Unit

67. IHE Solutions within the Enterprise Example: Cardiology
EMR - HIS
eMPI
User Auth
Enterprise IT Infrastructure
Radiology
RIS
PACS
Img Acq
Laboratory
LIS
Auto Mgr
Analyzer
Cardiology
CIS
Cath
ECG
Eye Care
Pathology
Cardiology Integration Profiles
Cardiac Catheterization Lab Workflow
Echocardiography Lab Workflow
Retrieve ECG for Display
Displayable Reports
Cath and Echo Evidence Documents
Home Hub
Therapy Plan
Nursing Station
Established Feb 2009
Img Acq
Treatment
Devices
Devices
Devices
Radiation Therapy
Pharmacy
Intensive Care Unit 67 67

68. IHE Solutions within the Enterprise Example: IT Infrastructure
EMR - HIS
eMPI
User Auth
Enterprise IT Infrastructure
Radiology
RIS
PACS
Img Acq
Laboratory
LIS
Auto Mgr
Analyzer
Cardiology
CIS
Cath
ECG
IT Infrastructure Integration Profiles
Patient Administration Management
Patient Demographics Query
Patient Identifier Cross-referencing
Retrieve Information for Display
Enterprise User Authentication
Consistent Time
Patient Synchronized Applications
Audit Trail and Node Authentication
Personnel White Pages
Shared Value Sets
Eye Care
Pathology
Home Hub
Therapy Plan
Nursing Station
Established Feb 2009
Img Acq
Treatment
Devices
Devices
Devices
Radiation Therapy
Pharmacy
Intensive Care Unit 68 68

69. IHE Solutions within the Enterprise Example: Radiology
EMR - HIS
eMPI
User Auth
Enterprise IT Infrastructure
Radiology
RIS
PACS
Img Acq
Radiology Integration Profiles
Radiology Scheduled Workflow
Patient Information Reconciliation
Access to Radiology Information
Portable Data for Imaging
Consistent Presentation of Images
Key Image Note
Presentation of Grouped Procedures
Evidence Documents
Audit trail and Node Authentication (Rad option)
Teaching Files and Clinical Trials Export
Post-processing Workflow
Reporting Workflow
Charge Posting
Simple Image and Numeric Reports
Laboratory
LIS
Auto Mgr
Analyzer
Cardiology
CIS
Cath
ECG
Eye Care
Pathology
Home Hub
Therapy Plan
Nursing Station
Established Feb 2009
Img Acq
Treatment
Devices
Devices
Devices
Radiation Therapy
Pharmacy
Intensive Care Unit 69 69

70. IHE Solutions within the Enterprise Example: Laboratory
EMR - HIS
eMPI
User Auth
Enterprise IT Infrastructure
Radiology
RIS
PACS
Img Acq
Laboratory
LIS
Auto Mgr
Analyzer
Cardiology
CIS
Cath
ECG
Eye Care
Pathology
Laboratory Integration Profiles
Laboratory Testing Workflow
Laboratory Information Reconciliation
Laboratory Point Of Care Testing
Laboratory Device Automation
Laboratory Code Set Distribution
Laboratory BarCode
Home Hub
Therapy Plan
Nursing Station
Established Feb 2009
Img Acq
Treatment
Devices
Devices
Devices
Radiation Therapy
Pharmacy
Intensive Care Unit 70 70

71. Laboratory Testing Workflow (LTW) & Laboratory Device Automation (LDA)
Placer order
Order Placer
Order Filler
Filler order
Work order
Results
Results
Automation Manager
Order Result Tracker
Work Order Steps
Query & download modes
Tests results
Pre/post processor
Analyzer
LTW
LDA
Profiles based on HL7 V2.5.1
Solid implementation experience

72. IHE Solutions within the Enterprise Example: Patient Care Devices
EMR - HIS
eMPI
User Auth
Enterprise IT Infrastructure
Radiology
RIS
PACS
Img Acq
Laboratory
LIS
Auto Mgr
Analyzer
Cardiology
CIS
Cath
ECG
Patient Care Devices Profiles
Device Enterprise Communication (DEC)
Alarm Communication Mgt (ACM)
Subscribe to Patient Data (SPD)
Patient Identity Binding (PIB)
Rosetta Terminology Mapping (RTM)
Eye Care
Pathology
Home Hub
Therapy Plan
Nursing Station
Established Feb 2009
Img Acq
Treatment
Devices
Devices
Personal Devices
Radiation Therapy
Pharmacy
Intensive Care Unit 72 72

73. Working Together to Deliver Interoperable Health Information Systems
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise
and Across Care Settings

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

75. See you for Part 2, this afternoon