XDR/XDM Metadata
Proposed Supplement Contents
Introduction
This supplement adjusts the requirements of metadata attributes when used in an XDR or XDM context. This adjustment is useful in environments where an XDS Affinity Domain concept does not exist. In order for the content exchanged using these adjusted metadata attributes requirements to be integrated into an XDS environment, generation of additional metadata is likely.
NOTE: Once open issues are resolved more content can be added here.
Open Issues
- (1) Is an indicator needed to communicate to receiver that minimal metadata has been specified? If yes, what how should the indicator be specified? Suggestions for reflecting the different levels of metadata include a) use of objectType on document entry (note that effects submission set as well) b) use of SOAP header level element to warn receiver prior to processing the message contents.
- (2) Is minimal metadata an option in XDR and XDM. Also considered just downgrading the XDR/XDM actor handling of metadata.
- (3) Should a new method of documenting metadata be addressed as part of this work effort? If yes, how should this documentation change be reflected? Suggestion that two supplements be released for public comment, one containing only documentation updates, the second contains the change to technical requirements on metadata used in XDR/XDM. The second would be written assuming the first had been accepted. After public comment, assuming general agreement on the change in documentation style, the first supplement would be integrated directly into final text and the second continue as a Trial Implementation supplement.
- (4) Does sourcePatientID allow more than one element? Documentation states there can only be one slot by this name - silly thing to say. Probably should open a CP to resolve this question.
- (5) Should we adopt the Direct Project enhancements to submission set metadata for author and intendedRecipient to add an XTN value holding sender and recipient email addresses? CP 524 submitted on this issue.
Use Cases
Primary care provider refers patient to specialist
Dr. Primary is referring a patient to Dr. Specialist. Dr. Primary works in a single physician practice which has limited technology which is not yet well integrated. Dr. Specialist works in a fully integrated environment, with an EMR that can automatically process incoming data and present it in the most effective way. Dr. Specialist's EMR accepts XDR transactions but is not enabled to accept and process e-mail. Because Dr. Primary, and single physical practices like his, are a source of a significant number of referrals for Dr. Specialist, the ability to translate from e-mail to XDR is valuable to Dr. Specialist. In this case, this capability is provided by a state level organization, which accepts e-mail messages on behalf of its participants and converts them to XDR transactions for delivery to EMR's in the state.
To send a referral, Dr. Primary's referral coordinator uses an e-mail application to write a textual summary of the referral and attaches a set of PDF formatted scanned documents. The textual summary and PDF documents are encrypted and signed by the application and mailed to Dr. Specialist's e-mailed address. Dr. Specialist's e-mail address was provided by the state organization and the e-mail is received by the state's e-mail server. This state e-mail server application converts the e-mail into an XDR message, where the text of the e-mail is one of the documents being sent. Then an XDR transaction is sent to Dr. Specialist's EMR which accepts the content for processing. The state e-mail server application will be able to decrypt the content but will not be able to automatically generate the metadata required for XDR.
Current situation Typically one of the following two approaches are used:
- For all required metadata which cannot be generated, a default value is defined by the state organization infrastructure and, possibly, communicated to Dr. Specialist. Dr. Specialist' EMR must understand this defaulted data and ensure that no misrepresentation of content results. For example, there is probably no patient identifier available. Since XDR specifies that the patient identifier should be known by the receiving system when an identifier arrives that is not known an appropriate workflow to handle this "default" value is needed. A similar set of special processing is needed for every case of a default being presented, which results in a non-interoperable system and a lot of custom coding for specific choices of defaults.
- The community defines is own set of required metadata, different than that specified by IHE. Dr. Specialist's EMR must be adjusted for this level of requirement and make appropriate choices for processing input that is not conformant with the XDR standard.
Improved situation IHE defines a level of metadata conformance that is clearly articulated for uses such as this. The community adopts this level of metadata conformance for use in this use case and Dr. Specialist ensures that his system supports this IHE specified level. When Dr. Specialist receives the content it is processed consistent with the use case, generally requiring human intervention to support routing and integration. If Dr. Specialist or the state organization did not want to support the requirement for human intervention the message could be rejected and that rejection communicated to the submitter.
This use case demonstrates a situation where the sender, Dr. Primary, has limited technical capabilities and as a result the receiver, in this case Dr. Specialist, has a greater responsibility in compensating for missing capability of the sender. Dr. Specialist has chosen to accept content that will likely require manual intervention to properly integrate it into his EMR. In addition, Dr. Specialist will have chosen an EMR which supports this manual intervention.
Specialist refers patient to hospital
After review of the patient referral, Dr. Specialist decides that this patient needs immediate hospitalization and refers the patient to Mercy Hospital which specializes in the patients condition. Since the patient has never been to Mercy Hospital there is no patient record or patient identifier known to Mercy Hospital. Dr. Specialist's system includes the patient demographics in the XDR message sent to Mercy Hospital but cannot include a patient identifier that is useful at the destination. Mercy Hospital uses the patient demographics included in the XDR message to create the patient record and store the incoming data in that patient record. When the patient arrives at Mercy the information is available to begin immediate treatment.
Primary care provider refers patient to unknown specialist
Dr. Primary recommends the patient see a specialist, but allows the patient to choose her own specialist. Dr. Primary provides the patient with her records in XDM format on a CD. Since Dr. Primary cannot know what specialist will receive the records, much of the metadata required by XDM cannot be specified. In particular, patient identifiers will likely not be useful but patient demographics especially important. Coded values may be less useful as receivers understanding of Dr. Primary's code sets is unknown.
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. |
| availabilityStatus | Cg | N/A | Not applicable to XDR or XDM transactions |
| 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. |
| comments | O | O | |
| 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 | Intervening portal generates this as part of generating the XDR/XDM message |
| eventCodeList | O | O | |
| formatCode | R | R2 | Diferentiating is available in mimeType and if there is no greater knowledge about the content then this element should be unspecified. |
| hash | Cp | O | |
| 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. |
| homeCommunityId | Cx | O | |
| languageCode | R | R2 | C80 points to IETF 4646 which has a value for "undetermined" and could use this for this case. |
| legalAuthenticator | O | O | |
| mimeType | R | R | Agreed to keep required, ebRIM does not require this but it is very valuable and easy to create |
| patientId | R | R2 | Definition requires XDS affinity domain, not applicable to XDR environment. In XDM no ability to create an environment of agreement, still have some sort of agreement. XDR/XDM environment: the patient identifier as known by the recipient. If a patient identifier known by the recipient is not available no value is specified. Should we give any guidance if more than one identifier known by the recipient is available. IHE can acknowedge this environment and give no guidance on which to use. |
| practiceSettingCode | R | R2 | |
| repositoryUniqueId | Cp | N/A | Not applicable to XDR or XDM transactions |
| serviceStartTime | R2 | O | |
| serviceStopTime | R2 | O | |
| size | Cp | O | |
| sourcePatientId | R | R2 | |
| sourcePatientInfo | O | R2 | |
| title | O | O | |
| typeCode | R | R2 | |
| uniqueId | R | R | Intervening portal generates this value |
| URI | O | O | Used by XDM maybe? |
Submission Set Metadata
This section lists the metadata associated with the submission set.
| Metadata Attribute | XDS | Minimal | Discussion |
|---|---|---|---|
| author | R2 | R | Extension to author attribute: defines new subattribute authorTelecommunication which is a single valued slot within author. The single slot value is an XTN data type string. See the example from the Direct Project. Example of XTN format is "^^Internet^drsmith@direct.example.org". |
| availabilityStatus | Cg | N/A | Not applicable to XDR or XDM transactions |
| comments | O | O | |
| contentTypeCode | R | R2 | |
| entryUUID | R | R | |
| homeCommunityId | Cx | O | |
| intendedRecipient | O | R | XCN|XTN. XTN hold the email address of the intended recipient, if available. See the example from the Direct Project. See author for an example of the XTN format. |
| 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 |
Meetings
January 24, 2010
Agenda:
- Review use case.
- Continue review of metadata and documenting in "discussion" column.
- Review example of use of format for Documenting Metadata.
Minutes:
- Reviewed use case
- Add to context of use case explaining the limitations of the sender - sender can do authentication but not metadata. Limitations of sender puts the burden on the receiver to manually understand the contents sufficiently to properly handle it. Receiver accepts this burden because of the value of the data from sender.
- Include that the body of the email also becomes and attachment that must be processed
- Add second use case showing a referral where the recevier does not know the patient yet so no patient id can be specified. Use of other fields like sourcePatientID and sourcePatientInfo contain the data needed by receiver to set up the patient record to hold the referall.
- Add an XDM specific use case, especially the email option.
- Discuss integration with XDS, that in order to integrate into an XDS environment metadata must get generated
- General discussion
- Describe the enhancements to submission set author and intendedREcipeient CP 524.
- Open Issue: Is a flag needed to communicate to receiver that minimal metadata has been specified. If yes, what should the flag be. Suggestions of useing objectType or a SOAP level flag.
- Open Issue: Is minimal metadata an option in XDR and XDM. Also considered just downgrading the XDR/XDM actor handling of metadata.
- Review example metadata documentation
- Need to consider metadata update and registry stored query repurcussions
- Reviewed patientID metadata attributue
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.
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