XDR/XDM Metadata

Current Work

Use Case

Primary care provider refers patient to specialist

Dr. Smith is referring a patient to Dr. Jones. Dr. Smith’s referral coordinator uses her web e-communication application to write a textual summary of the referral and attaches a set of PDF formatted scanned documents. The textual summary and PDF documents are encrypted and signed by the application and emailed to Dr. Jones community email endpoint.

Dr. Jones' system is able to receive XDR SOAP messages and the community that Dr. Jones participates with has agree to provide a conversion mechanism from email submissions to XDR. Upon receipt of the email the community infrastructure will probably be able to decrypt the content but will not be able to automatically generate the metadata required for XDR.

Current situation Typically one of the following two approaches are used:

• For all required metadata which cannot be generated, a default value is defined by the community infrastructure and, possibly, communicated to Dr. Jones. Dr. Jones' system must understand this defaulted data and ensure that no misrepresentation of content results. For example, there is probably no patient identifier available. Since XDR specifies that the patient identifier should be known by the receiving system when an identifier arrives that is not known an appropriate workflow to handle this "default" value is needed. A similar set of special processing is needed for every case of a default being presented, which results in a non-interoperable system and a lot of custom coding for specific choices of defaults.
• The community defines is own set of required metadata, different than that specified by IHE. Dr. Jones' system must be adjusted for this level of requirement and make appropriate choices for processing input that is not conformant with the XDR standard.

Improved situation IHE defines a level of metadata conformance that is clearly articulated for uses such as this. The community adopts this level of metadata conformance for use in this use case and Dr. Jones ensures that his system supports this IHE specified level. When Dr. Jones receives the content it is processed consistent with the use case, generally requiring human intervention to support routing and integration. If Dr. Jones or the community did not want to support the requirement for human intervention the message could be rejected and that rejection communicated to the submitter.

Adjusting Metadata Requirements

Document Entry Metadata

The following table lists each Document Entry metadata element, the optionality specified in TF Vol. 3 as used by XDS and the suggested minimal optionality.

Metadata Attribute	XDS	Minimal	Discussion
author	R2	R2	No concerns.
classCode	R	R2	Supports environments where content is provided without context, for example a PDF document or a patient's document as patients do not understanding coding systems. Could consider a well-known class code which identifies the entry as a "directed" entry.
confidentialityCode	R	R2	Only useful when the data stays within a privacy domain. When it crosses domains a translation/interpretation is needed and the value may not be useful in this context. If there is no common vocabulary it can't be interpreted. Generic problem: whenever XDS specified the XDS Affinity Domain must define the use, for XDR there may be no agreement so it is hard to specify codes. Consider specifying a "generic" set to be used as in cases where no agreed code set exists. Would still need to use R2.
creationTime	R	R2	If the creation time of the document is unknown it is better to specify nothing than use a value that is misleading.
entryUUID	R	R	Intervening portal generates this as part of generating the XDR/XDM message
formatCode	R	R2	Diferentiating is available in mimeType and if there is no greater knowledge about the content then this element should be unspecified.
healthcareFacilityTypeCode	R	R2	Have a package level "from" indicator. The cost of doing this on the sender is very easy, low cost, and some value on the receiver, not the most significant one but since it is easy to send and has some value.
languageCode	R	R2	C80 points to IETF 4646 which has a value for "undetermined" and could use this for this case.
mimeType	R	R	Agreed to keep required, ebRIM does not require this but it is very valuable and easy to create
patientId	R	R2	Definition requires XDS affinity domain, not applicable to XDR environment. In XDM no ability to create an environment of agreement, still have some sort of agreement. XDR/XDM environment: the patient identifier as known by the recipient. If a patient identifier known by the recipient is not available no value is specified. Should we give any guidance if more than one identifier known by the recipient is available. IHE can acknowedge this environment and give no guidance on which to use.
practiceSettingCode	R	R2
sourcePatientId	R	R2
sourcePatientInfo	R2	R2
typeCode	R	R2
uniqueId	R	R	Intervening portal generates this value

Submission Set Metadata

This section lists the metadata associated with the submission set.

Metadata Attribute	XDS	Minimal	Discussion
author	R2	R
contentTypeCode	R	R2
entryUUID	R	R
intendedRecipient	O	R
patientId	R	R2
sourceId	R	R
submissionTime	R	R
title	O	O
uniqueId	R	R

Documenting Metadata

As part of this project we should consider adjusting the way that metadata is presented in volume 3. A suggestion is to have a simplified table which references sections that hold details about each metadata attribute:

Metadata Attribute	Description	Data Type	Details
Common name of the attribute	One sentence description of the attribute.	Format of content of the attribute	Link to section holding details about the attribute

Each detailed section would have a similar format, something like this:

4.1.7.n <Attribute Name>
Description:
Coding:

• Coding in Provide & Register and Register Transactions
• Coding in Query Request
• Coding in Query Response

Required Use:

• Requirements in use in XDS
• Requirements in use in XCA
• Requirements in use in XDR
• Requirements in use in XDM

References:

Example

Metadata Attribute	Description	Data Type	Details
author	Represents the humans and/or machines that authored the document.	ebRIM Classification	Section 4.1.7.1 author
creationTime	Represents the time the author created the document in the Document Source.	DTM	Section 4.1.7.8 creationTime

