Process and IT Infrastructure Standards Drive Healthcare Solutions San Diego, Jan 2004 Charles...

Process and IT InfrastructureProcess and IT InfrastructureStandards Drive Healthcare SolutionsStandards Drive Healthcare Solutions

San Diego, Jan 2004 San Diego, Jan 2004Charles Parisot

IHE Planning Committees: IT, Radiology, Laboratory, CardiologyGE Medical Systems – Information Technology

OutlineOutline

1.1. IHE Process OverviewIHE Process Overview2.2. IHE for IHE for IT InfrastructureIT Infrastructure3.3. IHE for IHE for LaboratoryLaboratory4.4. IHE for IHE for RadiologyRadiology

IHE IHE Cardiology Cardiology established established first output expected for end of 2004first output expected for end of 2004

IHE Process OverviewIHE Process Overview

IHE introduces a novel processto accelerate the adoption and to facilitate use

of standards in healthcare

4HL7 San Diego – January 2004

IHE MissionIHE Mission

Bring together stakeholders to implement

standards for communicating clinical

and operational data safely and

efficiently throughout the healthcare

enterprise


IHE VisionIHE Vision

To provide relevant patient information at

the point of care to support caregiver

decision-making and optimal patient care


What is IHE?What is IHE?

A joint initiative to improve systems integration– Process for coordinated adoption of standards– Clinicians/IT staff define needs– Vendors develop solutions—Technical

Framework– Professional societies supervise documentation,

testing and demonstration/promotion


Goals of IHEGoals of IHE

Speed up the rate and quality of integration in healthcare environments

Foster communication among vendors Prove that integration is attainable

based on standardsImprove the efficiency and effectiveness

of clinical practice


What IHE is NOT!What IHE is NOT!

A standards development organization– Uses established standards (HL7, DICOM, RFCs,

others) to address specific clinical needs– Activity complementary to SDOs, formal

relationship with HL7 and DICOM.

Simply a demonstration project– Demos only one means to the end—adoption– Backed up by documentation, tools, testing, and

publication of information


IHE ParticipantsIHE Participants Societies Representing Healthcare Segments

– ( Radiology, Lab, IT Professional Societies… )

Users– ( Clinicians, Medical Staff, Administrators, CIOs, … )

Information Systems Vendors Clinical Systems and Device Vendors Standards Development Organizations (SDOs)

– HL7– DICOM– Others …


Benefits to IHE ParticipantsBenefits to IHE Participants

Clinicians– Improved workflow– Information when and where needed– Fewer opportunities for errors– Fewer tedious tasks/repeated work

Administrators– Improved efficiency– Best of breed opportunities– Decreased cost and complexity of interface

deployment and management


Benefits to IHE ParticipantsBenefits to IHE Participants Vendors

– Decreased cost and complexity of interface installation and management

– Validation of integration at Connectathon– 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


A Proven Standards Adoption ProcessA Proven Standards Adoption Process

IHEIntegrationProfiles B

IHEIntegrationProfile A

Easy toIntegrateProducts

IHEConnectathon

ProductWith IHE

IHEDemonstration

User Site

RFPRFP

Standards

IHETechnical

Framework

Product IHE IntegrationStatement

IHE ConnectathonResults

IHE Integration Profiles at the heart of IHE :– Detailed selection of standards and options each solving a specific integration

problem– A growing set of effective provider/vendor agreed solutions– Vendors can implement with ROI– Providers can deploy with stability


Result Matrix of the Radiology ConnectathonResult Matrix of the Radiology Connectathon


The Annual “Connectathon”The Annual “Connectathon” Unprecedented Cross-Vendor Testing Voluntary Participation Neither a Demo nor a Certification Well Designed End-to-End Scenarios Advanced Testing Tools Unprecedented Pool of Technical Talent Connectathon for IT InfrastructureConnectathon for IT Infrastructure

San Diego January 26-30, 2004San Diego January 26-30, 2004 Connectathon for IT Infrastructure, Laboratory & Radiology - Connectathon for IT Infrastructure, Laboratory & Radiology -

Padova (Italy) March 29-April 2, 2004Padova (Italy) March 29-April 2, 2004 Connectathon for Radiology and IT InfrastructureConnectathon for Radiology and IT Infrastructure

