Standards-based Solution for National Level Document Sharing.

1

IBM Research

Health Information Exchange
Standards-based Solution
for
Regional and National Level
Patient Centric Network
Boaz Carmeli – IBM Haifa Research Lab, Israel
boazc@il.ibm.com
February 21 2008

© 2002 IBM Corporation

IBM Research Worldwide
3000 researches in 8 research laboratories around the world
dealing with extensive verity of research topics

Estab. 1995
Estab. 1961 Estab. 1956
Estab. 1986 Employees: 110
Employees: 1750 Employees: 210
Employees: 440

Estab. 1982
Employees: 180
Estab. 1995
Estab. 1972 Estab. 1998
Employees: 40
Employees: 350 Employees: 80
2 National Health Record – Standard Solution © 2006 IBM Corporation
Updated 2/2/04

Haifa IT for Healthcare and Life Science Group
13+ years of IT research in Healthcare & Life Science
– Extensive Information Technology and Computer Science skills
– Medical domain skills – Imaging, Clinical Genomics, Interoperability
– Standards Practice – courses, consultation & services (DICOM, IHE,
HL7…)
– Mainly in Europe
– Extensive SW development and architecting skills – SOA and J2EE
– Deep knowledge in information integration and interoperability

Involvement in significant customer contracts and interactions
– Health Information Exchange (HIE) for NHIN
– Medical Imaging Repository at UCSF an Merck
– Public Health Affinity Domain at the Middle East (based on HIE)
– Complex Event Processing at the Nice hospital


Our Group Vision - from Data to Knowledge


Agenda
The Problem
IHE - Integrating the Healthcare Enterprise
IHE XDS - Cross Enterprise Document Sharing
Additional IHE ITI Profiles
IBM Health Information Exchange
Real Life Experience


The Problem

Creating health records at a regional or national level requires
electronic data exchange among healthcare organizations
IT systems within hospitals, HMOs, clinics and other care-delivery
organizations become an integral part of the working environment
Healthcare organizations still lack the ability to share information
across organization boundaries
Cross-enterprise data sharing implies the need for a standards
based communication mechanism
– Without standards: No information exchange is expected to take place
– With standards: No single vendor is expected to dominate the market


Agenda
The Problem



IHE is a healthcare industry organization promoting
coordinated use of established standards to improve
healthcare IT system integration
IHE produces healthcare integration profiles which:
– Address a specific healthcare integration scenario
– Build upon one or more existing, established standards such as HL7
and DICOM
– Define constraints which limit the options available when using
underlying standards


IHE Organizational Structure
IHE (International) Strategic Development Committee

Regional Deployment Global Development

IHE North America IHE Asia

China Japan Radiology IT Laboratory
Canada
Infrastructure
USA Korea Taiwan

Cardiology Patient Care Pathology
Coordination

IHE Europe
Radiation Patient Care Eye care,
France Germany Italy Netherlands Oncology Devices Quality, etc.

Norway Spain Sweden UK

Professional Societies / Sponsors Contributing &
ACC GMSIH COCIR SIRM ESC JAHIS METI-MLHW Participating
ACP SFR EAR-ECR BIR JIRA MEDIS-DC
HIMSS SFIL DRG EuroRec
Vendors
JRS JAMI
RSNA

History of IHE Domains
Veterinary
Endoscopy
Pathology
Over 100 vendors involved world-wide Pharmacy

8 Technical Frameworks Quality
Patient Care Devices (1)
48 Integration Profiles
Patient Care Coordination (5)
Testing at “Connectathons” world-wide
Radiation Oncology (1)
Demonstrations at major conferences world-wide
Eye Care (3)
Laboratory (6)
Cardiology (7)
IT Infrastructure for Healthcare (17)
Radiology (18)
(2003)

(2004)
Year 5

Year 6

(2007)
Year 9
(2002)

(2006)
Year 4

Year 8
(2005)
Year 7
(1999)

(2000)

(2001)
Year 1

Year 2

Year 3


IHE Integration Profiles from IT Infrastructure Domain
What is available and has been added in 2006/07

