1. INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop
International HL7 Interoperability Conference-08
Charles Parisot, IHE Europe, GE Healthcare, Buc, France
Eric Poiseau, IHE Europe Technical Project Manager, INRIA Rennes

2. Agenda
08:30-10:30 THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability - Charles Parisot
Coffee Break
11:00-12:30 USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE – Charles Parisot
Lunch Break
13:30-15:00 HOW TO USE IHE RESOURCES: hands on experience – Eric Poiseau

3. Agenda
08:30-10:30 THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability
Coffee Break
11:00-12:30 USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE – Charles Parisot
Lunch Break
13:30-15:00 HOW TO USE IHE RESOURCES: hands on experience – Eric Poiseau

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 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 RHIO) 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. Growth in IHE Domains Over 200 vendors involved world-wide
Veterinary
Endoscopy
Pharmacy
Over 200 vendors involved world-wide
8 Technical Frameworks
64 Integration Profiles
Testing at “Connectathons” world-wide
Demonstrations at major conferences world-wide
Public Health, Quality and Research
Pathology
Patient Care Devices (3 profiles)
Patient Care Coord. (5 profiles)
Radiation Oncology (3 profiles)
Eye Care (4 profiles)
Laboratory (6 profiles)
Cardiology (7 profiles)
IT Infrastructure for Healthcare (20 profiles)
Radiology (18 profiles)
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008

11. International Growth of IHE
Australia
Local Deployment
National Extensions
Promotional & Live Demonstration Events
Funding
Austria
China
Spain
Netherlands
Norway
Taiwan
Korea
Canada UK
Japan
Italy
Germany
France
USA
1999
2000
2001
2002
2003
2004
2005
2006
2007
2088
Pragmatic global standards harmonization + best practices sharing 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. IHE Technical Frameworks Implementation Guide for each Integration Profile
An Integration Profile :
A Set of Actors
Exchanging Transactions
Use cases Process Flows
Actors
Transactions
For each transaction:
Std referenced
Options specified
Mapping required

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

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

16. 1st key concept: Actor
Represents a set of application roles and responsibilities performed by a system
Always supported by a real-world system
A real-world system may support several IHE Actors
Examples:
Order Placer
Order Filler
Patient Admission, Discharge and Transfer (ADT)
Laboratory Automation Manager
Point Of Care Analyzer
An IHE Actor is an abstract functional unit playing a specific set of roles and supporting a specific set of transactions to share information with other actors.
A real-world system (e.g. a Laboratory Information System) is not an Actor. It may implement one or more Actors (e.g. Order Filler, Information Source).
IHE leaves the definition of products to users and vendors

17. 2nd key concept: Transaction
A set of interactions or messages defined between two Actors for a specific task.
Defines unambiguously how the Actors must cooperate to achieve this task.
Using existing standards such as HL7, DICOM, NCCLS etc.
Example: Transaction LAB-1
« Placer order management »
Order
Placer
Filler
→ Placer order management [LAB-1]
Order
Placer
Order
Filler
New order
Order accepted
Battery replaced
Acknowledgement
A transaction is a set of interactions defined between two actors to fulfill a specific task such as « placer order management ». It defines how the Actors cooperate to achieve this task.
Each interaction is triggered by a real-world event (e.g. a new clinical testing order is placed for a patient by the medical staff). The interaction usually involves two messages (question and answer, event and acknowledgement). The messages are taken from an existing standard and their usage is fully described, to get rid of options and remove ambiguities.
Status change
Acknowledgement
IHE defines transactions at a user-level workflow

18. 3rd key concept: Integration Profile
Solves an Integration Problem:
A collection of real world information exchange capabilities supported by a set of specific Actors using Standards-based Transactions
Integration Profile
Actor …
Transaction
Examples: 
Enterprise User Authentication
Retrieve Information for Display
Laboratory Scheduled Workflow
Echo Laboratory Workflow
Cross-Enterprise Document Sharing
Referenced standard (e.g. HL7)
Detailed messaging info
Roles
The Integration Profile is the global answer to a healthcare communication issue. For instance « Laboratory Scheduled Workflow » how the various systems of the hospital must interact with one another to establish the integrity of laboratory orders and observations throughout the hospital.

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