Tokyo – March 2004Tokyo – March 2004 Connectathon for Radiology - Chicago October 2004Connectathon for Radiology - Chicago October 2004


IHE ResourcesIHE Resources

Proven process with strong participationFive years of documentation, testing, demos

Technical FrameworkMESA Tools and Connectathon

2003: 36 vendors in USA2003: 43 vendors in Europe

Strong recognition and credibility of conceptPromotional opportunities at major professional venues

world-wide: HIMSS, RSNA, JRC, Hopital Expo, DRG, UKRC, SIRM, JFR, Medica


IHEIHE Domains Domains andand RegionsRegions

IHE North America

United States of AmericaHIMSS, RSNA, ACCE, ACC

IT Infrastructure

Radiology Laboratory Cardiology

IHE EuropeEAR, ECR, COCIR

IHE Asia

National ExtensionsNational Extensions

CanadaInfoway, CAR,

FranceGMSIH, SFR, SFL,

GermanyDRG, ZVEI

ItalySIRM,

United KingdomBIR, RCR, NHS, Norway, Sweden,

Dennemark

JapanJIRA, JAHIS, METI, JRS,

JSRT, JAMI Korea

Taiwan


National Extensions


National Extensions

Glo

bal

Develo

pm

ent

Lo

cal D

eplo

ymen

t

IHE Technical FrameworkIHE Technical Framework

IHE Connectathons, Education, DemonstrationsIHE Connectathons, Education, Demonstrations


Key IHE ConceptsKey IHE Concepts• Generalized Systems Generalized Systems -> -> ActorsActors

• Interactions between Actors Interactions between Actors -> -> TransactionsTransactions

• Problem/Solution ScenariosProblem/Solution Scenarios -> -> IntegrationIntegration ProfilesProfiles

• For each Integration Profile:For each Integration Profile:

• the context is described (which real-world problem)the context is described (which real-world problem)

• the actors are defined (what systems are involved)the actors are defined (what systems are involved)

• the transactions are defined (what must they do)the transactions are defined (what must they do)


ActorsActors

Represent a set of roles and responsibilities performed by a system

A real-world system may support several IHE Actors

Examples:– Order Placer– Order Filler– Patient Identifier Cross-Referencing Mgr– Laboratory Automation– Report Creator


TransactionsTransactionsUnambiguously defines how actors

communicateUsing existing standards such as HL7

or DICOM to accomplish a specific task.Examples:

– Procedure Scheduled– ADT Update– Retrieve Document for Display


Integration ProfilesIntegration ProfilesIHE Integration Profiles define a collection of

real world functionality and group together the necessary Actors and Transactions to make it work.

Examples: – Enterprise User Authentication– Retrieve Information for Display– Laboratory Scheduled Workflow– Patient Information Reconciliation


IHE:IHE: A stepwise approach A stepwise approach

CardiologyCardiologyLabora-Labora-ttoryory

Pharmacy,…..Pharmacy,…..RadiologRadiologyy

Patient Identifier Linkage, Registries, Security

Electronic Health Record

Enterprise Scheduling

Patient Management

Order Management


IHE Integration StatementIHE Integration Statement

HL7 & IHEHL7 & IHEJoint DemonstrationJoint Demonstration

at HIMSS 2004at HIMSS 2004


New at HIMSS in 2004New at HIMSS in 2004 In 2002 and 2003, IHE and HL7 have held separate

demonstration– HL7 demos were « throw away »– IHE demos were « radiology centric »

IHE is now in Healthcare IT - 5 new profiles to be showcased at HIMSS 2004

HL7 and IHE have decided this year to combine their demos and convey a 2 tier message:– HL7 broad in scope but leaves choices for interoperability– IHE Profiles are narrow in scope but high interoperability


HL7-IHE Interoperability demoHL7-IHE Interoperability demo

Demo scenario integrates 3 components: - IHE IT Integration Profiles, and selected

domain specific Profiles (e.g. Radiology). - HL7 standard functions - HL7 draft standard functions Demo highlights how each component feeds

into other and contributes to successful driving of standards in healthcare solutions.


HL7-IHE Interoperability demoHL7-IHE Interoperability demo

Live technology & product interoperability demonstration

At the center of the commercial exhibit floor at HIMSS, February 2004

Promoted by HIMSS-signage show-wide.


The Product World…..The Product World…..

Product XYZfrom Vendor T