Clinical and PHR Content
Security Patient ID Mgmt
Emergency Referrals
PHR Extracts/Updates
Format of the Document Content
ECG ReportDocumentvocabulary
and associated coded Basic Patients Privacy Patient Demographics
Format of the Document Content
Lab ResultsDocument Content
Document
and associated coded vocabulary Consents Query
Format of the Establish Consents & Enable
Content
Scanned Documents
and associated coded vocabulary Access Control
Format of the Document Content Patient Identifier
Imaging Information
Formatassociated coded Content
and of the Document vocabulary
Cross-referencing
Format of theSummary
Medical Document Content
and(associated coded vocabulary
Document Digital Map patient identifiers across
Meds, Allergies, Pbs)
Format of the Document Content Signature independent identification
Attesting “true-copy and origin domains
and associated coded vocabulary

Health Data Exchange Audit Trail & Node
Cross-Enterprise Authentication Other
Document Sharing (XDS) Centralized privacy audit trail and node
to node authentication to create a Request Form
Registration, distribution and access
across health enterprises of clinical secured domain. for Data Capture
documents forming a patient External form with custom
electronic health record import/export scripting

Consistent Time
Cross-Enterprise Document Notification of
Coordinate time across networked
Reliable Interchange (XDR) systems
Document Availability
Cross-Enterprise Document Notification of a remote
provider/ health enterprise
Media Interchange (XDM)


IHE Profile Development Lifecycle

2Q/3Q 2006 1Q 2007

Testing at 1Q 2007

Connectathons
Develop IHE
technical Demonstrations
specifications 2Q 2007
HIE v1.1

1Q 2006
Products
Identify available with IHE
standards (e.g. HL7,
DICOM, IETF, OASIS)
4Q 2005

Document Use Timely access to Easy to integrate
Case information products
12 RequirementsRecord – Standard Solution
National Health © 2006 IBM Corporation

Relevant IHE ITI Profiles
XDS - Cross Enterprise Document Sharing
– Specifies guidelines for sharing clinical documents across healthcare organization
boundaries
– XDS-I: XDS for Imaging
PIX - Patient ID Cross Referencing
– Specifies guidelines for cross-referencing a unique patient ID between healthcare
organizations
– Aka Master Patient Index (MPI)

PDQ – Patient Demographics Query
– Specifies guidelines for querying patient ID by demographic details
ATNA - Audit Trail and Node Authentication
– Specifies guidelines for security and auditing at both communication and application
layers
XUA – Cross Enterprise User Assertion
– Provides a means to communicate claims about an authenticated principal (user,
application, system) across enterprise boundaries


Agenda
The Problem


XDS Geographical Aspect & Terminology
EHR-CR
Clinical Affinity Domain
An EHR-CR or Care-delivery Record
A group of healthcare enterprises that
abstracts the patient information managed
have agreed to work together using a
by the IT system or by the set of systems of
common set of policies and share a Clinical Affinity Domain a single Care Delivery Organization
common infrastructure of repositories
and a registry

EHR-CR
EHR-CR Long Term
Acute Care Care

R -LR
EH
EHR-LR
The documents shared by the EHR-
CR and tracked by the registry form a
EHR-CR EHR-CR longitudinal record for the patients
PCPs & Clinics Diagnostic that received care among the EHR-
CRs of the Clinical Affinity Domain
Service


CAD - Clinical Affinity Domain

A group of healthcare organizations that have
agreed to share patient records along a set of
operational, business and legal agreements :
– Agreed-upon sharing policies
– Single Patient ID Domain (CAD ID)
– Common set of Codes
– Unified terminology
– Security & Access Control model/agreements


Cross Enterprise Document Sharing (XDS) Profile
Establish the IT Infrastructure for an Affinity Domain
Enables Care Delivery Organizations (CDOs) to cooperate in the care of a
patient by sharing clinical records

Patient Identity
Source
Patient Identity Feed [ITI-8] ↓
Query Registry
[ITI-16] ←
Document Registry Document Consumer

↑ Register Document
Provide & Register Document Set [ITI-14]
Set [ITI-15] Retrieve Document
Document Source → Document Repository [ITI-17] ←


XDS Actors
1. Document Source
– Produces and publishes documents
– Responsible for sending documents and metadata to a repository
2. Document Consumer
– Queries a registry for documents
– Retrieves selected documents from one or more repositories
3. Document Registry
– Maintains metadata about each registered document in a document entry
– Includes a link to the document in the repository
4. Document Repository
– Responsible for the persistent storage of documents
– Assigns a URI to documents for subsequent retrieval by a consumer
5. Patient Identity Source
– Provides a unique identifier for each patient and maintains a collection of identity traits


