ITI Infrastructure Update XDM, XDR, XDSSD, XDS Stored Query

1
ITI Infrastructure Update(XDM, XDR,XDS-SD,
XDS Stored Query)
IHE-Europe Workshop, Berlin, Feb.2007

• Emmanuel CORDONNIER (ETIAM)

2
Cross-Enterprise Document Media Interchange
XDM(and XDR)

• IHE ITI Update Feb. 2007

3
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

4
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

5
HL7 Attachments (US claims)
6
DICOM E-mail (started in Germany)
7
Merit-9 CD in Japan
Clinic
Hospital
DICOM Images
IHE-PDI
Home care
Lab/Hospital Doctors distribution
MERIT-9
8
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
9
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)

10
Implementing IHE XDS in regional national
projectsToday
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
11
Building and accessing Documents
Documents Registry
EHR-LRLongitudinal Recordas usedacross-encount
ers
Long Term Care
Acute Care (Inpatient)
Other Specialized Careor Diagnostics Services
PCPs and Clinics (Ambulatory)
EHR-CR Care Record systemssupporting care
delivery
12
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.

13
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.

14
XDS Key Concepts

• XDS Document
• XDS Submission Set
• XDS Folder

15
XDS concepts
Submission
Folder
SubmissionSet
Folder
Folder
Document
Document
Document
Documents server (registry-repository)
16
XDS 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.

17
XDS Diagram
18
XDS Diagram
19
XDS Diagram
20
XDS standards used

• ebXML Registry Services
• SOAP with attachments and ebXML SOAP Messaging
  Services
• Meta-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

21
XDS meta-data

• Patient Affinity domain id, demographics (id,
  name, birth date)  as viewed by the source 
• Origin author, institution, legal authenticator
• Identification ID index, repository URI, unique
  id, dates of creation and start /end of medical
  act, title, size, hash, status, parent document
• Classification class, type, format, MIME type,
  type and specialty of institution and author,
  medical codes, confidentiality level
• Required, If known, Generated by repository,
  Recommended

22
XDS / XDR / XDM Metadata Ex.
23
XDM / XDR Uses Cases
24
XDM / XDR 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

25
XDM / XDR 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).

26
XDM / XDR 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)

27
XDM Diagram
Portable Media Importer
Portable Media Creator
Distribute Document Set on Media ITI-32 ?
28
XDM Actors and Options
Note 1 At least one of these options is required
for each Actor.
29
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.

30
XDM media Structure
31
XDM combined with PDI

• XDM content

• Additional PDI content

32
Cross-Enterprise Document Reliable Interchange
XDR(and XDM)

• IHE ITI Update Feb. 2007

33
XDR Diagram
Provide and Register Document Set ITI-15 ?
Document Source
Document Recipient
34
XDR in conjunction with XDS
Document Registry
Document Consumer
Document Repository
Document Source
XDS
35
XDR off-line message
36
XDR Actors and Options
Note 1 At least one of these options is required
for each Actor.
37
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.

38
XDM/R 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
• XDM / XDR 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)

39
XDM/R 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.

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

• IHE ITI Update Feb. 2007

41
Cross Enterprise Sharing of 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 Proposition

• Text 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 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 creation
45
XDS-SD Meta-data Examples
46
XDS-SD HL7-2.5 to HL7 CDA
47
XDS-SD Header Example

• ltClinicalDocument xmlnsurnhl7-orgv3gt
• lttypeId extension"POCD_HD000040"
  root"2.16.840.1.113883.1.3"/gt
• ltid root1.3.6.4.1.4.1.2835.2.7777/gt
• ltcode code34133-9 codeSystem2.16.840.1.11
  3883.6.1
• codeSystemNameLOINC
• displayNameSUMMARIZATION OF EPISODE NOTE/gt
• lttitlegtGood Health Clinic Care Record
  Summarylt/titlegt
• lteffectiveTime value200503292244110500/gt
• ltconfidentialityCode code"N"
  codeSystem"2.16.840.1.113883.5.25"/gt
• ltlanguageCode codeen-US/gt

48
XDS-SD Body Example

• ltcomponentgt
• ltnonXMLBodygt
• lttext mediaTypeapplication/pdf
  representationB64gt
• JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIF
  IvRmlsdGVyIC9GbGF0
• ZURlY29kZT4CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr
  0GQqFbg7fQoSRNWuhB
• ...
• RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0YXQoPg
  pzdGFydHhyZWYKMzAx
• MgolJUVPRgo
• lt/textgt
• lt/nonXMLBodygt
• lt/componentgt
• lt/ClinicalDocumentgt

49
Registry Stored Query Transaction for XDS Profile

• IHE ITI Update Feb. 2007

50
XDS Stored Query Overview

• This supplement adds a single transaction, Stored
  Query, to the XDS Profile. Stored Query is a
  large improvement over the existing Query
  Registry transaction since it removes the use of
  SQL.
• It minimizes the risks of undesired (SQL based)
  queries.
• This optimized query simplifies implementation
  both on the XDS Document Registry and XDS
  Document Consumer.
• It is functionally identical to the required
  subset of the existing Query Registry transaction
  ITI-16, and it has been decided to make this
  new Stored Query mandatory and the existing query
  optional both on the XDS Document Registry and
  Document Consumer.

51
Introducing some ebRS 3.0