The IHE The IHE WWorld….orld….

IHE Actor

ActorActor

Actor

IHEIHETransactionTransactionIHEIHE

TransactionTransaction

IHEIHETransactionTransaction

IHE Actor


Mapping IHE to ProductsMapping IHE to Products

Poduct XYZfrom Vendor T

IHE Actor

ActorActor

Actor

IHEIHETransactionTransactionIHEIHE

TransactionTransaction

IHEIHETransactionTransaction

IHE Actor


The IHE Technical ApproachThe IHE Technical Approach

Identify the transactions required to integrate a specific information flow between several information systems/devices

For each transaction, select a single standard (e.g.HL7 messages, RFC) for use in implementing the transaction

Specify in detail the use of the standard in implementing the transaction


IHE IHE : : An Integration ProfileAn Integration ProfileA Solution to an Integration ProblemA Solution to an Integration Problem

24: Report Submission

Structured Report Export: 28

25: Report Issuing

Report Creator

26: Query Reports27: Retrieve Reports

Report Repository

Report Reader

External Report Repository Access

Report Manager

Enterprise Report Repository

Actors cooperating

through TransactionsTransactions to perform a specific task

Overview of IHE IT Infrastructure Overview of IHE IT Infrastructure Integration ProfilesIntegration Profiles


IHE IT InfrastructureIHE IT Infrastructure5 Integration Profiles5 Integration Profiles

Enterprise User Authentication

Provide users a single nameand

centralized authentication process

across all systems




across all systems

Retrieve Information for Display

Access a patient’s clinical information and documents in a

format ready to be presentedto the requesting user




Patient Identifier Cross-referencing

for MPI

Map patient identifiers across independent

identification domains


for MPI



Synchronize multiple applications on a desktop to the same patient

Patient Synchronized Applications



Consistent Time

Coordinate time across networked

systems

Consistent Time


systems






across all systems




across all systems


for MPI




for MPI







Consistent Time


systems

Consistent Time


systems


Access a patient’s clinical information and documents

in a format ready to be presented

to the requesting user






Abstract / Scope

Simple and rapid access to patient information

Access to existing persistent documents in well-known presentation formats: CDA, PDF, JPEG.

Access to specific key patient-centric information for presentation to a clinician : allergies, current medications, summary of reports, etc..

Links with other IHE profiles - Enterprise User Authentication & Patient Identifier Cross-referencing.

Retrieve Information for DisplayRetrieve Information for Display


Value Proposition: User Convenience:

– Healthcare providers can "see" the information. A significant integration step.

– Workflows from within the users’ on-screen workspace or application.

– Complements multiple simultaneous apps workflow of Patient Synchronized Apps

Broad Enterprise-Wide access to information:– Web technology for simple clients– Clinical data handling fully assumed by the information

source that holds clinical data.



Key Technical Properties: Standards Used:

– Web Services (WSDL for HTTP Get).– General purpose IT Presentation Formats: XHTML, PDF,

JPEG plus CDA L1.– Client may be off-the-shelf browser or display application.

Two services :– Retrieve of Specific Information:

Patient centric: patient ID Type of Request (see next slide) Date, Time, nMostRecent

– Retrieve a Document Object Unique Instance Identifier (OID) Type of Request Content Type Expected



Transaction Diagram


Display InformationSource

Retrieve Specific Info for Display [11]

Summary of All ReportsSummary of Laboratory ReportsSummary of Radiology ReportsSummary of Cardiology ReportsSummary of Surgery ReportsSummary of Intensive Care ReportsSummary of Emergency ReportsSummary of Discharge ReportsList of AllergiesList of Medications

Retrieve Document for Display [12]

Persistent Document

Types ofRequests






across all systems




across all systems








for MPI




for MPI



Consistent Time


systems

Consistent Time


systems

Synchronize multiple applications on a desktop to

the same patient


Synchronize multiple applications on a desktop to

the same patient



Abstract / Scope

Patient synchronization of multiple disparate applications

Single patient selection

When combined with PIX Profile, allows patient synchronization across patient identity domains

Patient Synchronized ApplicationsPatient Synchronized Applications


Value Proposition:User Convenience:

– Eliminates the repetitive task of selecting the patient in each application

– Permits the user to select the patient in the application for which they are most familiar and / or appropriate to the clinical workflow