Provide and Register Document Set

A Document Source actor initiates the Provide and Register Document
Set Transaction.
For each document in the submitted set, the Document Source Actor
provides both the documents and the corresponding metadata to the
Document Repository.
The Document Repository is responsible to persistently store these
documents, and to register them in the Document Registry using the
Register Documents transaction.

Provide & Register Document
Set [ITI-15]
Document Source → Document Repository


Register Document Set
A Document Repository actor initiates the Register Document Set
transaction.
This transaction allows a Document Repository Actor to register
documents with a Document Registry, by supplying metadata about each
document to be registered. This document metadata will be used to
create an XDS Document Entry in the registry.

Document Registry

↑ Register Document
Set [ITI-14]

Document Repository


Query Registry
The Query Registry transaction is issued by the Document Consumer Actor
on behalf of a care provider to a Document Registry
The Document Registry Actor searches the registry and returns a list of
matching document entries including the locations and identifier of each
document in the Document Repository

Query Registry
[ITI-16] ←
Document Registry Document Consumer


Retrieve Document
A Document Consumer Actor initiates the Retrieve Document transaction.
The Document Repository will return the document that was specified by the
Document Consumer

Document Consumer

Retrieve Document
Document Repository [ITI-17] ←


Patient Identity Feed
This is IHE ITI Transaction 8, defined as part of the Patient Identifier Cross-
Referencing Integration Profile
It conveys the patient identifier and corroborating demographic data.
Its purpose in the XDS Integration Profile is to populate the registry with
patient identifiers that have been registered for the affinity domain

Patient Identity
Source
Patient Identity Feed [ITI-8] ↓

Document Registry


XDS Concepts

The XDS registry is the cornerstone of the document sharing process
– The source registers information to be exchanged in the registry
– The registry only maintains metadata for the document (and not the
document itself)
– Clinical information is not exposed
The XDS repository maintains the actual clinical document
– Clinical documents can be kept within the enterprise’s repository or they can
be transferred to another enterprise’s repository.
– Allows for data encryption.
Source initiates the sharing process and provides the clinical document
and the associated metadata
Consumer queries the registry and retrieve the data from the relevant
repository


Single Registry Multiple Repositories

Clinical Affinity Domain

HMO
Document
Hospital Consumer
Document
Source

Documents
Registry

Independent
Document
Repository


XDS – Key Features
Foundation for health IT infrastructures
– Shared Electronic Health Record, in a community, region, etc.
Scalable architecture for document sharing
– Between private physicians, clinics, long term care, pharmacy, acute care
with different clinical IT systems
– Suitable for other healthcare domains such as Public Health and Clinical
Trials
Distributed
– Each organization “publishes” clinical information for others to use
– Actual documents may remain in the source system
Easy access
– Care providers are offered a means to query and retrieve clinical
documents of interest
– All transactions are based on industry and communication standards


XDS – Key Features
Document centric
– Published clinical data is organized into “clinical documents”
using agreed standard document types (HL7-CDA/CCD, PDF,
DICOM, etc.)
Document content neutral
– Document content is processed only by source and consumer
systems. Infrastructure is generic
Standardized registry attributes
– Documents are described by a standardized set of attributes.
– Standardized queries are supported by all vendors


Deployment Options

Registry
Source Consumer

Repository
EHR-CR
EHR- EHR-CR
EHR-

Source
Registry Consumer
Repository

EHR-CR
EHR- EHR-CR
EHR-


Registry and Repository Artifacts
XDS Folder
An XDS Folder allows document
Submission Folder A sources to group the documents they
Set submit with other related documents

Submission Set
A set of XDS documents registered
Document together to a Document Repository
Document Document concerning information related to
Registry
Entry 1 Entry 2 one care event of a single patient

Document Entry
A Document Entry contains all
metadata for a specific XDS document
and a link to the document’s repository
location.

Document XDS Document
D

D
oc

oc

Repository An XDS Document is the smallest unit
u

u
m

m

of information that may be provided to
en

en
t

t

a Document Repository


