Upload
cameo
View
79
Download
0
Tags:
Embed Size (px)
DESCRIPTION
IHE-Europe Workshop, Berlin, Feb.2007. ITI – Infrastructure Update (XDM, XDR, XDS-SD, XDS Stored Query). Emmanuel CORDONNIER (ETIAM). Cross-Enterprise Document Media Interchange XDM (and XDR). IHE ITI Update Feb. 2007. User Requirements. - PowerPoint PPT Presentation
Citation preview
1September, 2005 What IHE Delivers
ITI – Infrastructure UpdateITI – Infrastructure Update(XDM, XDR,(XDM, XDR,
XDS-SD,XDS-SD, XDS Stored Query) XDS Stored Query)
Emmanuel CORDONNIER (ETIAM)Emmanuel CORDONNIER (ETIAM)
IHE-Europe Workshop, Berlin, Feb.2007IHE-Europe Workshop, Berlin, Feb.2007
2September, 2005 What IHE Delivers
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
4
Patient « envelope » approachPatient « envelope » approach
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
5
HL7 Attachments (US claims)HL7 Attachments (US claims)
6
DICOM E-mail (started in Germany)DICOM E-mail (started in Germany)
7
Merit-9 CD in JapanMerit-9 CD in JapanHospital Clinic
Home care
CD CD
DICOMImages
Lab/HospitalDoctorsdistribution
IHE-PDI
MERIT-9
8
EDISanté « MMF/MXF » in FranceEDISanté « MMF/MXF » in France
.rtf
.txt
.xml
Letter or Report with the presentation
Textual Note or ASCII encoded message (HL7…)
Structured document [with included files] (CDA…)
Other files, included into documents (XSLT…)
Tile of medical images (DICOM)
Vocal comment or physiological signal
John Smith12/30/1957
Envelope header: patient identity, documents description,author, sender, recipient…
Envelope header: patient identity, documents description,author, sender, recipient…
9
Document SharingDocument Sharing
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
Documents Registry
DocumentRepository
EHR-LR:EHR-LR:Longitudinal RecordLongitudinal Recordas usedas usedacross-encountersacross-encounters
Submission of Document References
Retrieve of selected Documents
12
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 »
Origin:Origin: authorauthor, , institutioninstitution, legal authenticator, legal authenticator
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, ,
RecommendedRecommended
22
XDS / XDR / XDM Metadata Ex.XDS / XDR / XDM Metadata Ex.XDSDocumentEntry Attribute
Definition Source/Query
Data Type
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
classificationScheme= "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="theDocument" nodeRepresentation="classCode"><rim:Name>
<rim:LocalizedString value="classCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>Affinity Domain Specific Value</rim:Value> </rim:ValueList></rim:Slot>
</rim:Classification>
R/R XDS Affinity Domain specific
classCodeDisplayName
The name to be displayed for communicating to a human the meaning of the classCode.See classCode for example.
R/P XDS Affinity Domain specific
23
XDM / XDRXDM / XDR Uses CasesUses Cases
Specialist, Radio or LabGP / PCP Doctor A
Care Facility Hospital Acute
Care / ED
Patient TransferPatient Transfer
Personal Health Record (PHR)Personal Health Record (PHR)to ED/Primary Care EMRto ED/Primary Care EMR
Acute Care DischargeAcute Care Dischargeto Extended Care Facility (ECF)to Extended Care Facility (ECF)
Remote adviceRemote advice
Consulting to referring physicians Consulting to referring physicians
Hospital-doctorHospital-doctor communicationcommunication
24
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).
26
XDM / XDM / XDRXDR Key Technical Properties Key Technical Properties
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.
29
XDM Integration Profile OptionsXDM Integration Profile Options
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
media. media.
30
XDM media StructureXDM media Structure
Entry for the web content
Entries for the content the submissions sets
Other content not covered by the profile
XDS Metadata
Other file ignored by the metadata
Simple part document
Multi part document
XDS Metadata
Other file ignored by the metadata
Simple part document
Multi part document
Other part (file)
Start part (main file)
Other part (file)
Start part (main file)
31
XDM combined with PDIXDM combined with PDI
XDM content:XDM content:
Additional PDI content:Additional PDI content:
M
32September, 2005 What IHE Delivers
Cross-Enterprise Document Cross-Enterprise Document Reliable Interchange XDRReliable Interchange XDR
(and XDM)(and XDM)
IHE ITI Update Feb. 2007IHE ITI Update Feb. 2007
33
XDR DiagramXDR Diagram
Provide and Register Document Set [ITI-15]
Document Source Document Recipient
34
XDR in conjunction with XDSXDR in conjunction with XDS
Document Source
Document ConsumerDocument Repository
Document Registry
Document Recipient
XDR
Document Recipient
Document Source
XDR
XDS
35
XDR off-line messageXDR off-line messageProtocol encapsulation in SMTP/ESMTP
SOAP with MIME attachments (multipart/related)
text/xml SOAP:Envelope
SOAP:Header, with Service=LifeCycleManager and Action=submitObjects
SOAP:Body, with Manifest=list of attachments (e.g. ebXML Reg. Msg + Documents)
Part 1 (start)Part 1 (start)
text/xml SubmitObjectsRequest (ebXML Registry Message)Part 2Part 2
Document 1 Part 3Part 3
Document n
.
.
.
Part n+2Part n+2
36
XDR Actors and Options XDR Actors and Options
Actor Options Vol &Section
Document Source Multiple Document Submission
ITI TF-1:15.2.1
On-Line Mode ITI TF-1:15.2.2
Document Recipient On-Line Mode ITI TF-1:15.2.2
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.
37
XDR Integration Profile OptionsXDR Integration Profile Options
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.
38
XDM/R Security considerations (1)XDM/R Security considerations (1)
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)
39
XDM/R Security considerations (2)XDM/R Security considerations (2)
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.
45
XDS-SD Meta-data ExamplesXDS-SD Meta-data ExamplesXDSDoumentEntry
AttributeUsage
in XDS
Section number
Source Type
Source/ Value
authorInstitution R2 7.1.5.2.1 SAT ClinicalDocument / author / assignedAuthor / representedOrganization / name, idThis attribute is the corresponding institution to the authorPerson below.
authorPerson R2 7.1.5.2.1 SAT ClinicalDocument / author / assignedAuthor / id, ClinicalDocument / author / assignedAuthor / assignedPerson / name, id
authorRole R2 DS add value, if known
authorSpeciality R2 DS add value, if known
classCode R 7.1.5.2.2 SAT ClinicalDocument / code
classCodeDisplayName R 7.1.5.2.2 SAT ClinicalDocument / code @displayName
46
XDS-SD HL7-2.5 to HL7 CDAXDS-SD HL7-2.5 to HL7 CDAXDS Metadata HL7 CDA Header
HL7 v2.5 Data Type
Subcomponent index
Subcomponent name HL7 CDA R2 Data element
HL7 CDA R2 Subelement or attribute
XCN II and PN
1 Id number II @extension
2.1 FamilyName.surname PN family
3 Given Name PN given
4 Second (middle) Name PN given
5 Suffix PN suffix
6 Prefix PN prefix
9.1AssigningAuthority.namespace II @assigningAuthorityName
9.2 AssigningAuthority.uid II @root
47
XDS-SD Header ExampleXDS-SD Header Example
<ClinicalDocument xmlns=“urn:hl7-org:v3”> <typeId extension="POCD_HD000040"
root="2.16.840.1.113883.1.3"/> <id root=“1.3.6.4.1.4.1.2835.2.7777”/> <code code=“34133-9”
codeSystem=“2.16.840.1.113883.6.1” codeSystemName=“LOINC”displayName=“SUMMARIZATION OF EPISODE NOTE”/>
<title>Good Health Clinic Care Record Summary</title> <effectiveTime value=“20050329224411+0500”/> <confidentialityCode code="N"
codeSystem="2.16.840.1.113883.5.25"/> <languageCode code=“en-US”/>
48
XDS-SD Body ExampleXDS-SD Body Example
<component> <nonXMLBody> <text mediaType=“application/pdf”
representation=“B64”>JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB...RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAxMgolJUVPRgo=
</text> </nonXMLBody> </component></ClinicalDocument>
49September, 2005 What IHE Delivers
Registry Stored Query Registry Stored Query Transaction for XDS ProfileTransaction for XDS Profile
IHE ITI Update Feb. 2007IHE ITI Update Feb. 2007
50
XDS Stored Query OverviewXDS Stored Query Overview
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.
53
XDS: Updated DiagramXDS: Updated Diagram
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
Stored Query Documents
54
ebRS Transaction Parameters ebRS Transaction Parameters
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
Parameters section (3.18.4.1.2.3.7) belowParameters section (3.18.4.1.2.3.7) below
55
Query ListQuery ListFindDocumentsFindDocuments
FindSubmissionSetsFindSubmissionSets
FindFoldersFindFolders
GetAllGetAll
GetDocumentsGetDocuments
GetFoldersGetFolders
GetAssociationsGetAssociations
GetDocumentsAndAssociationsGetDocumentsAndAssociations
GetSubmissionSetsGetSubmissionSets
GetSubmissionSetAndContentsGetSubmissionSetAndContents
GetFolderAndContentsGetFolderAndContents
GetFoldersForDocumentGetFoldersForDocument
GetRelatedDocumentsGetRelatedDocuments
56
FindDocuments Parameters (1)FindDocuments Parameters (1)Parameter Name Attribute Opt Mult
$XDSDocumentEntryPatientId XDSDocumentEntry. patientId R --
$XDSDocumentEntryClassCode XDSDocumentEntry. classCode O M
$XDSDocumentEntryClassCodeScheme XDSDocumentEntry. classCode1 O2 M2
$XDSDocumentEntryPracticeSettingCodeXDSDocumentEntry. practiceSettingCode
O M
$XDSDocumentEntryPracticeSettingCodeScheme
XDSDocumentEntry. practiceSettingCode1
O2 M2
$XDSDocumentEntryCreationTimeFromLower value of XDSDocumentEntry. creationTime
O --
$XDSDocumentEntryCreationTimeToUpper value of XDSDocumentEntry. creationTime
O --
$XDSDocumentEntryServiceStartTimeFromLower value of XDSDocumentEntry. serviceStartTime
O --
$XDSDocumentEntryServiceStartTimeToUpper value of XDSDocumentEntry. serviceStartTime
O --
57
FindDocuments Parameters (2)FindDocuments Parameters (2)Parameter Name Attribute Opt Mult
$XDSDocumentEntryServiceStopTimeToUpper value of XDSDocumentEntry. serviceStopTime
O --
$XDSDocumentEntryHealthcareFacilityTypeCodeXDSDocumentEntry. healthcareFacilityTypeCode
O M
$XDSDocumentEntryHealthcareFacilityTypeCodeSchemeXDSDocumentEntry. healthcareFacilityTypeCode1
O2 M2
$XDSDocumentEntryEventCodeListXDSDocumentEntry. eventCodeList
O M
$XDSDocumentEntryEventCodeListSchemeXDSDocumentEntry. eventCodeList1
O2 M2
$XDSDocumentEntryConfidentialityCodeXDSDocumentEntry. confidentialityCode
O2 M2
$XDSDocumentEntryFormatCodeXDSDocumentEntry. formatCode
O M
$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-
regrep:xsd:query:3.0:StoredQuery</wsa:Action> ... </soap:Header> <soap:Body> <query:AdhocQueryRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"> <query:ResponseOption returnComposedObjects="true"
returnType="LeafClass"/> <rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"> <rim:Slot name="$XDSDocumentEntryPatientId"> <rim:ValueList>
<rim:Value>st3498702^^^&1.3…3.7&ISO</rim:Value> </rim:ValueList> </rim:Slot> </soap:Body></soap:Envelope>
60
XDS Stored Query WSDL ExampleXDS Stored Query WSDL Example<definitions name="StoredQuery"
targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns=http://schemas.xmlsoap.org/wsdl/ xmlns:tns="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/ xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <documentation>
</documentation> <types>
<xsd:schema elementFormDefault="qualified" targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:tns="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"><!-- Include query.xsd. --><xsd:include schemaLocation="../schema/query.xsd"/><xsd:element name="AdhocQueryRequest"/>
</xsd:schema> </types> <message name="StoredQuery_Message">
<part element="tns:AdhocQueryRequest" name="Body"/> </message> <message name="StoredQueryResponse_Message">
<part element="tns:AdhocQueryResponse" name="Body"/> </message>
61
www.ihe-europe.orgwww.ihe-europe.org