Patient Safety:– Ensures all data being viewed across applications is

for the same patient



Key Technical Properties:Standards Used:

– HL7 Context Management “CCOW” Standard, Version 1.4

– Support for both Windows and Web Technology– Support of “Patient Subject”

IHE Constraints:– Specifies use of Patient.Id.IdList item

Ensures maximum interoperability with PIX Profile Protects against future deprecation of patient identifier

items (HL7 2.3.1, 2.4, 2.5, CCOW).



Transaction Diagram







across all systems




across all systems






format ready to be presentedto the requesting user Synchronize multiple applications

on a desktop to the same patient




Consistent Time


systems

Consistent Time


systems


for MPI




for MPI




Patient Identifier Cross-referencingPatient Identifier Cross-referencingAbstract / ScopeAbstract / Scope

Allow all enterprise participants to register the identifiers they use for patients in their domain

Support domain systems’ queries for other systems’ identifiers for their patients

Optionally, notify domain systems when other systems update identifiers for their patients


Patient Identifier Cross-referencingPatient Identifier Cross-referencingValue PropositionValue 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


Patient Identifier Cross-referencingPatient Identifier Cross-referencingID Domains & TransactionsID Domains & Transactions

Patient Identification Domain C

Other IHE Actor

Identity Patient

Cross References

Patient Identity Consumer

Patient Identification Domain B

Patient Identity

Feed Patient Identity

Source

Patient Identity Cross-reference

Manager

Patient Identification Cross-reference Domain

Patient Identity Feed & Patient Identity References

Internal Domain transactions

Other IHE Actor

Patient Identity Cross References


Patient Identification Domain A

Patient Identity

Feed Patient Identity

Source

Internal Domain transactions


Patient Identifier Cross-referencingPatient Identifier Cross-referencingKey Technical PropertiesKey Technical Properties

Standards Used– HL7 Version 2.3.1 and Version 2.4

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)

Key Properties– ADTs remain in charge of their domains– No need for a master ID or MRN, but supported as another ID domain












for MPI




for MPI



Consistent Time


systems

Consistent Time


systems






Provide users a single name

andcentralized

authentication process

across all systems


Provide users a single name

andcentralized

authentication process

across all systems


Enterprise User AuthenticationEnterprise User AuthenticationAbstract / ScopeAbstract / Scope

Support a single enterprise governed by a single set of security policies and having a common network domain.

Establish one name per user that can then be used on all of the devices and software in a healthcare enterprise.

Facilitate centralized user authentication management.

Provide users with single sign-on.


Enterprise User AuthenticationEnterprise User AuthenticationValue PropositionValue Proposition

Start at the beginning– Recognize user authentication as a necessary step for

most application and data access operations.– Enable benefits from future integration profiles, such as

authorization management. Achieve cost savings/containment.

– Centralize user authentication management.– Simplify multi-vendor implementations

Provide workflow improvement for users.– Increase user acceptance.– Decrease unproductive user task-switching time.

Increase level of assurance in security protection.


Enterprise User AuthenticationEnterprise User AuthenticationKey Technical PropertiesKey Technical Properties

Standards Used– Kerberos v5 (RFC 1510)

Stable since 1993, Widely implemented on current operating system

platforms Successfully withstood attacks in its 10-year history Fully interoperable among all platforms

– HL7 CCOW user subjectMinimal Application Changes

– Eliminate application-specific, non-interoperable authentication.

– Replace less secure proprietary security techniques.


Enterprise User AuthenticationEnterprise User AuthenticationTransaction DiagramTransaction Diagram






across all systems




across all systems








for MPI




for MPI







Consistent Time

Coordinate time across networked systems

Consistent Time

Coordinate time across networked systems


Consistent TimeConsistent TimeScope and Value PropositionScope and Value Proposition

Ensures that the system clocks and time stamps of the many computers in a network are well synchronized

A median error under 1 second is sufficient for most purposes.

Consistent Time profile specifies the use of the Network Time Protocol (NTP) defined in RFC 1305.






across all systems




across all systems








for MPI




for MPI







Consistent Time


systems

Consistent Time


systems

Synergy between IHE IT Int. ProfilesSynergy between IHE IT Int. ProfilesRID with EUA/CT & PIXRID with EUA/CT & PIX

Display

Client AuthenticationAgent

Time Client

