XDR/XDM Metadata
Jump to navigation
Jump to search
Push Metadata Supplement Development
Ongoing work on
- Introduction
- Open/Closed Issues
- Use Cases
- Vol. 1 updates to XDR and XDM
has been moved to a MS Word document in the ftp directory. Look for the latest dated document with name IHE_Supplement_Push_Metadata.mm.dd.doc
Adjusting Metadata Requirements
Specific documentation of the adjusted metadata requirements has not been integrated into the MS Word document yet so remains here.
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 | Push | Discussion |
|---|---|---|---|
| author | R2 | R2 | No concerns. Note that the sender information is carried in the Submission Set author attribute, not this one. |
| 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/R | Optional in Provide & Register - XDR. XDM requires this value. |
| 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 | N/A | Does not apply to the XDR or XDM environment |
| 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. Agree to define this attribute when used in the XDR/XDM environment: the patient identifier is a value that is known by the recipient. If a patient identifier known by the recipient is not available no value is specified. If more than one identifier known by the recipient the sender chooses the value to use. No guidance on this choice is provided by IHE. Please see the sourcePatientId and sourcePatientInfo attributes for further guidance about identifying the patient to the receiver. If none of the patientID, sourcePatientId or sourcePatientInfo is specified it is unknown whether the document is patient specific or not. The receiver must open the document and do a, most likely, manuel inspection to determine whether it is a single patient specific document or not. |
| practiceSettingCode | R | R2 | This attribute is a coded value indicating the specialty where the document was produced. |
| repositoryUniqueId | Cp | N/A | Not applicable to XDR or XDM transactions |
| serviceStartTime | R2 | R2 | Valuable if available |
| serviceStopTime | R2 | R2 | Valuable if available |
| size | Cp | O/R | Optional in Provide & Register - XDR. XDM requires this value. |
| sourcePatientId | R | R2 | This is an identifier as know by the sender. If none of the patientID, sourcePatientId or sourcePatientInfo is specified it is unknown whether the document is patient specific or not. The receiver must open the document and do a, most likely, manuel inspection to determine whether it is a single patient specific document or not. |
| sourcePatientInfo | O | R2 | This attribute contains demographics about the patient. If no demographics are known it may be omitted. If none of the patientID, sourcePatientId or sourcePatientInfo is specified it is unknown whether the document is patient specific or not. The receiver must open the document and do a, most likely, manuel inspection to determine whether it is a single patient specific document or not. |
| title | O | O | |
| typeCode | R | R2 | |
| uniqueId | R | R | Intervening portal generates this value |
| URI | O | O/R | Optional in XDR - no meaning in thiat transaction. Required in XDM to address the location in the zip package of the document |
Submission Set Metadata
This section lists the metadata associated with the submission set.
| Metadata Attribute | XDS | Push | Discussion |
|---|---|---|---|
| author | R2 | R2 | 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 | NA | |
| intendedRecipient | O | R2 | 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 |
Metadata Docmentation Restructuring Supplement Development
Ongoing work on
- Introduction
- Open/Closed Issues
- Sections 4.1.7, 4.1.8 and 4.1.9
has been moved to a MS Word document in the ftp directory. Look for the latest dated document with name IHE_Supplement_Metadata-redoc.mm.dd.doc.
Open Issue
How will this restructuring effort and the general XD* Information Model work interact with the multiple supplements in Trial Implementation which change the model? Suggestion at: Proposal for ITI Information Model Change Management
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