september, 2005what ihe delivers 1 iti – infrastructure update (xdm, xdr, xds-sd, xds stored...

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


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




19

Document Consumer

Retrieve Document

Query Documents

Patient Identity Source

Patient Identity Feed

Document Source

Document Registry

Document Repository




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


Cross-Enterprise Document Cross-Enterprise Document Reliable Interchange XDRReliable Interchange XDR

(and XDM)(and XDM)


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.


Cross Enterprise Sharing of Cross Enterprise Sharing of Scanned Documents (XDS-SD)Scanned Documents (XDS-SD)


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>


Registry Stored Query Registry Stored Query Transaction for XDS ProfileTransaction for XDS Profile


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



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"><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