XDR/XDM Metadata

Current Work

Meetings

January 24, 2010

Agenda:

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

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.

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	No concerns.
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
patientId	R	R2
practiceSettingCode	R	R2
sourcePatientId	R	R2
sourcePatientInfo	R2	R2
typeCode	R	R2
uniqueId	R	R

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

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