Document & DocumentEntry Concept
XDS paradigm is built around documents (and not around records)
An XDS Document is a composition of clinical information that contains
observations and services to be exchanged within the Affinity Domain
Documents characteristics are defined by the HL7 CDA Standard
– Persistence, Wholeness, Potential for Authentication
An XDS Document is the smallest unit of information that may be
provided to a Repository and be registered in the Registry
– XDS does not provide mechanisms to access portions of a Document
XDS Documents are required to be globally uniquely identified
Each Clinical Document has set of metadata that describing it
– This metadata is referred as XDS DocumentEntry
– Most metadata attributes can be automatically generated form the clinical
document by the Document Source
– specially true for structured documents like CDA or DICOM


DocumentEntry Metadata
Document Author Person, role, specialty Legend
Patient Demographics Required
Service Start and Stop Time Optional
Document Creation Time Generated
Legal Authenticator
Title, comments,
Identifiers Patient ID, Unique ID, entryUUID
Kind of Document Class Code (e.g Prescription, Discharge Summary,
Report)
Type Code (more detail)
Event Code Main clinical event (e.g. colonoscopy, appendectomy)
Healthcare Facility Type Healthcare Facility Type Code and Display Name
Practice Setting Type Practice Setting Code and Display Name
Confidentiality Code
Technical Details MIME Type; Format Code (e.g. CDA); Size; Hash; URI;
Language
Available Status Available, Deprecated

SubmissionSet Concepts
Submission Set is related to care event(s) of a single patient
An XDS Submission Set is created for each submission request
– It is related to a single Document Source Actor
Submission Set creates a permanent entry in the Registry
– Submission Set includes one or more DocumentEntry object(s)
– Submission Set may refer to already registered XDS Documents that have
a relationship with the same care event
– Submission Set includes the record of new XDS Folders creation.
The Document Registry may be queried to find all documents registered
in the same XDS Submission Set
XDS provides complete flexibility to organization to relate Documents
and Submission Sets to an encounter, a visit, an episode of care, or
various workflow processes within clinical organization.


SubmissionSet Metadata
Each of the attributes listed below is an attribute on the RegistryPackage
object defining the Submission Set

Legend
Required Author – person, role, specialty, institution

Optional Comment – Any string

Generated Title – Title of this document

serviceStartTime

Submission time - Document submission Time
Availability Status – Approved, Deprecated
Coded elements–contentType (type of clinical activity)
Identifier – Patient ID, Source ID, Unique ID, entryUUID


Folder Concepts
The purpose of an XDS Folder is to provide a collaborative mechanism for
several XDS Document Sources to group XDS Documents
– Folders offer the Document Consumers a means to find all Document Entries placed
in the same Folder.
The following principles apply to an XDS Folder:
– A Folder groups a set of XDS Documents related to the care of a single patient
– One or more Document Source Actors may submit documents in a given Folder
– A Folder may be created by a Document Source and/or predefined in an XDS
Affinity Domain
– The content of a Folder is qualified by a list of codes/meaning,
– Source Actors may find existing Folders by querying the Document Registry
– Folders in XDS may not be nested
– The same documents can appear in more than one Folder
– Folders have a globally unique identifier


Folder Metadata

Legend
codeList
Required
availabilityStatus (approved, deprecated)
Optional entryUUID

Generated uniqueId
title
comments
lastUpdateTime
patientId


Agenda
The Problem


Patient Demographics Query (PDQ)
Find patients matching a given set of demographics
– Search may be based on combination of: name,
address, phone number, gender, date of birth, race,
marital status, birth place, citizenship id
Patient Patient
Key PDQ Actors: Demographics
Consumer
Demographics
Supplier
– Patient Demographics Supplier
Patient Demographics
– Database containing patient demographics and Query: QBP^Q22
corresponding patient identifiers
Patient Demographics
– Responds to queries for patient information Response: RSP^K22

– Patient Demographics Consumer
– Typically an EHR or PHR application that supports
lookup of patient information based on a partial
set of demographics


PDQ Example Query:
Rupert, Adrian

PDQ Consumer
(an EHR)
Patient Demographics Supplier
Response:

Rupert, Adrian
Gender: Male
Date of Birth: 09/24/1932
Address: 1342 Main Street Chatfield, MN
Patient Id: 13579
Rupert, Adrien
Gender: Female
Address: 58 1st Avenue Stewartville, MN
Patient Id: 2468
Rupert, Ade
Gender: Female
Address: 2525 Broadway Rochester, MN
Patient Id: 4A78X


