Minimal XD* Metadata

Purpose

This page describes what metadata need to be present as a minimum in order to build a valid XDR or XDM package.
 
 

Background

The description of the metadata is in Volume 3 of the IHE ITI Technical Framework
 
 

How to Handle Required Metadata Elements

The following table includes ONLY required XD* Metadata elements, and discusses how a system could fill out the values when they don't exist in the system. Specifically this shows how one could derive the Metadata values from the content if that content is a HITSP C80.

Keith Boone has provided a primer on his blog, describing the XML structure of the metadata and providing a list of elements. The required elements are extracted and listed below (in an abstract form, the implementation details will be incorporated later). The rows with green background are values which can be defaulted automatically, if corresponding metadata is not available; the rows with blue background are based on configuration.

This specification assumes a use case in which the creator of the metadata may not have a trusted relationship with the NHIN Direct Source that created the clinical content. If no trust relationship exists between the two parties, the entity performing the metadata creation function may need to default in a number of fields, as listed below. If more specific metadata can be obtained, perhaps by extending the trust relationship or by moving the responsibility for metadata creation to the NHIN Direct Source itself, it should be used. As a guiding principle, the metadata should always try to represent reality to the most accurate extent possible, in order to allow the most sophisticated processing behavior at the receiving side.

Metadata Attribute	Description	Derivation Type	Possible Defaulted Value	For more information	Discussion
XDSDocumentEntry - metadata about each document
classCode	A code representing the kind of document.	D	56444-3(Healthcare Communication)	HITSP C80 Table 2-144	Optional: Most discussants preferred to omit classCode if it was not known Default: Some preferred to use 47049-2 (Communication) if a more specific value was not provided
confidentialityCode	A code representing the confidentiality of the document.	D	N(Normal)	HITSP C80 Table 2-151
creationTime	The date the communication was created, in yyyymmddhhmmss format. hhmmss is optional.	D	Current date and time
formatCode	A code representing the format of the document (if encrypted, the format of the original document).	D	urn:nhind:document:2010	HITSP C80 Table 2-153
hash	The SHA-1 hash of the document's text, calculated based on the current state of the document. (If the metadata creator receives an encrypted document, the hash is based on the encrypted document)			SHA-1 Hash
healthcareFacilityTypeCode	Determined based on the sender and configuration	C		HITSP C80 Table 2-147
languageCode	The language of the document.	D	en-US(US English)	RFC 4646
mimeType	The MIME type of the document (If the metadata creator receives an encrypted document, the MIME type refers to the type of the document before encryption.)			RFC 2046
patientId	The patient ID, as it is known by the recipient, if known.	D	A unique OID
practiceSettingCode	Determined based on the sender and configuration	C		HITSP C80 Table 2-149
size	Size of the document in bytes, calculated based on the current state of the document. (If the metadata creator receives an encrypted document, the size is based on the encrypted document.)
sourcePatientId	The patient's ID, as it is known by the source, if known. Otherwise, see patient ID.	D	A unique OID
typeCode	Same as classCode	D	56444-3(Healthcare Communication)	HITSP C80 Table 2-144
uniqueId	The document's Unique ID	D	2.25.dddddddddd (A generated UUID)	UUID Format
XDSSubmissionSet - metadata about the group of all documents in the message (NB: There may likely be just one document in the group)
author	This is where the From: address will be provided for transport-independent reference. When used in XDR, the From: address will also be presented in the SOAP Header, where it will be used for routing. The From: address will be in its own slot, called "telecommunications address" (optional extension to the IHE XD* metadata, requried when used in NHIN Direct). Other components of the author attribute are optional.
contentTypeCode	Same as DocumentEntry typeCode	D	56444-3 (Healthcare Communication)	HITSP C80 Table 2-144
intendedRecipient	This is where the To: address will be provided for transport-independent reference. When used in XDR, the To: address will also be presented in the SOAP Header, where it will be used for routing. The To: address, called "telecommunications address" will be added to the IHE specification (optional extension to the IHE XD* metadata, requried when used in NHIN Direct). Other components of the intended recipient are optional.
patientId	The patient ID, as it is known by the recipient, if known. See patientId above.	D	A unique OID
sourceId	OID identifying the instance of the Document Source that contributed the Submission Set. Can be a lookup, based on configuration and sender.	C	2.25.dddddddddd(From configuration)	UUID Format
submissionTime	The date the communication was created, in yyyymmddhhmmss format. hhmmss is optional.	D	Current date and time
uniqueId	The Submission Set Unique ID	D	2.25.dddddddddd (A generated UUID)	UUID Format

---

1. Type refers to whether this field can be defaulted, whether it is based on configuration, or whether it must be calculated for each document. D = Defaultable; C = Based on Configuration; Blank = Must be calculated.
2. These tables are present in the most recent version of the HITSP C80 specification (as of this writing, version 2.0.1). Version 2.0.1 only exists in PDF format; therefore, to find these tables, open the PDF and search.