430 likes | 565 Views
IHE-Europe Booth, World of Health IT, 2006. ITI - Overview of Cross Enterprise Document Sharing (XDS) and Related Profiles (XDR, XDM). Emmanuel CORDONNIER (ETIAM). User Requirements.
E N D
IHE-Europe Booth, World of Health IT, 2006 ITI - Overview of Cross Enterprise Document Sharing(XDS) and Related Profiles(XDR, XDM) Emmanuel CORDONNIER (ETIAM)
User Requirements • Beyond the inter-applications structured messages and informal textual interchanges between healthcare professionals, there is an increasing need for interchange of medical documents (structured or not) • Complementary to EHR managed by healthcare professionals inside care facilities (acute and ambulatory care), there is an emerging need for sharing medical documents among these professionals, and with the patient
Patient « envelope » approach • Electronic document is the intermediate object enabling to manage the link between non structured information (letters, dictated reports…) and the one managed inside medical databases (EHR) • A patient centric « envelope » approach enables to manage the documents interchange as well as their sharing, with an easy and structuring implementation
CD CD Merit-9 CD in Japan Clinic Hospital DICOM Images IHE-PDI Home care Lab/Hospital Doctors distribution MERIT-9
EDISanté « MMF/MXF » in France Textual Note or ASCII encoded message (HL7…) .txt Letter or Report with the presentation .rtf Structured document [with included files] (CDA…) .xml Other files, included into documents (XSLT…) Tile of medical images (DICOM) Vocal comment or physiological signal Envelope header: patient identity, documents description,author, sender, recipient… John Smith12/30/1957
Document Sharing • Before to address the EHR itself, the IHE community has decided to work on the cross-enterprise clinical document sharing • This document sharing IHE XDS Integration Profile is referenced in numerous emerging projects around the World, at different levels (healthcare centers and local / specialized / regional / state health networks)
Implementing IHE XDS in regional & national projects…Today FranceNational PHR Canada Infoway Austria MA-Share – MA IHIE – IN Mendicino - CA Denmark (Funen) Italy (Veneto) Spain (Aragon) IHE Interoperability Showcase ‘06 Italy (Conto CorrenteSalute) THINC- New York NCHICA – N. Carolina
Typically, a patient goes through a sequence of encounters in different Care Settings Long Term Care Acute Care (Inpatient) Other Specialized Care(incl. Diagnostics Services) GPs and Clinics (Ambulatory) Continuity of Care: Patient Longitudinal Record
community Hospital Record Laboratory Results Specialist Record Records Sent Clinical Encounter Finding the records of a patient-Manual & tedious The challenge: Finding and accessing easily documents from other care providers In the community. Clinical IT System
Sharing records that have been published community Hospital Record Laboratory Results Reference to records Specialist Record 4-Patient data presented to Physician Temporary Aggregate Patient History Index of patients records (Document-level) 3-Records Returned Clinical IT System Sharing System 2-Reference to Records for Inquiry 1-Patient Authorized Inquiry Clinical Encounter
Building and accessing Documents DocumentRepository Submission of Document References Retrieve of selected Documents Documents Registry EHR-LR:Longitudinal Recordas usedacross-encounters Long Term Care Acute Care (Inpatient) Other Specialized Careor Diagnostics Services PCPs and Clinics (Ambulatory) EHR-CR: Care Record systemssupporting care delivery
XDS – Value Proposition • Foundation for Health IT Infrastructures: Shared Electronic Health Record, in a community, region, etc. • Effective means to contribute and access clinical documents across health enterprises. • Scalable sharing of documents between private physicians, clinics, long term care, pharmacy, acute care with different clinical IT systems. • Easy access: Care providers are offered means to query and retrieve clinical documents of interest.
XDS - Value Proposition • Distributed: 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.
IHE XDS Integration Profile: Key Concepts • XDS Document • XDS Submission Set • XDS Folder
XDS : concepts Submission Folder Folder SubmissionSet Folder Document Document Document Documents server (registry-repository)
IHE XDS Integration Profile: Key Concepts XDS Document • A set of attested clinical information (structured or not) which form an element of a patient record to be shared. It may already exist within the source IT system. XDS Submission Set • A set of documents related to a patient that a (team of) clinician(s) in the same source system have decided to make available to potential consumers. XDS Folder A means to group documents for a number of other reasons: • Team work across several physicians, • Episode of care, • Emergency information for a patient, etc. XDS leaves open the use of folders to affinity domain clinicians.
XDS: standards used • ebXML Registry Services • SOAP with attachments et ebXML SOAP Messaging Services • Méta-data based on HL7 CDA with HL7 v2.5 content for ids (patient, prof/org) • On line (HTTP) or optional off-line (SMTP) submission of document • On-line (HTTP) SQL query with recent stored queries on Web Services
XDS: meta-data • Patient: Affinity domain id, demographics (id, name, birthdate…) « as viewed by the source » • Origin: (author, institution, validator) • Identification: (ID index, repositoryURI, unique id, dates of creation et start /end of medical act, title, size, hash, status, parent document) • Classification: (classe, type, format, MIME type, type and specialty ofinstitution and author, medical codes, confidentiality level) • Required, if known, generated by repository, Recommended
Consulting to referring physicians Specialist, Radio or Lab GP / PCP Doctor A Remote advice Hospital-doctor communication Patient Transfer Personal Health Record (PHR)to ED/Primary Care EMR Acute Care Dischargeto Extended Care Facility (ECF) Hospital Acute Care / ED Care Facility XDR / XDMUses Cases
XDR / XDM Value proposition • Complementary to sharing documents (XDS), point-to-point communication of documents • Both transports: secured mail & media (CD…) • As XDS, “document content agnostic” • Maximal re-use of XDS objects & meta-data • Compatible with exchange of images (PDI…) • All XDS “content profiles” apply
XDR / XDM Scope • Interchange of patient centered documents • Transmission of results, discharge letters or patient referrals (not the "workflow" itself but all the medical information associated with - e.g. reports, results, images, signals…) • Personal Health Record medical information (history, etc), snapshots of clinical information (medication list, immunization records, etc), current observations from home care medical devices (e.g. blood pressure, blood sugar level, etc).
XDR / XDM Key Technical Properties • Re-uses XDS approach for documents • SubmissionSet, DocumentEntry • ebRS based XML meta-data w. limited extensions • Secure e-mail (ebMS over SMTP, S/MIME) • Optional on-line protocol (similar to XDS) • PDI like media profile with XDS meta-data • Potential association of XDS and PDI at the actor level (Document Source…) • Further evolution possible for direct interchange over web services (MTOM…)
XDR Diagram Provide and Register Document Set [ITI-15] Document Source Document Recipient
Document Recipient XDR XDR Document Recipient Document Source XDR in conjunction with XDS Document Registry Document Repository Document Consumer Document Source XDS
Protocol encapsulation in SMTP/ESMTP SOAP with MIME attachments (multipart/related) text/xml SOAP:Envelope SOAP:Header, with Service=LifeCycleManager and Action=submitObjects Part1 (start) SOAP:Body, with Manifest=list of attachments (e.g. ebXML Reg. Msg + Documents) Part2 text/xml SubmitObjectRequest (ebXML Registry Message) Part3 Document 1 .. . Part n+2 Document n XDR off-line message
XDR Actors and Options Note 1: At least one of these options is required for each Actor.
XDR Integration Profile Options • Multiple Documents Submission Option • Offers the ability to include multiple documents in a single Submission Request • On-Line Mode Option • Offers the ability to send the set of documents to one unique recipient, using a HTTP web-service based on-line transmission mode.
Diagramme XDM Portable Media Creator Distribute Document Set on Media [ITI-32] Portable Media Importer
XDM Actors and Options Note 1: At least one of these options is required for each Actor.
XDM Integration Profile Options • Multiple Documents Submission Option • Offers the ability to include multiple documents in a single Submission Request • ZIP email Mode Option • Offers the ability to send the set of documents to one unique recipient, using a ZIP over email. • USB Option • Portable Media Creator writes a set of documents on USB media • CD-R Option • Portable Media Creator writes a set of documents on CD-R media.
XDM content: Additional PDI content: XDM combined with PDI
Security considerations (1) • Use of S/MIME encryption and signature for off-line network transfer (integrity, privacy) • Encryption, with TLS authentication of both hosts, for on-line transfers across secure domains • Actors need to protect themselves against confidentiality and integrity related risks • XDR / XDM grouped with ATNA (access control/audit) • Import operations need to be further protected (hash and size to detect corruption with metadata assurance) • Media must be securely managed (respect of privacy, proper identification, and corruption checking)
Security considerations (2) • Additionally, parties are recommended to have a mutual agreement: • Management of Patient identification in order to avoid/limit identification errors. The metadata includes a patient id shared by both the Document Source and the Document Recipient as well as id and associated patient info as known by the Document Source. • Measures taken to avoid/limit loss of email by using acknowledgements. • Management of personnel and the organizations identification and access control mechanisms. • Codes set and vocabulary used enabling a consistent management of the metadata on both side. • In addition both organizations shall have mutually acceptable audit trail mechanisms.