Patient Identifier Cross-Referencing (PIX)
Find various identifiers for the same patient – for example:
– I know a patient’s id within a community clinic
– I need to find corresponding patient id within a given hospital
Key PIX actors:
– Patient Identifier Cross Reference Manager (PIX Manager)
– Maintains cross reference between corresponding patient ids from
different domains based on matching patient demographics
– Patient Identity Source
– Existing application within a hospital or clinic that is responsible for
assignment and management of patient ids
– Provides Patient Identity Feed for the PIX Manager
– Patient Identifier Cross Reference Consumer
– An application which has an id for a patient in one domain and
wishes to determine corresponding CAD ID
– Or ID in a different domain


PIX Transactions
Patient Identity
Source Hospital

Patient Identifier Cross
Patient Identity
Reference Consumer
Source
(an EHR application) Clinic
Li Wang
09/24/1932
A87631Male
M8354673993
PIX Query Li Wang
1435509/24/1932
A87631
M8354673993 Male
A87631 M8354673993 14355
Patient Identity
L-716 14355
L-716 A87631 L-716
Patient identifier Cross Source
Reference Manager Hospital

Patient Identity Source Li Wang
09/24/1932
Clinic Male

Li Wang
09/24/1932
M8354673993Male

Patient Identity Feeds


Audit Trail and Node Authentication (ATNA)
ATNA provides a secure healthcare information infrastructure by
prescribing how to:
– Secure systems
– Ensure access control to protected healthcare information
– Secure the network
– Only trusted systems are allowed to exchange protected healthcare
information
– Encrypted exchange of information also supported
– Track data access
– All access to and movement of protected healthcare information is
audited
Key ATNA Actors:
– Centralized Audit Record Repository
– Collects all Audit Trail events into a centralized place
– Provides a mean to investigate PHI access breaches

ATNA Within A Healthcare Network
Example:
Using an EHR application to retrieve a discharge summary from a local hospital

Audit login
Encrypt data to EHR
during
transport

Secured System Secured System
Hospital
Discharge Summary

Header Secure network Discharge Summary

Header
Clinic
Family History Family History

Body Medications
Immunizations
Body Medications
Immunizations
Vital Signs Vital Signs
Allergies Allergies

Authenticate Authenticate
… …

requesting target
clinic hospital

Central Audit import of
Audit Export of
data from hospital Audit Trial data into clinic
repository Repository EHR


Cross-Enterprise User Assertion (XUA)

New profile defined this year by IHE ITI and successfully
tested during the last Connectathon (January 2008)
Designed to support user level authentication
– Provides a means to communicate claims about an
authenticated principal (user, application, system) in
transactions that cross enterprise boundaries
Based on an Web Services enabled environment
– Uses WS-Trust and SAML for communicating principal
attributes
– Comes into play only within XDS.b supported environment
– ITI – 18 Stored Query transaction
– ITI – 43 Retrieve Document transaction


XUA Actors
X-Service User
– A system making a services request of an X-Service Provider
– e.g., an XDS.b Document Consumer issuing a query to the XDS.b
Registry
X-Service Provider
– A system providing a service that requires an X-User Assertion
– e.g., XDS.b Registry, XDS.b Repository
X-Assertion Provider
– A SAML Identity Provider (IDP) or WS-Trust Security Token Service
(STS)
– X-Assertion Provider is currently out of scope as an IHE actor


Regional Level Policies
Each affinity domain is qualified to set the sharing policies
Which document and data to share
– Not all clinical documents are required for the regional or national level
Where to keep original documents
– Under the generating organization or at the center
Which terminologies and coding schemes to use
– Translation from the CDO terminology to the Affinity Domain terminology
Which access control policies to set
Which user interfaces and end-client applications to use
– Access to data is possible from anywhere and is based on Internet
transactions
– Physician and Patient portals


Agenda
The Problem


IBM HIE Solution Architecture


IBM HIE XDS Registry
Serves as searchable index of patient medical records within a healthcare
community
Supports latest features outlined by IHE XDS and ATNA profiles
Register Document Set (ITI-14, ITI-42)
Registry Stored Query (ITI-18)
Patient Identity Feed (ITI-8)
ATNA Secure Node and Record Audit Event (ITI-20)
Based on proven, scalable IBM middleware
WebSphere Application Server (v6, Base & Network Deployment)
Network Deployment supports multi-server clustering for load balancing and failover
DB2 Universal Database (v8.2)
Provide support for Oracle if needed
IBM XDS Document Registry deployed in 2 of 4 U.S. Government NHIN projects