Information Source

KerberosAuthentication

Server

TimeServer


Patient Identity X-ref

Manager

Example of support ofmultiple actors/profiles

59

Synergy between IHE IT Int. ProfilesSynergy between IHE IT Int. ProfilesApps with PSA, EUA & PIXApps with PSA, EUA & PIX

Application A

Client AuthenticationAgent

Time Client KerberosAuthentication

Server

TimeServer


Patient Identity X-ref

Manager

Context Manager

Application BContext participant

Context participant

Example of support ofmultiple actors/profiles

60

How to proceed with IHE ITHow to proceed with IHE IT Infra Infra1. Read IHE Fact Sheet & this presentation

• www.himss.org/ihe

2. Read ITI Technical Framework Vol 1 Integration Profiles


3. Read ITI Technical Framework Vol 2 Transactions


4. Enter comments on http://forums.rsna.org

5. IHE IT Infrastructure Tech. Committee has issued the trial for implementation technical framework in August for HIMSS HL7-IHE Demo.

6. Final IT Infrastructure Technical Framework to be issued in February 2004. 61


Integration profiles, the easy way Integration profiles, the easy way to deal with transactionsto deal with transactions

easy-to-understand, coherent functional sets and

a convenient way for users and vendors to communicate

about integration requirements and needed functionality in daily life.

Overview of the IHE Overview of the IHE Laboratory Integration ProfileLaboratory Integration Profile



Access a patient’s clinical information and documents in a format ready to be presented


Laboratory Scheduled Workflow

Admit, Discharge, Transfer a patient, order lab tests, collect specimen, perform tests, report

results.





Admit, Discharge, Transfer a patient, order lab tests, collect specimen, perform tests,

report results.

IHE Laboratory Integration Profiles IHE Laboratory Integration Profiles

1 now, 4 planned1 now, 4 planned



across all systems

Point of Care Testing(Future)

Extend laboratory testing with bedside testing devices



Cooperation with external laboratory

Outside Healthcare Enterprise Testing (Future)



across all systems

Laboratory Patient Information

Reconciliation (Future)

Updates resulting from unidentified or misidentified

Patient



across all systems

Lab Analyzer Management (Future)

Extend laboratory testing with intra-lab testing devices


IHE-Lab Technical FrameworkIHE-Lab Technical FrameworkRetrieve Information

for Display




Admit, Discharge, Transfer a patient, order lab tests, collect specimen, perform tests, report

results.

Lab-TF Trial Implementation has been issued on November 15, 2003


Laboratory Scheduled WorkflowLaboratory Scheduled WorkflowAbstract / ScopeAbstract / Scope

Spans ordering, conformity of specimens, lab automation, results delivery.

Handles all major types of workflows:– Externally placed order with identified specimens– Externally placed order with specimens unidentified or

to be collected by the laboratory– Internally placed order with specimens identified by

third party or collected by the laboratory

Shares ADT transactions with Radiology


Laboratory Scheduled Workflow Laboratory Scheduled Workflow Value PropositionValue Proposition

A comprehensive workflow approach– Spans all countries– Address specimen linkage– most lab specialties: Blood gases, Chemistry,

Hematology, Immunology, Laboratory, Microbiology, Mycobacteriology, Mycology, Serology, Toxicology, Virology.

Provides workflow improvement– Increases continuity and integrity of clinical

data – Decreases user need for manual tasks.


Laboratory Scheduled WorkflowLaboratory Scheduled WorkflowKey Technical PropertiesKey Technical Properties

Standard Used : HL7 V2.5– Released 2003 – Includes significant extensions developed by HL7 UK

and Germany for specimen tracking– Leverages broad acceptance world-wide of HL7 V2– Offers the option to support HL7V2-XML

IHE Integration Profile value-add:– A robust data model supporting all necessary workflow

concepts.– Offers a significant improvement over V2.3 for a

reasonable incremental effort.


Laboratory Scheduled workflowLaboratory Scheduled workflow

Already definedIn Radiology TF

ADT

Order Filler (LIS) Order Placer

1: Pt Registration12: Pt Update

Pt registration: 1Pt Update: 12

T1. OP Order Mgmt

LAS

T4. Work Order Mgmt

Result Tracker

T1. OP Order Mgmt

T2. OF Reflex Order Mgmt

T5. Test Results Mgmt

