Direct XD* Envelop Metadata for
DS4P
Kathleen Connor VA (ESC)
February 2012
DIRECT Overview and XD*
• Direct Project includes support for trading partners
capable of exchanging and registering payloads
wrapped with XD* Metadata
• The XD* Metadata may be derived from the payload
• Some Metadata may be revealing of protected payload
information
• DS4P, Query Health, and Direct Projects should avoid
using Metadata that reveals what is intended to be
concealed from unauthorized users, including
intermediaries, while ensuring that appropriate routing
and patient matching information is available on the
envelope
XDR and XDM for Direct Messaging
• This specification discusses the application of XDR and XDM to the direct
messaging environment and the interaction between the primary Direct
Project environment, which uses SMTP and RFC 5322 to transport and
encode healthcare content, and the XDR and XDM specifications.
•
•
•
•
This specification defines:
Use of XD* Metadata with XDR and XDM in the context of directed
messaging
Additional attributes for XDR and XDM in the context of directed
messaging
Issues of conversion when endpoints using IHE XDR or XDM specifications
interact with endpoints utilizing SMTP for delivering healthcare content.
To view or edit the current wiki-text working version of the document,
click here
Version 1.0
2011-03-09
DIRECT Overview
XDR and XDM for Direct
Messaging Specification
Published
Download
CDA Annotated with XD* Data Sources
& Support for Privacy/Consent
Direct XD* Document Entry Metadata
•
This section lists the
metadata associated
with the content of the
message (called
document by IHE).
• The following table lists
each of the applicable
metadata elements, the
optionality specified in
the IHE XDS
specification and the
adjusted optionality
defined by the Minimal
Metadata specification.
• The table also gives a
few details regarding
conformance of the
value of the metadata
element
XDS Source
Minimal Metadata
Source
author
R2
R2
If supplied, MUST indicate the document's author, which may be different from the message sender
classCode
R
R2
When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2144 {see below}
confidentialityCod
e
R
R2
When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-150.
Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g.,
ETH, HIV, PSY, SDV)
creationTime
R
R2
Implementations MUST NOT use transaction-related dates/times, including the value of the RFC 5322
Date header
entryUUID
R
R
MUST be a unique value internal to this transaction, MAY be a symbolic or UUID form as per the XDS
Metadata specification
formatCode
R
R2
Implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-152, when the specific
listed codes apply
healthcareFacilityT R
ypeCode
R2
When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-146.
Implementations SHOULD populate mapped by configuration to sending organization {see below –
facilities related to protected conditions highlighted yellow}
languageCode
R
R2
Coded identifiers as described by the IETF (Internet Engineering Task Force) RFC 3066, conformant
with IHE requirements
mimeType
R
R
On conversion to/from MIME Entities, MUST contain the same media type as the applicable ContentType header for the entity
patientId
R
R2
Formatted as a HL7 CX as described in ITI TF-3 Table 4.1-3.
practiceSettingCo
de
R
R2
When available, implementations SHOULD draw from HITSP C80, version 2.0.1, table 2-149 which is a
list of members of the value set in table 2-148. {see below – practice settings related to protected
conditions highlighted yellow}
sourcePatientId
R
R2
Formatted as a HL7 CX as described in ITI TF-3 Table 4.1-3.
sourcePatientInfo
R2
R2
Formatted as defined in ITI TF-3 Table 4.1-5.
typeCode
R
R2
When available, implementations SHOULD draw values from HITSP C80, version 2.0.1, table 2-144
and SHOULD be the same value as classCode . {see below – type code possibly indicative of protected
conditions highlighted yellow}
uniqueId
R
R
Implementations SHOULD use a unique ID extracted from the content, if a single such value can be
determined. If not, implementations SHOULD use a UUID URN, generated for the transaction. This
value must be different from the uniqueId specified on the Submission Set.
Metadata
Attribute
Value Conformance
Direct XD*Submission Set Metadata
•
•
This section lists the metadata
associated with the set of
content of the message (called
submission set by IHE). Note
that IHE allows multiple
documents (content parts)
and this set of metadata
groups this set of documents
and gives metadata that is
common to all.
The following table lists each
of the applicable metadata
elements, the optionality
specified in the IHE XDS
specification and the adjusted
optionality defined by the
Minimal Metadata
specification. The table also
gives a few details regarding
conformance of the value of
the metadata element.
Attribut
e
XDS
Minimal
Sourc Metadata
e
Source
author
R2
Value Conformance
R
MUST indicate the message sender as a slot named
"authorTelecommunication". See Extensions. When
converted from an RFC 5322 message, MUST indicate the
value of the from header. Even though the authorPerson
slot is required by IHE, since authorTelecommunication is
valued the authorPerson may be omitted.
content R
TypeCo
de
R2
When available, implementations SHOULD draw from HITSP
C80, version 2.0.1, table 2-144
entryU
UID
R
R
MUST be a unique value internal to this transaction, MAY be
a symbolic or UUID form as per the XDS Metadata
specification
intende
dRecipi
ent
O
R
MUST indicate the message receivers. When converted from
RFC 5322, MUST carry the combined recipients.
Implementations SHOULD handle bcc consistent with the
relevant discussion in RFC 5322. See Extensions for how to
carry the Direct Address.
patientI
d
R
R2
MUST be identical to the Document Entry patientId
sourceI
d
R
R
Implementations SHOULD use a UUID URN mapped by
configuration to sending organization
submis R
sionTim
e
R
In cases of transformation from RFC 5322, implementations
SHOULD use the value of the Date header
title
O
O
It is RECOMMENDED that the Subject of the RFC 5322
message be put in this attribute
uniqueI
d
R
R
Implementations SHOULD use a unique ID extracted from the
content, if a single such value can be determined. If not,
implementations SHOULD use a UUID URN, generated for
the transaction. This value must be different than the uniqueId
specified on the Document.
XD* Metadata Derivation
Some XD* Wrapper and Document Set Metadata may be derived
from CDA Payload
• author: “If supplied, MUST indicate the document's author,
which may be different from the message sender”
• class, typeCode, and contentType codes
• uniqueID: “Implementations SHOULD use a unique ID extracted
from the content, if a single such value can be determined. If
not, implementations SHOULD use a UUID URN, generated for
the transaction. This value must be different from the uniqueId
specified on the Submission Set”
• healthcareFacilityTypeCode
• practiceSettingCode
• patientID
Problematic Metadata
• Some Metadata codes from HITSP reveal protected
information
– healthcareFacilityTypeCode
– practiceSettingCode
– classCode / typeCode
• Not clear that some of the XD* Metadata can be directly
derived from CDA
• Need guidance to ensure consistent approach to deriving
Metadata from payload (CDA and messages – e.g., X12 275
and Claims Attachment response to Payer for HITECH, HL7
v.2 Lab) to protect confidential information especially when
exchanged through an intermediary
Where Metadata is found in CDA Header
Author and Intended Recipient may
reveal protected information.
Recommend using more generic codes
for Role if necessary
Intended Recipient
Author
Document Type, Practice Setting, and Facility Type may reveal Protected Information
Recommend: Use more Generic codes for Protected Types
Document Class
Type – use
LOINC codes
from HITSP
value set
practiceSetting/Clini
cal Specialty is an
AssignedEntity Role
Code, which may
not map to HITSP
SNOMED value set
healthcareFacilityTypeCode –
uses HL7
ServiceDeliveryLocationRoleType,
Not HITSP C80 SNOMED value set
classCode / typeCode
• When available, implementations SHOULD
draw values from HITSP C80, version 2.0.1,
table 2-144
– Counseling note
• If value set extended, need to be aware that the
Document Class codes on Wrapper may reveal
protected information in payload
practiceSettingCode / Clinical Specialty
• This is the code representing the clinical specialty
of the clinician or provider who interacted with,
treated, or provided a service to/for the patient
• The value set used for clinical specialty has been
limited by HITSP to the value set reproduced
below in Table 2-149 Clinical Specialty Value Set
Definition
– Adult mental illness
– Psychiatry
– Psychotherapy
healthcareFacilityTypeCode
• When available, implementations SHOULD draw
values from HITSP C80, version 2.0.1, table 2-146.
Implementations SHOULD populate mapped by
configuration to sending organization
• Hospital-psychiatric
–
–
–
–
Hospital outpatient mental health center
Free-standing mental health center
Sexually transmitted disease health center
Substance abuse treatment center
Patient Information may be Confidential
Recommend: Limit Wrapper Metadata to minimum needed for accurate Patient Matching
Patient