20. The IHE World…. IHE Transaction IHE Transaction IHE Actor IHE Actor

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

22. 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 precise Service definition does not result in compatibility “on the wire”.
IHE Integration profiles are supportive of Service Oriented Architecture, but do not “require” them. 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.

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

24. IHE Connectathon
Open invitation to vendor and other implementors community
Advanced testing tools (MESA, KUDO, GAZELLE)
Testing organized and supervised by project management team
Thousands of cross-vendor tests performed
Results recorded and published

25. IHE Connectathons Next Connectathon: Wien, Austria, April 20-24, 2008
Massive yearly events :
70-80 vendors
engineers
systems
….integrated in 5 days
Vendors do not pass…
until an IHE Project Manager attest it !
Next Connectathon:
Wien, Austria, April 20-24, 2008

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

28. Example: 2008 HIMSS Interoperability Showcase
Next Demonstration at WoHIT, Copenhagen, Nov 4-6, 2008

29. Feb 2008 HIMSS Interoperability Showcase
Next Demonstration at WoHIT, Copenhagen, Nov 4-6, 2008

30. Featured this year in the HIMSS Showcase…
76 connected applications, 32 IHE profiles
Secured Health Information Exchange with broad content
Clinical Scenarios, focusing on clinician and patient access and information sharing across the continuum of care
Population Health, Quality and Research
Privacy and Security
HITSP Interoperability Specifications
The 2008 Cast:
Vendors Connected 51
Supporters 22
Total 73
Health information exchange with patient care devices
Personal health record solutions
Financial and administrative systems for billing and claims attachments (CAQH/CORE)
Expanded distributed demonstration in an HIE format showing connectivity with vendor booths

31. Across Care Settings Interoperable Health Information Systems
Providers and Vendors
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise and
Across Care Settings
 Health Information Exchange (HIE) or shared EHR

32. 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 types of documents, and content elements).
Care delivery organizations access patient information through:
their own local EMR (if they have one), or
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, which ones to see (may be done in background)
Among those of interest, chose to import in whole or part in its own EMR patient record (responsibility).
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.

33. 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 (where context is best known)
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.

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

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

36. IHE Profiles Specifications
Go to:
For XDS:Under IT Infrastructure
IT Infrastructure Technical Framework 5.0 (XDS.b)
Until 5.0 published: use XDS.b+XDS Stored Query supplements.
For PIX:Under IT Infrastructure
IT Infrastructure Technical Framework 4.0 or 5.0 (PIX, HL7V2)
Or PIXV3 supplement (PIX HL7 V3).
For XDS-MS: Under Patient Care Coordination
PCC Technical framework 3.0

37. 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 other systems’ identifiers for their patients
Optionally, notify domain systems when other systems update identifiers for their patients

38. Patient Identifier Cross-referencing for MPI Value Proposition
Maintain 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

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
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. PIX Integration Profile & MPI The typical view
PIX Server acting as MPI
Patient Identity Cross-reference Manager
Patient Identification Domain A
(Master Domain)
Master (A) Patient Identity Source
Patient Identification
Domain B
Patient Identification
Domain C

47. PIX Integration Profile & MPI The Equivalent IHE Model
Linking PIX Server
Patient Identity Cross-reference Manager
Patient Identification Domain A
(Master Domain)
Master (A) Patient Identity Source
Patient Identification
Domain B
Patient Identification
Domain C

48. 4-Patient data presented to Physician Index of patients records
Introduced at HIMSS in 2005 : IHE-XDS
Clinic Record
Community or
sub-network
Specialist Record
Hospital Record
Sharing System
Repository of Documents
Reference
to records
3-Records
Returned
Repository of Documents
Aggregate Patient Info
4-Patient data presented to Physician
Index of patients records
(Document-level)
Clinical Encounter
Clinical IT System
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.
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.