T3. OF Results Mgmt

Laboratory

T2. OF Reflex Order Mgmt

IHEIHE

Looking to the future . . .


IHE plans for 2004IHE plans for 20046 Candidate Integration Profiles6 Candidate Integration Profiles

1. EHR-Longitudinal Record Management

2. Patient Demographics Query

3. Enterprise Audit Trail Mgt 4. Cross-Node Security (Authentication, Encryption)

5. Healthcare Staff White Page Directory

6. Basic Configuration Mgt

Selection by January 2004Selection by January 2004Public Comment Supplements by June 2004Public Comment Supplements by June 2004


IHE Integration Profiles Focused on the EHRIHE Integration Profiles Focused on the EHRUnder development in 2004

• An IHE Integration Profile organizes a set of coordinated, standards-based transactions between a subset of the functional components of healthcare enterprises in order to address a specific clinical or infrastructure need.

• IHE develops such solutions for IT systems integration in a stepwise and pragmatic manner, focusing on the most common integration challenges.

• IHE has developed close to 20 Integration Profiles focuses on IT Infrastructure (MPI, Security, etc.), Radiology, Laboratory and is now expanding to Cardiology. This is an intra-enterprise, bottom-up approach.

• In this proposal, IHE explains how it intends to approach the longitudinal dimension of the EHR with a distributed, cross-enterprise, document centric, top-down point of view.

Feedback on this approach and expanding collaborations are sought.


Acute Care (Inpatient)

GPs and Clinics (Outpatient)

Nursing Homes

Other Specialized Careor Diagnostics Services

Continuity of Care: Patient Longitudinal Record Across Encounters

A typical patient goes through a sequence of encounters in different Care Setting (incl. Diagnostics Services).


Acute Care (Inpatient)

GPs and Clinics (Outpatient)

Nursing Homes

Other Specialized Careor Diagnostics Services

Integration : Feeding & Accessing the Longitudinal Health Record Information

EHR-LR

The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems


Care Delivery Process

Selection of informations

Decide toAssess demand For care

Actions to order

Define an action plan

Identification End ofEncounter

Define healthcareObjective

EHR-CREHR-CR : EHR information supporting immediate care deliveryEHR-LREHR-LR : EHR information supporting long term care delivery

Two types of Integration : Health Record as used during care delivery Health Record as used across-encounters

EHR-CR

Read

EHR-LR EHR-LR

Read

EHR-LR

CreateUpdate


EHR-LR Documents Repository

Custodian for an unspecified time of Documents recorded from patient encounters.

EHR-LR Virtual Documents Repository

Custodian for an unspecified time of Documents recorded from local patient encounters.

EHR-LR Directory

EHR-LR Actors: Directory & Repository Actors

EHR-LR Documents Repository

Custodian for an unspecified time of Documents recorded from patient encounters.EH

R-

CR EH

R-

CR


IHE Integration Profiles Focused on the EHRIHE Integration Profiles Focused on the EHR • IHE proposes an approach to obtaining a longitudinal view of the EHR, IHE proposes an approach to obtaining a longitudinal view of the EHR,

with a distributed, cross-enterprise, document centric solution.with a distributed, cross-enterprise, document centric solution.

• The strategy is to progressively bridge the gap between the EHR-LR Integration Profiles and the domain integration profiles as new integration profiles are developed.

Feedback on this approach and expanding collaborations are sought.

Is this a useful “brick” ?

• The proposed strategy is a scoping exercise to address one of the many integration problems in the realization of the EHR vision. IHE does not claim to master and address the definition and all aspects of a complete and interoperable EHR System.

• In collaboration with well established standards bodies and other EHR related initiatives world-wide (EHRCOM, CCR, HL7, etc.), IHE expects to contribute at a more cost-effective and rapid deployment.


Where is More Information Where is More Information Available?Available?

www.himss.org/IHEIHE IT Technical framework – V1.0IHE RAD Technical framework – V5.5 IHE LAB Technical framework – V1.0

Non-Technical Brochures :IHE Primer and IHE FAQIHE Integration Profiles: Guidelines for BuyersIHE Connectathon ResultsIHE Integration Statements from Vendors

IHEIHE

Thank You

Date post:	25-Dec-2015
Category:	Documents
Upload:	lucy-allison
View:	214 times
Download:	0 times