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[1] |
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[2] |
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) |
||
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) |
- 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.
- 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.