4.1.7.1 author

The following is copied verbatim from the TF Vol. 3 metadata table
Represents the humans and/or machines that authored the document. This attribute contains the following sub-attributes:

• authorInstitution
• authorPerson
• authorRole
• authorSpecialty

which are individually defined below.

The author attribute is defined as a Classification which contains the above sub-attributes. The author attribute itself does not have a simple value. It defines a structure to hold its sub-attributes. An instance of this Classification shall be considered a single value of the author attribute. If present, the author attribute shall have one or more values. Each instance of this Classification shall contain:

• One instance of the authorPerson sub-attribute
• Zero or more instances of the authorInstitution sub-attribute
• Zero or more instances of the authorRole sub-attribute
• Zero or more instances of the authorSpecialty sub-attribute

etc..... Notes: This section would probably have subsections for authorInstitution, authorPerson, author Role and authorSpecialty. It also needs to address coding within submissions, queries and query response and requirements also in those transactions"

4.1.7.8 creationTime

Description:Represents the time the author created the document in the Document Source. Shall have a single value.
Coding:

• Coding in Provide & Register and Register Transactions - coded as a single value within a Slot in the DocumentEntry.

Example:

<rim:Slot name="creationTime">
	<rim:ValueList>
		<rim:Value>20041225212010</rim:Value>
	</rim:ValueList>
</rim:Slot>

• Coding in Query Request - coded as a single value within the $XDSDocumentEntryCreationTimeFrom and $XDSDocumentEntryCreationTimeTo Slots on selected stored queries.

Example - to specify a creation time range of 200412252300 to 200501010800:

<rim:Slot name="$XDSDocumentEntryCreationTimeFrom">
	<rim:ValueList>
		<rim:Value>200412252300</rim:Value>
	</rim:ValueList>
</rim:Slot>
<rim:Slot name="$XDSDocumentEntryCreationTimeTo">
	<rim:ValueList>
		<rim:Value>200501010800</rim:Value>
	</rim:ValueList>
</rim:Slot>

• Coding in Query Response - same as Provide & Register and Register Transactions

Required Use:

• Requirements in use in XDS - Required in submission, optional in some stored query requests, required in query response.
• Requirements in use in XCA - Optional in some stored query requests, required in query response
• Requirements in use in XDR - Required if available
• Requirements in use in XDM - Required if available

Required Use: (alternative presentation

Profiles	Transactions	Request	Response	Details
XDS	ITI-41 Provide & Register ITI-42 Register	Required	N/A	Required on submission
XDS	ITI-18 Registry Stored Query	Optional on selected stored queries	Required	Not Applicable on stored queries without Patient ID
XDR	ITI-41 Provide & Register	Required if available	N/A	Requirement based on XDR use case
XDM	ITI-32 Distribute Document set on Media	Required if available	N/A	Requirement based on XDM use case
XCA	ITI-38 Cross Gateway Query	Optional on selected stored queries	Required	Not Applicable on stored queries without Patient ID

Meetings

January 24, 2010

Agenda:

• Review use case.
• Continue review of metadata and documenting in "discussion" column.
• Review example of use of format for Documenting Metadata.

Minutes:

• Reviewed use case
  • Add to context of use case explaining the limitations of the sender - sender can do authentication but not metadata. Limitations of sender puts the burden on the receiver to manually understand the contents sufficiently to properly handle it. Receiver accepts this burden because of the value of the data from sender.
  • Include that the body of the email also becomes and attachment that must be processed
  • Add second use case showing a referral where the recevier does not know the patient yet so no patient id can be specified. Use of other fields like sourcePatientID and sourcePatientInfo contain the data needed by receiver to set up the patient record to hold the referall.
  • Add an XDM specific use case, especially the email option.
  • Discuss integration with XDS, that in order to integrate into an XDS environment metadata must get generated
• General discussion
  • Describe the enhancements to submission set author and intendedREcipeient CP 524.
  • Open Issue: Is a flag needed to communicate to receiver that minimal metadata has been specified. If yes, what should the flag be. Suggestions of useing objectType or a SOAP level flag.
  • Open Issue: Is minimal metadata an option in XDR and XDM. Also considered just downgrading the XDR/XDM actor handling of metadata.
• Review example metadata documentation
  • Need to consider metadata update and registry stored query repurcussions
• Reviewed patientID metadata attributue

December 16, 2010

Agenda:

• Review U.S. Direct Project XDR and XDM for Direct Messaging
• Review Documenting Metadata

Minutes:

• The use case needs to be well documented. Explain difference between directed exchange and sharing through a registry, these differences result in differences in needs of metadata. Express the requirements based on use case and minimal/maximal metadata concepts.
• Reviewed author, classCode, confidentialityCode, creationTime, entryUUID, healthcareFacilityTypeCode, languageCode and documented in "discussion" column.
• Write up a couple examples of the Documenting Metadata format for review.

References:

• ITI TF-3:3.18.4.1.2.3.7.1

Regional/National Projects

Here is a list of projects around the world that make use of XDR and/or XDM

• U.S. Direct Project - XDR and XDM for Direct Messaging
• Australia - SMD/XDR/XDS harmonization
• Continua
• epSOS

Proposal Documents

• Brief Proposal
• Brief Proposal Presenation
• Detailed Proposal
• Detailed Proposal Presentation