IBM HIE XDS Registry
ATNA
Generated
Events
Patient Identity Feed
HL7 v3 over Web Services

Patient Identity Feed XDS Document Registry JDBC XDS Document
JMS
HL7 v2 over MLLP MLLP (J2EE Application) Registry Database
Adapter (Document Metadata)

Register Document Set, Registry Stored Query
XDS.a - SOAP over HTTP
XDS.b - Web Services

WebSphere Application Server DB2 Universal Database


IBM HIE XDS Repository

Data store for clinical documents being shared within a healthcare community
Supports both centralized (hosted) architecture and federated architecture
Supports latest features outlined by IHE XDS and ATNA profiles:
Provide and Register Document Set (ITI-15, ITI-41)
Retrieve Document (ITI-17, ITI-43)
ATNA Secure Node and Record Audit Event (ITI-20)
WebSphere Application Server (v6, Base and Network Deployment)
Several back-end data storage models supported
File system (simple, low cost option)
DB2 Universal Database v9 (integrated, XML/relational data store)
DB2 Content Manager v8.3 (robust, highly scalable document management
system)
Deployed in 2 of the 4 U.S. Government sponsored NHIN projects


IBM HIE XDS Repository

File System
ATNA
Generated Local or
Events Distributed
Provide and Register Document Set File System
SOAP with Attachments over HTTP

Storage Options
GMAS
XDS
Retrieve Document Document Repository
HTTP/MTOM (J2EE Application)
Document DB2
Management Content
System Manager

WebSphere Application Server DB2 UDB
XML/Relational
Data Model


IBM HIE ATNA Audit Record Repository

Repository for audit events generated by systems handling PHI within a
healthcare network
Supports ATNA Record Audit Event (ITI-20) interface to other healthcare
applications
BSD Syslog protocol for data transport (RFC 3164)
Supports both RFC 3881 and IHE Provisional audit record formats
Support for reliable transport for audit massages (Currently not included in IHE)
Web-based tool provided to query audit data
Based on IBM’s Data Discovery and Query Builder product (DDQB)
Build and execute canned or ad hoc audit queries
WebSphere Application Server (v6, Base & Network Deployment)
Network Deployment supports multi-server clustering for load balancing and failover
DB2 Universal Database (v8.2)


IBM HIE ATNA Audit Repository

Data Discovery and Query Builder

HTTP Web-Based
Audit Query/Reporting
Interface JDBC

ATNA Audit
Record Database
Record Audit Event (Audit Information)
BSD Syslog JMS ATNA Audit JDBC
Audit
Interceptor Record Repository

WebSphere Application Server DB2 UDB


IBM HIE Audit Query Interface


IBM HIE XUA X-Assertion Provider
Serves as a WS-Trust Security Token Service (STS), creates and validates
SAML assertions
Supports WS-Trust 1.3 and WS-Trust 2005/02
Interoperates with other Security Token Services
Tivoli Federated Identity Manager (v6.1)
Supports both WS-Trust and SAML
IBM HIE XUA X-Assertion Provider was tested with several vendors during the
last IHE Connectathon (January 2008)
Currently out of scope as IHE actor


IBM HIE XUA X-Assertion Provider
Authentication
Service
(LDAP)
Get SAML Assertion
SOAP 1.1, SOAP 1.2

Underlying Systems
WS-Trust 2005/02, WS-Trust 1.3
Persistent
Validate SAML Assertion XUA X-Assertion Provider Storage
SOAP 1.1, SOAP 1.2 (Web Service Application) (DB2 UDB)
WS-Trust 2005/02, WS-Trust 1.3

Authorization
Service
(Tivoli Access
Manager)

Tivoli Federated Identity Manager


IBM HIE XDS-I Imaging Document Source

XDS-I (XDS for Imaging)
Variation of XDS to support sharing of medical images
Imaging document source actor is responsible for:
Registration of medical images and reports within an XDS
community
Retrieval of medical images and reports
Via DICOM or WADO (Web Access to DICOM Object)
Can be conceived as a DICOM<->XDS converter
Prevent copying of large data chunks within the Affinity
Domain
Subset of IBM’s Content Manager Offering (CMO)


IBM HIE XDS-I Imaging Document Source
IHE XDS-I Profile

XDS
Repository

DICOM DICOM

XDS-I XDS-I