• The simplification and optimization benefits
  realized outweigh the few incompatible changes
  introduced by this approach
• A few XML schema change introduced by the move
  from ebXML Registry 2.x to 3.0 (e.g. name space)
• Replacement of the SQL Query expression by a
  compact set of query attributes
• The Provide and Register Document Set and
  Register transactions could have been upgraded to
  version 3.0 at the same time. They were not
  upgraded for the following reasons
• Provide and Registry Document Set relies on Soap
  with Attachments. We anticipate upgrading this
  transaction to use MTOM once WS-I finishes its
  profiling work. When that work is done, we
  anticipate upgrading Provide and Register with
  both changes at one time.
• The Register transaction should be upgraded at
  the same time as Provide and Register.

52
XDS Consumer and Registry
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 Diagram

Patient
Identity Source

Patient Identity
Feed

Document
Document
Consumer

Registry

Stored Query
Documents
Register


Document Set

Retrieve
ProvideRegister

Document

Document Se
t

Document
Document
Repository

Source


54
ebRS Transaction Parameters

• The ebXML Registry stored query facility (Invoke
  Stored Query transaction) accepts the following
  parameters
• returnType LeafClass or ObjectRef
• Query ID a UUID from the Stored Query IDs
  section (3.18.4.1.2.4) below
• Query Parameters as defined in the Query
  Parameters section (3.18.4.1.2.3.7) below

55
Query List

• FindDocuments
• FindSubmissionSets
• FindFolders
• GetAll
• GetDocuments
• GetFolders
• GetAssociations
• GetDocumentsAndAssociations
• GetSubmissionSets
• GetSubmissionSetAndContents
• GetFolderAndContents
• GetFoldersForDocument
• GetRelatedDocuments

56
FindDocuments Parameters (1)
57
FindDocuments Parameters (2)
58
Parameters encoding

• AdhocQueryRequest ebRS operation with id
  corresponding to  FindDocuments 
• ebRS Slot with name XDSDocumentEntryPatientI
  d
• 123 - without quotes for numbers
• urnoasisnamestcebxml-regrepStatusTypeApprov
  ed - in single quotes for strings.
• Childrens Hospital a single quote is
  inserted in a string by specifying two single
  quotes
• Within the LIKE predicate
• Underscore (_) matches an arbitrary character
• Percent () matches an arbitrary string
• Format for multiple values is
• (value, value, value, ) OR
• (value) if only one value is to be specified.

59
Introducing (real) Web Services

• ltsoapEnvelope ...gt
• ltsoapHeadergt
• ltwsaMessageIDgtuuidaaaabbbb-cccc-dddd-eeee-fffff
  ffffffflt/wsaMessageIDgt
• ltwsaTogthttp//fulfillerlocation/PRPA_AR101202
  lt/wsaTogt
• ltwsaActiongturnoasisnamestcebxml-regrepxs
  dquery3.0StoredQuerylt/wsaActiongt
• ...
• lt/soapHeadergt
• ltsoapBodygt
• ltqueryAdhocQueryRequest
• xmlnsxsi"http//www.w3.org/2001/XMLSchema-inst
  ance"
• xmlnsquery"urnoasisnamestcebxml-regrepxs
  dquery3.0"
• xmlnsrim"urnoasisnamestcebxml-regrepxsd
  rim3.0"
• xmlnsrs"urnoasisnamestcebxml-regrepxsdr
  s3.0"gt
• ltqueryResponseOption returnComposedObjects"t
  rue" returnType"LeafClass"/gt
• ltrimAdhocQuery id"urnuuid14d4debf-8f97-425
  1-9a74-a90016b0af0d"gt
• ltrimSlot name"XDSDocumentEntryPatientId
  "gt
• ltrimValueListgt
  ltrimValuegtst3498702amp1.33.7ampISOlt/rim
  Valuegt
• lt/rimValueListgt
• lt/rimSlotgt

60
XDS Stored Query WSDL Example

• ltdefinitions name"StoredQuery"
  targetNamespace"urnoasisnamestcebxml-regrepx
  sdquery3.0" xmlnshttp//schemas.xmlsoap.org/wsd
  l/ xmlnstns"urnoasisnamestcebxml-regrepxsd
  query3.0" xmlnssoaphttp//schemas.xmlsoap.org/w
  sdl/soap/ xmlnsxsd"http//www.w3.org/2001/XMLSch
  ema" xmlnswsa"http//schemas.xmlsoap.org/ws/2004
  /08/addressing"gt ltdocumentationgt
• lt/documentationgt
• lttypesgt
• ltxsdschema elementFormDefault"qualified"
  targetNamespace"urnoasisnamestcebxml-regrep
  xsdquery3.0"
• xmlnstns"urnoasisnamestcebxml-regrepxsdq
  uery3.0"gt
• lt!-- Include query.xsd. --gt
• ltxsdinclude schemaLocation"../schema/query.xsd
  "/gt
• ltxsdelement name"AdhocQueryRequest"/gt
• lt/xsdschemagt
• lt/typesgt
• ltmessage name"StoredQuery_Message"gt
• ltpart element"tnsAdhocQueryRequest"
  name"Body"/gt
• lt/messagegt
• ltmessage name"StoredQueryResponse_Message"gt
• ltpart element"tnsAdhocQueryResponse"
  name"Body"/gt
• lt/messagegt

61
www.ihe-europe.org