50. Cross-Enterprise Document Sharing (XDS) Standards Used
Healthcare Content Standards
HL7 CDA header extract
Electronic Business Standards
ebXML Registry, SOAP,
Web Services …
Internet Standards
HTML, HTTP, ISO, IETF …
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.
Implemented world-wide by close to 100 vendors/open source.
Adopted in several national & regional projects: Italy, Austria, Canada, USA, Japan, South Africa, France, 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 (Message feeding a central web server 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

52. 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
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
Document
Sharing XDS
Reliable Pt-Pt Interchange
XDR
Media Interchange
XDM

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

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

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

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. IHE XDS Integration Profile: Key Concepts
XDS Document
XDS Submission Set
XDS Folder

59. Document Repository and Registry Example of Submission Request
Document Registry
Submission Request
Folder A
Submission Set 1
Document Entry
Document
Document Repositories

60. IHE XDS Integration Profile: Key Concepts
XDS Document
A set of attested clinical information (structured or not) which form an element of a patient record to be shared. It may already exist within the source IT system.
XDS Submission Set
A set of documents related to a patient that a (team of) clinician(s) in the same source system have decided to make available at one point in time to potential consumers.
XDS Folder
A means to group documents for a number of other reasons:
Team work across several physicians,
Episode of care,
Emergency information for a patient, etc.
XDS leaves open the use of folders to affinity domain clinicians.

61. How real is XDS ?
Stable specification IHE Technical Framework Published Aug 15th, 2004 (TI Supplement)
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, 2 Dutch regions, etc.
Adopted by several national programs world-wide
4 open source toolkits available, numerous product implementations in EHRs and Infrastructure offerings.

62. IHE, global standards-based profiles adopted by several national & regional projects
Netherland
Amsterdam
Lower
Austria
Italy (Conto Corrente Salute)
UK CfH
(Radiology WF)
France DMP
Denmark (Funen)
Italy (Veneto)
Spain (Aragon)
Austria
Quebec, Toronto, Alberta, British Columbia Canada Infoway
VITL-Vermont
Boston Medical Center - MA
Philadelphia HIE
CPHIC – Pennsylvania
CareSpark – TN & VA
South Africa
Malaysia
CHINA-MoH
Lab results sharing
JAPAN-Nagaya
Imaging Info Sharing
THINC- New York
NCHICA – N. Carolina
CHINA-Shanghai
Imaging Info Sharing

63. IHE-XDS is part of a family of profiles
Regional, national, local or disease centric networks need a consistent set of Integration Profiles
Eight Integration Profiles completed and tested, plus ten 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

64. IHE Integration Profiles for Health Info Nets What is available and has been added in 2007
Security & Privacy
Clinical and PHR Content
Patient ID Mgmt
Emergency Referrals
Format of the Document Content and associated coded vocabulary
PHR Extracts/Updates
ECG Report Document
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
Notification of Document Availability
Notification of a remote provider/ health enterprise
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
Final Txt 2008

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

66. 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
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.
Imaging Center
Physician Practice
Same XDS Infrastructure (Registry and Repositories) for medical summaries and imaging information !

67. XDS Scenario + use of ATNA & CT
Physician Office
EHR System
Teaching Hospital
PACS
ED Application
EHR System
PMS
XDS Document Repository
Community Clinic
Lab Info. System
PACS
XDS Document Registry
Query Document
Register Document
Secured Messaging
Lets lift the cover and get a peek into some of the details that enable secured sharing of health records.
Animated, but automatic, only two clicks:
First Click: start placing the three infrastructure components: registry, audit trail repository and cosnsitent time server, then publishes a document and registers it with appropriate security
Second Click: serach documents, retrieve them and impoirt them into the community clinic EMR.
Retrieve Document
Provide & Register Docs
Maintain Time
ATNA Audit record repository
CT Time server
Maintain
Time
Record Audit
Event
Maintain
Time
Record Audit
Event
Record Audit
Event

68. XDS Scenario + use of PIX & PDQ
PDQ Query to Acquire Affinity Domain Patient ID
Patient Identity Feed M
Patient Identity XRef Mgr
14355 M
L-716
A87631
Physician Office
EHR System
Patient Identity Feed M
A87631
L-716
Teaching Hospital
PACS
ED Application
EHR System
Affinity Domain Patient
Identity Source M
Patient Identity Feed
Patient Identity Feed
Community Clinic
Lab Info. System
PACS
XDS Document Repository
XDS
Document Repository
PIX
Query
A87631
L-716
Document Registry
PIX
Query
Sharing documents in an environment of fragmented patient identification is addressed by integrating the linking of patients ids.
Automatic animation: three clicks only
First Click: patient consent to having his information shared in the Community. Registered demographics fed to the Id X-referencing (MPI)
Second Click: to publish a document, the PIX/MPI is queried, than the XDS transactions performed with the repository and registry.
Third Click: to query for records of a patient, the PIX/MPI is queried, then the registry is queried and finally the document retrieved from the distributed (in this example) repositories.
Query Document (using Pt Id)
Register (using Pt ID)
Provide & Register Docs
PACS
Retrieve Document
ATNA Audit record repository
CT Time server

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

70. 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
Being established
Img Acq
Treatment
Devices
Devices
Devices
Radiation Therapy
Pharmacy
Intensive Care Unit

71. IHE Solutions within the Enterprise Example: Cardiology
EMR - HIS
Enterprise IT Infrastructure
eMPI
User Auth
RIS
CIS
LIS
-Radiation Therapy
-Patient Care Devices
-Pathology
-Eye Care
Img Acq
PACS
Cath
ECG
Auto Mgr
Analyzer
Radiology
Cardiology
Laboratory
Cardiology Integration Profiles
Cardiac Catheterization Lab Workflow
Echocardiography Lab Workflow
Retrieve ECG for Display
Displayable Reports
Cath and Echo Evidence Documents

72. IHE Solutions within the Enterprise IT Infrastructure (Enterprise)
EMR - HIS
Enterprise IT Infrastructure
eMPI
User Auth
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
RIS
CIS
LIS
-Radiation Therapy
-Patient Care Devices
-Pathology
-Eye Care
Img Acq
PACS
Cath
ECG
Auto Mgr
Analyzer
Radiology
Cardiology
Laboratory

73. IHE Solutions within the Enterprise Radiology
EMR - HIS
Enterprise IT Infrastructure
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
eMPI
User Auth
RIS
CIS
LIS
-Radiation Therapy
-Patient Care Devices
-Pathology
-Eye Care
Img Acq
PACS
Cath
ECG
Auto Mgr
Analyzer
Radiology
Cardiology
Laboratory
How to use IHE ?
IHE Radiology
Handbook

74. IHE Solutions within the Enterprise Example: Laboratory
EMR - HIS
Enterprise IT Infrastructure
eMPI
User Auth
RIS
CIS
LIS
-Radiation Therapy
-Patient Care Devices
-Pathology
-Eye Care
Laboratory Integration Profiles
Laboratory Testing Workflow
Laboratory Information Reconciliation
Laboratory Point Of Care Testing
Laboratory Device Automation
Laboratory Code Set Distribution
Laboratory BarCode
Img Acq
PACS
Cath
ECG
Auto Mgr
Analyzer
Radiology
Cardiology
Laboratory

75. General scope of LAB TF
Ordering, placing, scheduling and performing clinical laboratory tests on in vitro specimen, within acute care settings
Tests in lab as well as at the point of care. Chemistry and Microbiology included with thorough examples
Sharing laboratory reports within a wide community of care providers
Anatomic pathology addressed by a separate domain in IHE

76. Organization of LAB Technical Framework rel 2.1
Volume 1: Use Cases, Profiles, actors, dependencies
Volume 2: Description of message-based transactions
Volume 3: Document-based transaction (lab report)
Volume 4: Common subset of LOINC test codes
Openly available at:

77. Lab TF Rel 2: Integration Profiles
HL7
V2.5
Laboratory Testing Workflow (LTW)
Laboratory Device Automation (LDA)
Laboratory Point Of Care Testing (LPOCT)
Laboratory Code Sets Distribution (LCSD)
Laboratory Barcode Labeling (LBL)
Workflow
Subset of LOINC test codes
The lab TF includes in its volume 4 a common subset of LOINC test codes, usable in all transactions of the framework.
The point of care testing profile is based on the standard POCT1-A, which implies HL7 v2.5 (see further slides)
V3:
CDA
Sharing Laboratory Reports (XD-LAB)
Content

78. Dependencies toward IHE IT Infrastructure

79. Lab TF Rel 2: Integration Profiles
HL7
V2.5
Laboratory Testing Workflow (LTW)
Laboratory Device Automation (LDA)
Laboratory Point Of Care Testing (LPOCT)
Laboratory Code Sets Distribution (LCSD)
Laboratory Barcode Labeling (LBL)
Workflow
Subset of LOINC test codes
The lab TF includes in its volume 4 a common subset of LOINC test codes, usable in all transactions of the framework.
The point of care testing profile is based on the standard POCT1-A, which implies HL7 v2.5 (see further slides)
V3:
CDA
Sharing Laboratory Reports (XD-LAB)
Content

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

81. IHE Profiles Specifications
Go to:
For LTW:Under Laboratory
Laboratory Technical Framework 2.1 (LTW, LDA)

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

83. Coffee Break

84. Agenda
08:30-10:30 THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability - Charles Parisot
Coffee Break
11:00-12:30 USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE – Charles Parisot
Lunch Break
13:30-15:00 HOW TO USE IHE RESOURCES: hands on experience – Eric Poiseau

85. Understanding the IHE Initiative
IHE has a clear focus
IHE is a healthcare domain-based initiative
IHE creates synergies for interoperability testing across domains
IHE addresses the standards adoption process
IHE is both regional and multi-national
IHE is both user lead and vendor driven

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

87. IHE International Board
IHE Organizational Structure
IHE International Board
Regional Deployment
Global Development
Radiology
Cardiology IT
Infrastructure
Patient Care
Coordination
Devices
Laboratory
Pathology
Eye Care
Radiation
Oncology
Public Health, Quality
and Research
IHE Europe
IHE North America
France
USA
Canada
IHE Asia-Oceania
Japan
Korea
Taiwan
Netherlands
Spain
Sweden UK
Italy
Germany
Norway
China
Austria
ACC
ACCE
ACEP
JAHIS JIRA JRS
METI-MLHW
MEDIS-DC JAMI
RSNA SFR SFIL
SIRM
BIR
EuroRec
COCIR
EAR-ECR
DRG
ESC
Professional Societies / Sponsors
ACP
GMSIHIMSS
Contributing &
Participating Vendors 87 87

88. IHE Sponsors Professional societies (stakeholder representation)
Healthcare Information Management Systems Society (HIMSS)
Radiological Society of North America (RSNA)
British Institute of Radiology (BIR), British Computer Society (BCS
German Radiology Society (DRG)
GMSIH (IT France), SFIL (laboratory), French National Project (DMP)
European Society of Cardiology
……Many other European Societies
American College of Physicians (ACP), American College of Emergency Physicians (ACEP)
…Many other American healthcare societies (ACCE), (AAO), (ASTRO), etc.
JAHIS (IT Japan), and many other Japanese Societies
And many more…. 88 88

89. IHE Participants and Relationships
Participants include:
Users - Clinicians, Staff, Administrators, CIOs, Governments
Vendors of Information Systems and Equipment
Consultants
Relationship with Standards Development Organizations (SDOs):
HL7, DICOM, ISO, CDISC, ASTM, W3C, IEEE, IETF, and many others
Approved via ISO/TC 215 allowing for IHE profiles to be published as ISO deliverables
National Adoption of Healthcare IT Standards and IHE Profiles
DMP(France), ELGA(Austria), HITSP (USA), Infoway (Canada), many others worldwide…..

90. IHE International Board
IHE Organizational Structure
IHE International Board
Regional Deployment
Global Development
Radiology
Cardiology IT
Infrastructure
Patient Care
Coordination
Devices
Laboratory
Pathology
Eye Care
Radiation
Oncology
Public Health, Quality
and Research
IHE Europe
IHE North America
France
USA
Canada
IHE Asia-Oceania
Japan
Korea
Taiwan
Netherlands
Spain
Sweden UK
Italy
Germany
Norway
China
Austria
ACC
ACCE
ACEP
JAHIS JIRA JRS
METI-MLHW
MEDIS-DC JAMI
RSNA SFR SFIL
SIRM
BIR
EuroRec
COCIR
EAR-ECR
DRG
ESC
Professional Societies / Sponsors
ACP
GMSIHIMSS
Contributing &
Participating Vendors 90 90

91. IHE International Governance - Membership
Membership:
Members are Organizations–Sign Governance & IP once.
Three Organizational Categories: User, Developer, General Interest
Member designates a primary/alternate representatives to one of more Committees (Domains, Test& Tools, MarCom).
Voting rights lost after three missed meetings, regained at second meeting
Elect Committee (or sub-Committee) co-chairs. One User & one vendor recommended for Planning Committees
Regional and National IHE Committee members required to become members of IHE International.

92. IHE International Governance – Others Committees
IHE Regional or National Deployment Committees are independent entities with their own governance but close collaborative relationship with IHE International.
IHE International Board empowers “Regional and National Committee”. 3 year commitment, renewable.
Oversees Testing and Tools Committee
Coordinates the various Regional and National Committees.
Oversees Marketing & Communication Committee
Consistency of communication among Domains within IHE International and various Regional and National Committees.

93. How can I participate? As a Provider or Vendor Contributor
Offer Clinical Use Case Input to Drive IHE Profile Development
Become a member of relevant domain’s Planning or Technical Committees
Become a member of relevant Regional/National Committees
Help to shape IHE’s future direction
As a Vendor Participant
Respond to Public Comments of Domain Supplements
Attend the June Educational Workshop
Participate in Connect-a-thons and Demonstrations
As a Provider/Consultant Participant
Attend Demonstrations and include IHE Integration Profiles in your RFPs and Integration Projects.

94. What can you do? Learn about IHE, www.ihe.net
Insist on relevant IHE profiles compliance in your RFPs and contract documents:
Select Integration Profiles, and Appropriate Actor(s)
Ask vendors for their products “IHE Integration Statements”.
Need more interoperability ?
Contribute to IHE Committees

95. IHE Web site: www.IHE .net
Frequently Asked Questions
Integration Profiles in Technical Frameworks: See Volume 1 of each TF for Use cases
Cardiology
Eye Care
IT Infrastructure
Laboratory
Patient Care Coordination
Patient Care Devices
Pathology
Quality
Radiation Oncology
Radiology
Connectathon Result:
Vendor Products Integration Statements

96. How to Participate As a User or Vendor Committee Member
Become a member of relevant Domains Planning or Technical Committees
As a User, Consultant or Vendor Interested Observer
Provide Public Comments on Technical Framework Supplements
Attend Demonstrations, Educational Events and Workshops

97. More Resources - www.ihe.net
Frequently Asked Questions
Integration Profiles in Technical Frameworks:
Cardiology
IT Infrastructure
Laboratory
Patient Care Coordination
Patient Care Devices
Radiation Oncology
Radiology
Connectathon Results
Vendor Products Integration Statements
Participation in Committees and Connectathons