XDS-I Document
Document XDS Consumer
Source Registry
PIX/PDQ Audit Repository
Manager Server


Eclipse Open Healthcare Framework (OHF)
The Eclipse Foundation
– Open source community whose projects are focused on
providing an extensible development platform and application
frameworks for building software.
– www.eclipse.org
The Eclipse Open Healthcare Framework (OHF)
– Project within Eclipse formed for the purpose of expediting
healthcare informatics technology.
– Extensible frameworks and tools which emphasize the use of
existing and emerging standards
– Encourages interoperable open source infrastructure
– Lowers integration barriers
– www.eclipse.org/ohf


OHF and IBM HIE

OHF is complementary technology to the IBM HIE
Infrastructure developed by IBM and other industry
partners.

OHF tooling helps vendors implement the standards so
they can continue to focus on making better products.
– Two options: Java libraries and Web Services

OHF software was used with the HIE Solution in the US
NHIN Project and the PHAD project for MECIDS


Eclipse OHF – Java and Web Service Adapters


Agenda
The Problem


HIE Involvement in Healthcare Industry Events
IBM has been a strong supporter of industry events aimed at validation or our HIE solution
and demonstration of IHE profiles and the underlying standards they are based upon

– IHE Connectathon North America – January 2006
– HIMSS – IHE Interoperability Showcase – February 2006
– RSNA – IHE Demonstration – November 2006
– IHE Connectathon North America – January 2007
– HIMSS – IHE Interoperability Showcase – February 2007
– ACC – IHE Interoperability Showcase – March 2007
– Zorg and ICT 2007 (Netherlands) – IHE Demonstration – March 2007
– IHE Connectathon Europe – April 2007
– Canada eHealth Conference – IHE Interoperability Showcase – May 2007
– World of Health IT Conference (Vienna Oct 2007) – IHE Interoperability Showcase

IBM providing internet-accessible reference implementation of IHE infrastructure profiles
(HIE) for ISV testing/demonstration for past 2+ years.


IHE Connectathon Test Partners (part 1 of 2)
Audit Repository Doc Registry Doc Repository openEMR/OHF

Accenture x x
Acuo x x
Agfa x x x x
Alert x x x
Allscripts x x x x
Ashvins x
Axolotl x
Bell Canada x x
Blueware x x x x
Canon x
CapMed x x x x
Caribel
Cegedim x x
Cerner x x
CGI x
CompassCare x x
Convergence x
CPSI x x
DataProcessing x x x
Dianoema x
Dictaphone x x
Eclipsys x x
EDL x x
Epic x x
Esel x x x
Etiam x x
Forcare x x x x
GE Clinisoft, RIS x Clinisoft, Muse, RIS x
HIPAAT x x
HXTI x x
IcoServe x x x
ICW x
Infinitt x x
Initiate x x
Intersystems x x
Kodak x x x x


IHE Connectathon Test Partners (part 2 of 2)
Audit Repository Doc Registry Doc Repository openEMR/OHF
McKesson x x
Medasys x x x
MedCommons x x x
MediNotes x x x
Mediware x x
MedQuist
Medos x
MIE x
Misys x x x
Moreau-Labbeer x
NDMA x x
NextGen x x x
NIST x
Obrieng x
Philips x
PracticePartner x x x
Quadramed x
Quovadx x x x
Rogan x
RVC x
Santeos x x x
Sectra
Siemens x x x x
Sillage x x
Smwaidr2i x x
SoftMedical x x x
Solinfo x x x
Sovera x x
SQLI x x x
SRDC x x x
Synapsis x x x
Tiani-Spirit x x x x
Visus

Total Vendors Tested 47 38 39 25


NHIN Architecture Prototype Project Vision
A nation-wide standards based network that will allow connectivity of existing and
future systems for providers and affiliated stakeholders

ONC Objectives IBM Approach
Develop and evaluate prototypes for an
interoperable NHIN architecture Maximize existing resources & systems
- Maximize existing resources to achieve - Maximize existing resources to achieve
widespread interoperability among health care
SW applications, (e.g. EHRs) widespread interoperability among health
care SW applications, (e.g. EHRs)
Spur technical innovation for nationwide sharing
of health information Be community centric
- In patient care and public health settings
- In patient care and public health settings
Achieve interoperability between SW
applications and networks Be interoperable between software
- Communicate and exchange information in an applications and networks
accurate, effective, useful, manner
- Communicate and exchange information
Promote collaboration between HHS health IT in an accurate, effective, useful, manner
contractors
- Develop Compliance Certification process Be security & privacy compliant
- Develop Standards Harmonization process
- Develop Privacy and Security solutions for - Develop Compliance Certification process
interoperable health information exchange - Develop Standards Harmonization
process
- Develop Privacy and Security solutions
for interoperable health information
exchange


