Minimal XD* Metadata

From Direct Project
Jump to navigation Jump to search

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)

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.