bill majurski national institute of standards and technology (nist) it infrastructure: profiles for...
TRANSCRIPT
Bill MajurskiNational Institute of Standards and Technology (NIST)
IT Infrastructure: IT Infrastructure: Profiles for Health Profiles for Health
Information Information ExchangeExchange
Affinity Domain Profiles
HIE Profiles
Categories of Profiles
Basic XDS
Cross Community
Point-to-Point
Notification
Patient ID Management
All focus on or support Document Sharing
What is XDS?
XDS is Cross-Enterprise Document Sharing
Cross-Enterprise – Elements can be owned by different organizations
Document Sharing – Elements of patient record organized as 'Documents'
Basic XDS
XDS.a - Original
XDS.b – Updated technology
Cross Community
XCA – Cross Community Access
Point-to-Point
XDM – Media Interchange (email, CD, etc.)
XDR – Reliable networking
Notification
NAV – Notification of Document Availability
Patient ID Management
PDQ – Patient Demographics Query
PIX – Patient Identifier Cross-Referencing
What is a Document?
Cross-Enterprise Document Sharing
What is a Document?
Collection of bytes
Persistent/Unchangeable
Documented Format
What We Will Not Discuss
Document Content Format
Security
These are covered in other talks
XDS Content
XDS does not define content•...just like your PC filesystem does not define file types•PDF, Word, Text, JPEG files are just collections of bytes. The file type is what links the file to an application.•XDS Content Profiles define what the bytes mean
XDS Content Profiles
• Content Profiles define document formats and XDS extensions for specific applications:– XDS-MS: Medical Summaries– BPPC: Basic Patient Privacy Consents– XPHR: Exchange of Personal Health Record Content– PPHP: Pre-procedure History and Physical – EDR: Emergency Department Referral– XDS-SD: Scanned Documents– XDS-Lab: Lab Reports– XDS-I: DICOM Images
Security is still required
– ATNA: Audit Trail and Node Authentication
• Basic security functions: centralized audit trail,authentication of systems (not users),optional encryption for transport connections
• Required by IHE for all XDS implementations
What are we defining?
IHE Profiles are NOT an architecture
It is a collection of architectural components
To build into new or existing systems
To aid in integration
XDSXDSCross-enterprise Cross-enterprise
Document SharingDocument Sharing
XDS
• Big Picture
• Transactions and Actors
• Metadata
• How it integrates with PIX/PDQ
• Common configurations
XDS: Big Picture
• Provide support for document-based patient EHR
• Support for document storage within existing products
• Provide support for indexing of patient documents
• Support query and retrieval of patient documents
• Scalable architecture
XDS: Big Picture
• Points of view• EHR-CR : Care-delivery Record
– Patient information – Managed by a Care Delivery Organization
• EHR-LR : Longitudinal Record – Documents shared by EHR-CR(s)– Tracked by Registry
• Clinical Affinity Domain : – Group of healthcare enterprises (EHR-CR)– Common set of policies– Share a single registry
• Archival
XDS: Big Picture
• 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.
XDS: Big Picture
• Distributed: Each Care delivery organization “publishes” clinical information for others. Actual documents may remain in the source system.
• Cross-Enterprise: A Registry provides an index for published documents that can be queried!
• Document Centric: Published clinical data is organized into “clinical documents”. using agreed standard document types (HL7-CDA/CCD, PDF, DICOM, etc.)
XDS: Big Picture
• Document Content Neutral: Document content is processed only by source and consumer systems. Infrastructure is generic.
• Standardized Registry Attributes: Documents are described by standardized set of attributes. Standardized queries supported by all vendors.
XDS Actors
• Document Source
• Document Repository
• Document Registry
• Document Consumer
Document Source
• Has document to store
• Creates description (metadata) for document
• Submits
Document Repository
• Accepts document and metadata from Document Source
• Stores document
• Forwards metadata to Document Registry
• Later, reproduces document on request (allows retrieval)
Document Registry
• Accepts metadata from Repository
• Stored metadata
• Accepts queries about metadata
• Returns metadata matching queries
Document Consumer
• Generates queries to Registry
• Accepts metadata back from Registry
• Displays list of documents for user to choose from (probably)
• When user selects document from list, retrieves and displays document
XDS Transaction Diagram
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed
Query Documents
Retrieve Document
Provide and Register
Document Set
Register Document Set
Patient Registration
Patient Identity Source
Document Registry
Patient Identity Feed
Document Submission
Document Registry
Document Repository
Document Source
Provide and Register
Document Set
Register Document Set
Query and Retrieve
Document Registry
Document Repository
Document Consumer
Query Documents
Retrieve Document
Register Document Set
XDS Actors
• Document Source– Source of documents and metadata about documents
• Document Repository – Stores documents, requests indexing in Document
Registry, supports retrieval
• Document Registry – Indexes documents, supports search
• Patient Identity Source – Feeds identity of known patients to Document Registry
• Document Consumer – Initiates search and retrieval for consumer of
documents
Metadata Objects
• Metadata is data stored in the Registry• Document - represents a real document• Submission Set - included in all
submissions to document the submitted “package”
• Folder - for grouping documents (directory metaphor)
• Association - Links other objects together
Object Structure
• Each Metadata Object has internal structure
• ebRIM standard coding used (XML)
SubmissionSet
DocumentAssociation(HasMember)
Single Document Submission
Envelope Contents
Metadata
Submission Set Attributes
• Author – person, role,
specialty, institution
• Title, comments, submission time
• Availability Status– Submitted or
Approved
• Coded elements– contentType (type
of clinical activity)
• Identifiers– Patient ID, Source
ID, Unique ID, UUID
Document Attributes
• Author– Person, role, specialty,
institution
• Legal Authenticator• Title, comments,
creation time, service start/stop time
• Availability Status– Submitted, Approved,
Deprecated
• Identifiers– Patient ID, Unique
ID, UUID
• Demographics– Source Patient ID,
Patient Demographics
Document Attributes (cont)
• Coded Values– Kind of Document
• Class Code (general catagory)
• Type Code (more detail)
– Event Code (main clinical event)
– Healthcare Facility Type
– Practice Setting Type– Confidentiality Code
• Technical Details– MIME Type – Format Code (more
detail)– Size– Hash– URI– Language
Document Attributes (cont)
Document Metadatapoints to
Document
in Repository
Association Attributes
• Type– HasMember– RPLC (Replace)– APND (Appends)– XFRM (Transformation)– Signs
• SubmissionSetStatus– Original or Reference
• Pointers– sourceObject, targetObject
Multiple Document Submission
SubmissionSet
DocumentAssociation(HasMember)
DocumentAssociation
(HasMember)
SubmissionSet
Status = Approved
DocumentStatus = Approved
Association(HasMember)
SubmissionSet
Status = Approved
DocumentStatus = Approved
Association(HasMember)
Association(RPLC)
DocumentStatus = Approved
Status = Deprecated
Document Replacement
Digital Signature
• Clinical Document Stored in Repository– Indexed in Registry
• Digital Signature (Document) Stored in Repository– Indexed in Registry
• How is Signature “attached” to Clinical Document?
Digital Signature (DSG Profile)
SubmissionSet
Status = Approved
ClinicalDocument
Status = Approved
Association(HasMember)
SubmissionSet
Status = Approved
SignatureDocument
Status = Approved
Association(HasMember)
Association(Signs)
XDS Metadata handling
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed
Query Documents
Retrieve Document
Provide and Register
Document Set
Register Document Set
Generates
Stores
Interprets
Adds
XDS Options
• Options center around Document Source actor• Basic operations• Submit single document• Replace existing document• Optional features• Off-line mode• Multi-document submission• Document life-cycle management
– Submit addendum or transformation of document
• Folder management– Create folder, add to folder
Affinity Domain
• Set of organizations/systems organized around a single Registry
• Common set of Codes
• Single Patient ID Domain
• Involves business and legal agreements
• Security model/agreements
Enterprise
Enterprise
Enterprise
EnterpriseImaging Center
Hospital B
Hospital A
Emergency Room
PCP
PatientAdmin
Repository
Repository
Repository
Repository
Cross-Enterprise Document Registry(XDS)
-Cross Enterprise Document
Registry(XDS)
XDS Example
HealthcareContent Standards
HL7 CDA, CEN EHRcomHL7, ASTM CCR
DICOM …
Internet StandardsHTML, HTTP,
ISO, PDF, JPEG …
Electronic BusinessStandards
ebXML, SOAP …
XDS: Standards Used
XDS: Standards Used
• XDS Infrastructure Standards• OASIS/ebXML
– Registry Information Model v2.0• Basis of XDS Registry Information Model
– Registry Services Specifications v2.0• Registry Services
– Messaging Services Specifications v2.0• Offline protocols
• ISO/IEC 9075 Database Language SQL– Registry Query Language
• SOAP with Attachments– Protocol for communication with XDS Registries and
Repositories
• SHA-1 [FIPS 180-1]– Document Hashes
XDS: Standards Used
• XDS Infrastructure Standards (cont)• HL7 Version 2.3.1
– Messages for Patient Identity Management
• HL7 Version 2.5– Datatypes for XDS Registry Attribute values
• HL7 CDA Release 1– XDS Document concept definition– Source of XDS Document Entry Attributes
• DICOM, ASTM CCR, HL7 CDA Release 2, CEN EHRcom– Sources of XDS Document Entry Attributes
XDS: Standards Used
• HTTP– Protocol for Retrieve
Document– Online SOAP bindings
• SMTP– Offline ebMS bindings
• IETF– Language Identifiers
• MIME– Document Type codes
• UTF-8– Encoding of Registry
Attributes
• XDS Infrastructure Standards (cont)
Two “categories” of standards used
XDS Infrastructure
XDS Content
XDS: Standards Used
XDS Content Profiles
• Outside scope of XDS; layer on top of XDS • Content Profiles
– Document use cases and translation of document content into registry metadata
– Publishable separately– Generated (mostly) by other committees (PCC,
Radiology, Lab etc)
• Of concern only to Document Source and Document Consumer actors
• Base standards for Content Profiles include: HL7 CDA, DICOM, ASTM CCR
XDSXDSQuery Catalog Query Catalog
supported by Stored Querysupported by Stored Query
Stored Query
• Defines a collection of queries– Name– Function/purpose they serve– Parameters they accept
• Must be supported by all XDS Registries!
Query Types
• Primary queries– Based on Patient ID
• Secondary queries– Based on registry identifiers
Primary Queries
• FindDocuments– Find documents for a patient
• FindSubmissionSets– Find submission sets for a patient
• GetAll– Get everything known about a patient
• Each have parameters to restrict documents ‘found’
Secondary Queries
• GetDocuments– Given the ids of the documents
• GetFolders– Given the ids of the folders
• GetAssociations– Related to a given
document/folder/submission set
Secondary Queries (cont)
• GetDocumentsAndAssociations– Combines GetDocuments and GetAssociations
queries
• GetSubmissionSets– For a collection of documents and/or folders
• GetSubmissionSetAndContents– Given the id of the submission set, return its
contents
Secondary Queries (cont)
• GetFolderAndContents– Given the id of a folder return the folder and its
contents
• GetFoldersForDocument– Given the id of a document return all folders
that ‘contain’ the document
• GetRelatedDocuments– Given the id of a document return all
documents that are related to the document through an association
XDS.a vs XDS.b
XDS.a• Older standards• Registry
(ebRIM/ebRS 2.1)
• Web Services (SOAP w Attachments)
• Most transactions are WS
• HTTP Retrieve
XDS.b• Newer Standards• Registry
(ebRIM/ebRS 3.0)
• Web Services (Addressing, MTOM/XOP)
• All transactions are WS
• WS Retrieve
XDS ConfigurationsXDS ConfigurationsUnderstanding how Understanding how
the actors work togetherthe actors work together
XDS Transaction Diagram
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed
Query Documents
Retrieve Document
Provide and Register
Document Set
Register Document Set
Source/Consumer Grouping
• A single 'workstation' that can submit and access content.
XDS Transaction Diagram
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed
Query Documents
Retrieve Document
Provide and Register
Document Set
Register Document Set
Registry/Repository Grouping
• Affinity Domain could offer a central Repository along with Registry to serve facilities that do not have local Repository.
XDS Transaction Diagram
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed
Query Documents
Retrieve Document
Provide and Register
Document Set
Register Document Set
Source/Repository Grouping
A source of documents could be an existing EHR which
• Registers documents in Registry
• Allows document retrieval via Retrieve Document transaction
• Stores information internally in non-document formats
• Must manage document persistence
What is a Document?
• Content/Documents have 3 formats:– Storage – Transfer/interface– Display
• XDS constrains the transfer/interface through Content Profiles– Use of IHE published Content Profiles is a
local choice. It is not required by XDS.
• Transfer/interface formats are chosen locally by Affinity Domain
• IHE only makes recommendations
Support ProfilesSupport Profiles“Infrastructure for XDS”“Infrastructure for XDS”
XDS Support
Collection of profiles that support XDS• Globally Consistent Time (CT profile)• Patient Management (PIX/PDQ profiles)• Node Authentication (ATNA profile)• Audit Logging (ATNA profile)• Authorization Assertions (XUA profile)• Notification of Availability (NAV)• Digital Signature (DSG)
Support ProfilesSupport ProfilesConsistent Time (CT)Consistent Time (CT)
Consistent Time Profile
• XDS describes a distributed system - time synchronization is critical
• Network Time Protocol ( NTP) version 3 (RFC 1305) for time synchronization
• Actor must support manual configuration
• Required accuracy: 1 second
• Optionally Secure NTP may be used
Support ProfilesSupport ProfilesPatient Identifier Cross-referencing (PIX)Patient Identifier Cross-referencing (PIX)
Patient Identifier Cross-referencing (PIX)
• 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
Patient Identifier Cross-referencing (PIX)
• 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
Patient Identity Feed [ITI-8]
PIX Query [ITI-9] PIX Update Notification [ITI-10]
Patient Identity Source
Patient Identity Crossreference Manager
Patient Identity Consumer
PIX Transaction Diagram
XDS: PIX integration
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed
Query Documents
Retrieve Document
Provide and Register
Document Set
Register Document Set
PIX XREF ManagerPIX Query
PIX 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)
PIX 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)
PIX 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)
PIX: Standard Used
• 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 Summary
• Patient ID management
• Translation of Patient IDs across Patient ID domains
• Patient ID feed
• Query & Notification of Cross Referencing
PIX as seen from XDS
• NOT a requirement
• XDS Affinity Domain allows only a single Assigning Authority for Patient IDs
• Implication: do your complex Patient ID management outside of the XDS environment
• To 'do' XDS, translate your Patient IDs to the Patient ID Domain (Assigning Authority) defined for the Affinity Domain.
Patient ID Responsibilities
Who must manage?• Document Source• Document Consumer• (known as Edge Systems)
• Registry and Repository only see Assigning Authority defined for Affinity Domain
• (known as Infrastructure Systems)
Edge Systems
Must translate local Patient ID to Affinity Domain Patient ID
• Use request to PIX Cross-Reference Manager– Translate PID X in local domain– To domain Affinity Domain– Return is PID in Affinity Domain
Edge Systems
• Management of healthcare information always starts with a Patient
• Identified by name and demographics• PDQ query translates
name/demographics to pick-list of matching Patients
• Produces Patient ID in a domain
Registry
Registry has two uses for Patient ID• What are valid Patient IDs
– Consistency check against submitted documents
• Handle request to Merge two Patient IDs
• PIX profile supplies both of these to Registry
Support ProfilesSupport ProfilesPatient Demographic Query (PDQ)Patient Demographic Query (PDQ)
Patient Demographics Query (PDQ)
• Allow quick retrieval of a patient list including common patient names, identifiers, contacts, and visit information
• Enable selection of correct patient when full identification data may not be available
• Limits access to only a subset of demographic and visit information
Patient Demographics Query (PDQ)
• Enables access on demand to diverse systems and devices – Participants that do not need continual
synchronization of patient registration information
– Devices that cannot participate in monitoring of ADT feeds, e.g.:
• Small-footprint devices• Low-memory devices
Patient Demographics Query (PDQ)
• Allow search on full or partial data
• Retrieve information from any domain to which the client has query access
• Allows use of matching algorithm (e.g., soundex) to find near matches
Patient Demographics Supplier
Patient Demographics Consumer
Patient Demographics
Query
Patient Demographics and Visit Query
A departmental system that is connected on demand to the registration system.
Diverse systems including bedside monitors, physician office systems, lab applications, mobile blood bank registries; might be any system at the point of contact.
PDQ Transaction Diagram
PDQ Standards Used
• Employs HL7 Conformance Based Queries– Defined in HL7 Version 2.5, Chapter 5– Profiles Query by Parameter (QBP^Q22)
with Segment Pattern Response (RSP^K22)
PDQ Actors
• Patient Demographics Consumer • Definition
– Requestor of patient demographic (and perhaps current visit) information
– Allows user to associate information with a patient at the point of care
• Transaction Supported – Required– Patient Demographics Query (as sender)
• Transaction Supported – Optional– Patient Demographics and Visit Query (as sender)
PDQ Actors
• Patient Demographics Supplier • Definition
– Repository of patient information that can be searched on demographic or visit-related fields
• Transaction Supported – Required– Patient Demographics Query (as receiver)
• Transaction Supported – Optional– Patient Demographics and Visit Query (as
receiver)
PDQ Operation
• Patient Demographics Query • User enters full or partial demographic
information (e.g., partial last name and first initial) for patients of interest
• Application associated with Patient Demographics Consumer sends HL7 QBP^Q22 to Patient Demographics Supplier to find matching information– May request specific domains from which to
return identifier information
XDS: PIX/PDQ integration
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed
Query Documents
Retrieve Document
Provide and Register
Document Set
Register Document Set
Patient Demographics
Supplier
PIX XREF ManagerPIX Query
Patient Demographics Query
Support ProfilesSupport ProfilesAudit Trail and Node Authentication (ATNA)Audit Trail and Node Authentication (ATNA)
Content ProfilesContent Profiles
Definition
• XDS defines a mechanism for sharing ‘Documents’
• ‘Document’ defined as a byte stream with a size, hash, and mime type
• Content Profiles are standardized document formats defined within IHE
Domains
• The following IHE Domains have defined XDS Content Profiles
• IT Infrastructure (ITI)
• Radiology
• Laboratory
• Patient Care Coordination (PCC)
IT Infrastructure
XDS-SD• Scanned document
• Stored in PDF format
• Wrapped in CDA/R2
Basic Patient Privacy Consents (BPPC)• More than a Content Profile
• Includes privacy processing rules enforced by the Document Registry in queries
Radiology
XDS-I (XDS for Imaging)• Normal XDS actors plus
– Image Document Source (extension to XDS Document Source)
– Image Document Consumer (extension to XDS Document Consumer)
– Image Document Source stores Radiology images locally in Image Archive
– Image Manifest Document stored in XDS Repository– Manifest (also called Key Object Select - KOS)
references specific DICOM content in Image Archive
Retrieving Radiology Content
• Query Registry, receive metadata – Metadata describes Image Manifests
• Choose and retrieve Image Manifest(s) from Document Repository
• Decode Manifest and retrieve Image content from Image Archive
Laboratory
• Lab Report
Patient Care Coordination
Many, many Clinically oriented Content Profiles
XDR / XDMXDR / XDMPoint-to-point transmissionPoint-to-point transmission
of documentsof documents
XDM
Cross-Enterprise Document Media Interchange
XDM
Big Picture
Documents and XDS Metadata shared via media
XDM
Cross-Enterprise Document Media Interchange (XDM)
Options
• USB
• CD-R
• ZIP over email
XDM
• Imposes File/Directory structure on the media
• Transport Multiple XDS Submission Sets • Each Submission Set has
– Metadata describing documents– Documents
• Protocol structure of XDS imposed on file/directory organization
XDM
Uses
• Release of documents to patient
• Manual (in pocket or email) transfer of documents
• Local display after receipt– Index.htm file required to support
display
• These are manual operations!
XDR
Cross-Enterprise Document Reliable Interchange
XDR
Cross-Enterprise Document Reliable Interchange (XDR)
• Point-to-point transmission of XDS content over reliable communications
• Uses Provide and Register transaction (from XDS)
• A new profile but really just documents how to use Provide and Register to perform point-to-point transfers.
XDR
Reliable asynchronous point-to-point transfer of XDS metadata and documents
• Reliable transfer comes from ebMS Messaging Services Specification v2.0
XDR
• Single Submission Set per transfer– More like XDS than XDM
• Optionally identify intended recipients
XDS + XDR + XDM
How do XDR and XDM work with XDS?
• XDS Query/Retrieve can feed XDR/XDM transmission
• Point-to-point transfer via XDR/XDM can feed XDS submission
XCAXCACross-Community Cross-Community
AccessAccess
XCA
Big Picture
• XDS defines the operation of an Affinity Domain (single Registry + ...)
• XCA defines interchange between multiple communities. An Affinity Domain is one type of community.
XCA
Features of an XCA community• Accept Query and Retrieve
transactions from other communities– Allows sharing of local documents
• A community could be an Affinity Domain...or not.
XCA
A few details• Uses Stored Query and XDS.b
Retrieve to access foreign community content
• A query can be broadcast to multiple communities (document discovery)
• Introduces homeCommunityId to identify/address communities
• Uses ebRIM/ebRS 3.0 (like XDS.b)
XCA
Tough problems still to be solved• Patient ID management
– How to manage translation between communities
– PIX/PDQ provide some of the necessary features
• Configuration Management– How to translate/manage coding
Community Community Network BNetwork B
Document Registry
PracticePracticePractice
ClinicClinicClinicClinic
HospitalsHospitalsHospitalsHospital
Diag Test
Other
PracticePractice HospitalHospital
Community Community Network CNetwork C
Document Registry
PracticePractice
Clinic
Hospitals
Hospitals
IHE transactions (future)
CrossCommunityGateway
CrossCommunityGateway
CrossCommunityGateway
National Network ANational Network A
Non-IHE Non-IHE National National EHREHR
Which community holds records for a patient ?
XDS Cross Community…Access
• Cross-Community Gateways query and retrieve records (2007 & future)
• National or Regional Networks not required to be IHE-based
• Mapping to & from IHE Transactions performed by X-Community Gateways
Regional Network BRegional Network B
Acute Care (Inpatient)
PCPs and Clinics (Ambulatory)
Long Term Care
Other Specialized Careor Diagnostics Services
Document Registry
DocumentRepository
Longitudinal Recordas usedacross-encounters
Regional Network CRegional Network C
Acute Care (Inpatient)
PCPs and Clinics (Ambulatory)
Long Term Care
Other Specialized Careor Diagnostics Services
Document Registry
DocumentRepository
Longitudinal Recordas usedacross-encounters
Regional Network ARegional Network A
Acute Care (Inpatient)
PCPs and Clinics (Ambulatory)
Long Term Care
Other Specialized Careor Diagnostics Services
Document Registry
DocumentRepository
Longitudinal Recordas usedacross-encounters
Cross Community Cross Community GatewayGateway
Which community holds records for a patient ?
CrossCrossCommunityCommunityGatewayGateway
CrossCrossCommunityCommunityGatewayGateway
CommunityCommunityLocator serviceLocator service
IHE TransactionsIHE Transactions(future)(future)
Cross-Community…Location
• Each region notifies Community Location Service when new patient is registered or first data is stored.
• Cross Community Gateways query Community Locator Service (future)
• Cross-Community Gateways query and retrieve records (2007 & future)
Other Cross-community Issues…
• Management of Patient IDs– Normally managed within Affinity
Domain
• Clinical Coding– Normally managed within Affinity
Domain
Cross Community Access: Value Proposition
• Sharing of documents beyond the XDS Affinity Domain (community) boundary.
• Part of a larger vision for regional and national sharing – 2006 whitepaper on Cross Community Information Exchange– Cross Community Access (2007)– Cross Community Location (2008)
• Scoped to document sharing between XDS Affinity Domains. Future goal to define sharing with other types of communities.
Cross Community Access: Technical Solution
• Cross Community Gateway– A new actor which supports all inter-community
communications. Encapsulates in one actor all activities required to communicate outside the community.
– Every community would have one cross community gateway which would interact with actors within the community and remote cross community gateways.
• Cross Community Consumer– Initiator of a request for information beyond the community.
• Technical Issues:– Need for asynchronous transactions in the cross community
environment– Interaction with existing XDS actors– Reliable identification of the patient
Community Community Network BNetwork B
Document Registry
PracticePracticePractice
ClinicClinicClinicClinic
HospitalsHospitalsHospitalsHospital
Diag Test
Other
PracticePractice HospitalHospital
Community Community Network CNetwork C
Document Registry
PracticePractice
Clinic
Hospitals
Hospitals
18 edge systems4 infrastructure systems
5 edge systems 4 infrastructure systems
13 edge systems3 infrastructure systems
3 infrastructureSystems
Community Community Network ANetwork A
Document Registry
PracticePracticePracticePracticePractice
ClinicClinicClinicClinic
HospitalsHospitalsHospitals
Diag Test
HIMSS Interoperability ShowcaseThe largest multi-vendor prototype ever built !
Patient Information Options
• PIX Feed to Document Source/Consumer
• PDQ queries from Document Source/Consumer
• Use of Patient ID Cross-Referencing by Document Source/Consumer
These are all optional within XDS!
Patient ID Patient ID MergeMerge
Merge
Issues• Patient Management is an imperfect
art• Documents get assigned to the wrong
Patient ID• Multiple Patient IDs identify single
Patient• Single Patient ID identifies content for
multiple Patients
Merge
• Merge Supplement starts to offer tools to manage these issues in XDS
• Relies on PIX notification of Patient ID related problem
• Current scope is to merge two Patient IDs that are found to represent same Patient
• Early work ... still evolving