This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Cross-Enterprise Document Cross-Enterprise Document Media Interchange XDMMedia Interchange XDM
(and XDR)(and XDR)
IHE ITI Update Feb. 2007IHE ITI Update Feb. 2007
3
User RequirementsUser Requirements
Beyond the inter-applications Beyond the inter-applications structured structured messagesmessages and and informal textual interchangesinformal textual interchanges between healthcare professionals, there is an between healthcare professionals, there is an increasing need for increasing need for interchange of medical interchange of medical documentsdocuments (structured or not) (structured or not)
Complementary to Complementary to EHR managed by healthcare EHR managed by healthcare professionalsprofessionals inside care facilities (acute and inside care facilities (acute and ambulatory care), there is an emerging need for ambulatory care), there is an emerging need for sharing medical documentssharing medical documents among these among these professionals, and with the patientprofessionals, and with the patient
Electronic document is the Electronic document is the intermediate intermediate objectobject enabling to manage the link enabling to manage the link between between non structured informationnon structured information (letters, dictated reports…) and (letters, dictated reports…) and the one the one managed inside medical databasesmanaged inside medical databases (EHR) (EHR)
A A patient centricpatient centric « envelope » approach « envelope » approach enables to manage the documents enables to manage the documents interchangeinterchange as well as their as well as their sharingsharing, with , with an an easy and structuring implementationeasy and structuring implementation
Before to address the EHR itself, the IHE Before to address the EHR itself, the IHE community has decided to work on the community has decided to work on the cross-enterprise clinical document cross-enterprise clinical document sharingsharing
This document sharing IHE XDS This document sharing IHE XDS Integration Profile is referenced in Integration Profile is referenced in numerous emerging projects around the numerous emerging projects around the World, at different levels (healthcare World, at different levels (healthcare centers and local / specialized / regional / centers and local / specialized / regional / state health networks)state health networks)
10
Implementing IHE XDS in regional & national Implementing IHE XDS in regional & national projects…Todayprojects…Today
Canada Infoway
IHE InteroperabilityShowcase ‘06
Denmark (Funen)Italy (Veneto)Spain (Aragon)
Austria
THINC- New YorkNCHICA – N. Carolina
Italy (Conto CorrenteSalute)
MA-Share – MAIHIE – INMendicino - CA
FranceNational
PHR
11
Acute Care (Inpatient)
PCPs and Clinics (Ambulatory)
Long Term Care
Other Specialized Careor Diagnostics Services
Building and accessing DocumentsBuilding and accessing Documents
EHR-CR: EHR-CR: Care RecordCare Record systems systemssupportingsupporting care delivery care delivery
XDS – Value PropositionXDS – Value PropositionFoundation 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.
13
XDS - Value PropositionXDS - Value PropositionDistributed: Each Care delivery organization “publishes” clinical information for others. Actual documents may remain in the source EHR-CR.
Cross-Enterprise: A Registry provides an index for published information to authorized care delivery organizations belonging to the same clinical affinity domain (e.g. an LHII).
Document Centric: Published clinical data is organized into “clinical documents”. using agreed standard document types (HL7-CDA, ASTM-CCR, PDF, DICOM, etc.)
Document Content Neutral: Document content is processed only by source and consumer IT systems.
Standardized Registry Attributes: Queries based on meaningful attributes ensure deterministic document searches.
14
XDS DocumentXDS Document
XDS Submission SetXDS Submission Set
XDS FolderXDS Folder
XDS KXDS Key Conceptsey Concepts
15
SubmissionSet
Folder
XDS : conceptsXDS : concepts
DocumentDocument
Document
FolderFolder
Documents server (registry-repository)
Submission
16
XDS DocumentXDS Document
A set of attested clinical information (structured or not) which A set of attested clinical information (structured or not) which form an element of a patient record to be shared. It may form an element of a patient record to be shared. It may already exist within the source IT system.already exist within the source IT system.
XDS Submission SetXDS Submission Set
A set of documents related to a patient that a (team of) A set of documents related to a patient that a (team of) clinician(s) in the same source system have decided to make clinician(s) in the same source system have decided to make available to potential consumers.available to potential consumers.
XDS FolderXDS FolderA means to group documents for a number of other reasons:A means to group documents for a number of other reasons:
Team work across several physicians,Team work across several physicians,
Episode of care, Episode of care,
Emergency information for a patient, etc.Emergency information for a patient, etc.
XDS leaves open the use of folders to affinity domain clinicians.XDS leaves open the use of folders to affinity domain clinicians.
XDS KXDS Key Conceptsey Concepts
17
Document Source
Document Registry
Document Repository
Provide&Register Document Set
Register Document Set
XDS: DiagramXDS: Diagram
18
Document Consumer
Retrieve Document
Query Documents
Document Source
Document Registry
Document Repository
Provide&Register Document Set
Register Document Set
XDS: DiagramXDS: Diagram
19
Document Consumer
Retrieve Document
Query Documents
Patient Identity Source
Patient Identity Feed
Document Source
Document Registry
Document Repository
Provide&Register Document Set
Register Document Set
XDS: DiagramXDS: Diagram
20
XDS: standards usedXDS: standards used
ebXML Registry ServicesebXML Registry Services
SOAP with attachments and ebXML SOAP SOAP with attachments and ebXML SOAP Messaging ServicesMessaging Services
Meta-data based on HL7 CDA with HL7 v2.5 Meta-data based on HL7 CDA with HL7 v2.5 content for ids (patient, prof/org)content for ids (patient, prof/org)
On line (HTTP) or optional off-line (SMTP) On line (HTTP) or optional off-line (SMTP) submission of documentsubmission of document
On-line (HTTP) SQL query with recent stored On-line (HTTP) SQL query with recent stored queries on Web Servicesqueries on Web Services
21
XDS: meta-dataXDS: meta-data
Patient:Patient: Affinity domainAffinity domain idid,, demographics (id, demographics (id, name, birth date…) « as viewed by the source »name, birth date…) « as viewed by the source »
Identification:Identification: ID indexID index, , repositoryrepository URIURI, , unique idunique id, , dates of dates of creationcreation and and start /end of medical actstart /end of medical act, , title, title, sizesize, , hashhash, , statusstatus, parent document, parent document
Classification:Classification: classclass, , typetype, , formatformat, , MIME typeMIME type, , typetype and and specialty ofspecialty of institutioninstitution and and authorauthor, , medical codes, medical codes, confidentiality levelconfidentiality level RequiredRequired, , If knownIf known, , Generated by repositoryGenerated by repository, ,
classCode The code specifying the particular kind of document (e.g. Prescription, Discharge Summary, Report). It is suggested that the XDS Affinity Domain draws these values from a coding scheme providing a coarse level of granularity (about 10 to 100 entries). <rim:Classification
XDM / XDR Value propositionXDM / XDR Value proposition
Complementary to sharing documents (XDS), Complementary to sharing documents (XDS), point-to-point communication of documentspoint-to-point communication of documents
Both transports: secured mail & media (CD…)Both transports: secured mail & media (CD…)
As XDS, “document content agnostic”As XDS, “document content agnostic”
Maximal re-use of XDS objects & meta-dataMaximal re-use of XDS objects & meta-data
Compatible with exchange of images (PDI…)Compatible with exchange of images (PDI…)
All XDS “content profiles” applyAll XDS “content profiles” apply
25
XDM / XDR ScopeXDM / XDR Scope
Interchange of patient centered documentsInterchange of patient centered documents
Transmission of results, discharge letters or Transmission of results, discharge letters or patient referrals (not the "workflow" itself but patient referrals (not the "workflow" itself but all the medical information associated with - all the medical information associated with - e.g. reports, results, images, signals…)e.g. reports, results, images, signals…)
Personal Health Record medical information Personal Health Record medical information (history, etc), snapshots of clinical information (history, etc), snapshots of clinical information (medication list, immunization records, etc), (medication list, immunization records, etc), current observations from home care medical current observations from home care medical devices (e.g. blood pressure, blood sugar devices (e.g. blood pressure, blood sugar level, etc). level, etc).
Re-uses XDS approach for documentsRe-uses XDS approach for documents SubmissionSet, DocumentEntrySubmissionSet, DocumentEntry ebRS based XML meta-data w. limited extensionsebRS based XML meta-data w. limited extensions
Secure e-mail (ebMS over SMTP, S/MIME)Secure e-mail (ebMS over SMTP, S/MIME)
Optional on-line protocol (similar to XDS)Optional on-line protocol (similar to XDS)
PDI like media profile with XDS meta-dataPDI like media profile with XDS meta-data
Potential association of XDS and PDI at the actor Potential association of XDS and PDI at the actor level (Document Source…)level (Document Source…)
Further evolution possible for direct interchange Further evolution possible for direct interchange over web services (MTOM…) over web services (MTOM…)
27
XDM Diagram XDM Diagram
Portable Media Importer
Portable Media Creator
Distribute Document Set on Media [ITI-32]
28
XDM Actors and Options XDM Actors and Options
Actor Options Vol &Section
Portable Media Creator USB (Note 1) ITI TF-1:15.2.3
CD-R (Note 1) ITI TF-1:15.2.4
ZIP e-mail (Note 1) ITI TF-1:15.2.5
Portable Media Importer
USB (Note 1) ITI TF-1:15.2.3
CD-R (Note 1) ITI TF-1:15.2.4
ZIP e-mail (Note 1) ITI TF-1:15.2.5
Note 1: At least one of these options is required for each Actor.Note 1: At least one of these options is required for each Actor.
Multiple Documents Submission Option Multiple Documents Submission Option Offers the ability to include multiple documents in a single Offers the ability to include multiple documents in a single
Submission RequestSubmission Request
ZIP email Mode Option ZIP email Mode Option Offers the ability to send the set of documents to one unique Offers the ability to send the set of documents to one unique
recipient, using a ZIP over email. recipient, using a ZIP over email.
USB Option USB Option Portable Media Creator writes a set of documents on USB Portable Media Creator writes a set of documents on USB
mediamedia
CD-R Option CD-R Option Portable Media Creator writes a set of documents on CD-R Portable Media Creator writes a set of documents on CD-R
Multiple Documents Submission Option Multiple Documents Submission Option Offers the ability to include multiple documents in Offers the ability to include multiple documents in
a single Submission Requesta single Submission Request
On-Line Mode Option On-Line Mode Option Offers the ability to send the set of documents to Offers the ability to send the set of documents to
one unique recipient, using a HTTP web-service one unique recipient, using a HTTP web-service based on-line transmission mode. based on-line transmission mode.
Use of S/MIME encryption and signature for off-line network Use of S/MIME encryption and signature for off-line network transfer (integrity, privacy)transfer (integrity, privacy)
Encryption, with TLS authentication of both hosts, for on-Encryption, with TLS authentication of both hosts, for on-line transfers across secure domainsline transfers across secure domains
Actors need to protect themselves against confidentiality Actors need to protect themselves against confidentiality and integrity related risks and integrity related risks
XDM / XDR grouped with ATNA (access control/audit)XDM / XDR grouped with ATNA (access control/audit)
Import operations need to be further protected (hash and Import operations need to be further protected (hash and size to detect corruption with metadata assurance)size to detect corruption with metadata assurance)
Media must be securely managed (respect of privacy, Media must be securely managed (respect of privacy, proper identification, and corruption checking)proper identification, and corruption checking)
Additionally, parties are recommended to have a Additionally, parties are recommended to have a mutual agreement:mutual agreement: Management of Patient identification in order to avoid/limit Management of Patient identification in order to avoid/limit
identification errors. The metadata includes a patient id identification errors. The metadata includes a patient id shared by both the Document Source and the Document shared by both the Document Source and the Document Recipient as well as id and associated patient info as known Recipient as well as id and associated patient info as known by the Document Source.by the Document Source.
Measures taken to avoid/limit loss of email by using Measures taken to avoid/limit loss of email by using acknowledgements.acknowledgements.
Management of personnel and the organizations Management of personnel and the organizations identification and access control mechanisms.identification and access control mechanisms.
Codes set and vocabulary used enabling a consistent Codes set and vocabulary used enabling a consistent management of the metadata on both side.management of the metadata on both side.
In addition both organizations shall have mutually In addition both organizations shall have mutually acceptable audit trail mechanisms.acceptable audit trail mechanisms.
40September, 2005 What IHE Delivers
Cross Enterprise Sharing of Cross Enterprise Sharing of Scanned Documents (XDS-SD)Scanned Documents (XDS-SD)
IHE ITI Update Feb. 2007IHE ITI Update Feb. 2007
41
Cross Enterprise Sharing of Cross Enterprise Sharing of Scanned Documents (XDS-SD)Scanned Documents (XDS-SD)
A variety of legacy paper, film, electronic and scanner outputted formats are used to store and exchange clinical documents and do not have a uniform mechanism to store healthcare metadata associated with the documents, including patient identifiers, demographics, encounter, order or service information.
It is necessary to provide a mechanism that allows such source metadata to be stored with the document.
This profile defines how to couple such information, represented within a structured HL7 CDA R2 header, with a PDF or plaintext formatted document containing clinical information.
The content of this profile is intended for use in XDS, XDR and XDM. Content is created by a Content Creator and is to be consumed by a Content Consumer.
42
XDS-SD Value PropositionXDS-SD Value PropositionText Chart Notes Handwritten, typed or word processed clinical documents and/or chart
notes, typically multi-page, narrative text, including preprinted forms with handwritten responses, printed documents, and typed and/or word processed documents, and documents saved in various word processing formats.
Graphs, Charts and/or Line Drawings Growth Charts, Fetal Monitoring Graphs... best rendered using PDF versus
an image based compression, such as JPEG. When computer generated PDFs include lines, PDF vector encoding should be used.
Optical Character Recognition (OCR) Scanned Documents Clinical documents can contain text and annotations that cannot be fully
processed by optical character recognition (OCR), which may only partially represent the document content.
Electronic Documents Existing clinical documents that are electronically transmitted or software
created (e.g. PDF, or plaintext) can be considered as actually scanned, previously scanned or virtually scanned before they are shared.
43
XDS-SD Standards UsedXDS-SD Standards Used
Document Content Standards and Specifications PDF RFC 3778, The application/pdf Media Type PDF/A ISO 19005-1. Document management - Electronic
term preservation - Part 1: Use of PDF (PDF/A)
Wrapper Content Standards and Specifications HL7 CDA Release 2.0 (denoted HL7 CDA R2), or just IETF (Internet Engineering Task Force) RFC 3066
44
XDS-SD Meta-data creationXDS-SD Meta-data creationSource Type
Description
SA Source document Attribute – value is copied directly from source document. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible.
SAT Source document Attribute with Transformation – value is copied from source document and transformed. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible. Extended Discussion column must be ‘yes’ and the transform must be defined in the extended discussion
FM Fixed (constant) - for all source documents. Source/Value column contains the value to be used in all documents.
FAD Fixed by Affinity Domain – value configured into Affinity Domain, all documents will use this value. (Note: AD must be configurable along with the Document Source)
CAD Coded in Affinity Domain – a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
CADT Coded in Affinity Domain with Transform - a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
n/a Not Applicable – may be used with an optionally R2 or O attribute to indicate it is not to be used.
DS Document Source – value comes from the Document Source actor. Use Source/Value column or Extended Discussion to give details.
O Other – Extended Discussion must be ‘yes’ and details given in an Extended Discussion.
authorInstitution R2 7.1.5.2.1 SAT ClinicalDocument / author / assignedAuthor / representedOrganization / name, idThis attribute is the corresponding institution to the authorPerson below.
This supplement This supplement adds a single transactionadds a single transaction, , Stored QueryStored Query, , to the XDS Profileto the XDS Profile.. Stored Query is a Stored Query is a large improvement large improvement over the existing Queryover the existing Query Registry transaction since Registry transaction since it it removes the use of SQLremoves the use of SQL..
It minimizes the risks of undesired (SQL based) queries.It minimizes the risks of undesired (SQL based) queries.
This optimized query This optimized query simplifies implementationsimplifies implementation both on the both on the XDS Document Registry and XDS Document Consumer.XDS Document Registry and XDS Document Consumer.
It is functionally identical to the required subset of the It is functionally identical to the required subset of the existing Query Registry transaction [ITI-16], and it has been existing Query Registry transaction [ITI-16], and it has been decided to make this decided to make this new Stored Query mandatorynew Stored Query mandatory and the and the existing query optionalexisting query optional both onboth on the XDS Document the XDS Document RegistryRegistry and Document and Document ConsumerConsumer. .
51
Introducing some ebRS 3.0Introducing some ebRS 3.0
The simplification and optimization benefits realized outweigh The simplification and optimization benefits realized outweigh the few incompatible changes introduced by this approach:the few incompatible changes introduced by this approach: A few XML schema change introduced by the move from ebXML A few XML schema change introduced by the move from ebXML
Registry 2.x to 3.0 (e.g. name space)Registry 2.x to 3.0 (e.g. name space) Replacement of the SQL Query expression by a compact set of query Replacement of the SQL Query expression by a compact set of query
attributesattributesThe Provide and Register Document Set and Register The Provide and Register Document Set and Register transactions could have been upgraded to version 3.0 at the transactions could have been upgraded to version 3.0 at the same time. They were not upgraded for the following reasons: same time. They were not upgraded for the following reasons: Provide and Registry Document Set relies on Soap with Attachments. Provide and Registry Document Set relies on Soap with Attachments.
We anticipate upgrading this transaction to use MTOM once WS-I We anticipate upgrading this transaction to use MTOM once WS-I finishes its profiling work. When that work is done, we anticipate finishes its profiling work. When that work is done, we anticipate upgrading Provide and Register with both changes at one time.upgrading Provide and Register with both changes at one time.
The Register transaction should be upgraded at the same time as The Register transaction should be upgraded at the same time as Provide and Register.Provide and Register.
52
XDS Consumer and RegistryXDS Consumer and Registry
Actors Transactions Optionality Section in Vol. 2
Document Consumer
Query Registry O ITI TF-2:3.16
Retrieve Document R ITI TF-2:3.17
Registry Stored Query R (Note 4)
Document Registry
Register Document Set R (Note 2) ITI TF-2:3.14
Query Registry O ITI TF-2:3.16
Patient Identity Feed R ITI TF-2:3.8
Registry Stored Query R (Note 4)
Note 4: The Document Registry actor part of the Registry Stored Query transaction shall implement all queries defined by the Registry Stored Query transaction. No such minimum requirements are placed on the Document Consumer actor.
The ebXML Registry stored query facility The ebXML Registry stored query facility (Invoke Stored Query transaction) accepts (Invoke Stored Query transaction) accepts the following parameters:the following parameters: returnType – ‘returnType – ‘LeafClassLeafClass’ or ‘’ or ‘ObjectRefObjectRef’’ Query ID – a UUID from the Stored Query IDs Query ID – a UUID from the Stored Query IDs
section (3.18.4.1.2.4) belowsection (3.18.4.1.2.4) below Query Parameters – as defined in the Query Query Parameters – as defined in the Query
$XDSDocumentEntryStatus XDSDocumentEntry. status R M
58
Parameters encodingParameters encoding
AdhocQueryRequest ebRS operation with id corresponding to AdhocQueryRequest ebRS operation with id corresponding to « « FindDocumentsFindDocuments » »
ebRS “Slot” with name = “$XDSDocumentEntryebRS “Slot” with name = “$XDSDocumentEntryPatientId”PatientId”
123 - without quotes for numbers123 - without quotes for numbers
‘‘urn:oasis:names:tc:ebxml-regrep:StatusType:Approved’ - in urn:oasis:names:tc:ebxml-regrep:StatusType:Approved’ - in single quotes for strings.single quotes for strings.
‘‘Children’’s Hospital’ – a single quote is inserted in a string by Children’’s Hospital’ – a single quote is inserted in a string by specifying two single quotesspecifying two single quotes
Within the LIKE predicateWithin the LIKE predicate Underscore (‘_’) matches an arbitrary characterUnderscore (‘_’) matches an arbitrary character Percent (‘%’) matches an arbitrary stringPercent (‘%’) matches an arbitrary string
Format for multiple values isFormat for multiple values is (value, value, value, …) OR(value, value, value, …) OR (value) if only one value is to be specified.(value) if only one value is to be specified.
59
Introducing (real) Web ServicesIntroducing (real) Web Services<soap:Envelope ...> <soap:Header> <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff</wsa:MessageID> <wsa:To>http://fulfillerlocation/PRPA_AR101202</wsa:To> <wsa:Action>urn:oasis:names:tc:ebxml-