IBM Healthcare Marketplace Partners
Each vendor must demonstrate information exchange
within and between three distinct community healthcare markets

Mid-Hudson Valley, NY (THINC)
– Taconic Healthcare Information Network and Community
(THINC) THINC
– Mid-Hudson Valley: evolving RHIO with shared data at
HealthVision hub
– 2,300 physicians supporting 700,000 patients
Research Triangle, NC (NCHICA)
– Competitive, high-tech urban environment
Rockingham County, NC
– Hospitals: Duke, WakeMed, UNC, Rex (UNC Health) Danville, VA (NCHICA)
– Practices, Public Health, Pharmacies
Rockingham County, NC and Danville, VA (NCHICA)
– Rural environment with NC and VA patients
– Hospitals: Morehead Memorial, Annie Penn
(Moses Cone Health System) Research Triangle,
– Practices, Public Health, Pharmacies NC (NCHICA)


IBM NHIN Phase 1 Participants
THINC Mid Hudson Valley
Research Triangle Rockingham County, NC
Kingston Hospital
Pinehurst, NC Danville, VA
St. Francis Hospital
Duke University Health Morehead Memorial Hospital
Vassar Brothers
System Eden Internal Medicine
Healthcare Medical Center Durham Medical Center Pulmonary, Allergy and Asthma
Providers Physician Practices FirstHealth of the Carolinas Clinic of Danville
Hudson Valley Primary Care Moore Free Care Clinic Moses Cone Health System
Bridge Street Family Medicine Pinehurst Medical Family Tree OB/GYN
Springside Medical Associates Pinehurst Surgical Moses Cone Internal Medicine
Rabi Sinha, MD Southern Pines Women’s Center Residency Program
Hudson River Community Health
CapMed (PHR)
Possibility Forge (openEMR)
Medical Application Allscripts (Touchworks 11™)
Vendors McKesson (Horizon WP Physician Portal™)
GE Centricity
MediTech
Medical Service Spectrum Lab
Lab Corp
Providers SureScripts®
Custom Patient Registration, Provider Registration, and Provider Notification Services
Custom Security Services
Core Services Initiate Identity Hub™ Software
IBM Healthcare Collaborative Network
IBM Heath Information Exchange (XDS Repository & Registry, FQS, OHF Bridge, ARR)
Infrastructure IBM Tivoli IBM WebSphere® DataPower
IHE Integration Profiles (ATNA, XDS, PIX, PDQ, XDS MS)
Standards HL7 / ASTM (CDA / CCD)
SAML, SSL/TLS, X509, Web Services Security (SAML / SOAP / Trust Language)


XDS Projects – Worldwide
Netherlands Lower
Austria Italy
Hilversum (Conto Corrente Salute)
UK CfH Leeuwarden
(Radiology WF) Amsterdam France Denmark (Funen)
Italy (Veneto) Quebec, Toronto,
DMP Spain (Aragon) Alberta, British Columbia
Austria Canada Infoway

VITL-Vermont

Boston Medical
Center - MA

Philadelphia HIE

CPHIC –
Pennsylvania

CareSpark – TN & VA

South Africa

CHINA-Shanghai Malaysia CHINA-MoH JAPAN-Nagoya THINC- New York
Imaging Info Sharing Lab results sharing Imaging Info Sharing NCHICA – N. Carolina

‫תודה‬
Hebrew (Toda)
Grazie
Italian
Thai
Traditional Chinese

Obrigado Merci
Brazilian Portuguese French
Russian

Gracias
Spanish
Danke Arabic

German

Simplified Chinese

Japanese


Standards-based Solution for National Level Document Sharing.

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (10)

Semelhante a Standards-based Solution for National Level Document Sharing.

Semelhante a Standards-based Solution for National Level Document Sharing. (20)

Mais de Fòrum Català d’Informació i Salut

Mais de Fòrum Català d’Informació i Salut (20)

Último

Último (20)

Standards-based Solution for National Level Document Sharing.