XDR/XDM Metadata: Difference between revisions
Jump to navigation
Jump to search
New page: __TOC__ = Current Work = == Meetings == === December 16, 2010 === Agenda: * Review U.S. Direct Project [http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging XDR and XDM for Dire... |
|||
| Line 3: | Line 3: | ||
= Current Work = | = Current Work = | ||
== Meetings == | == Meetings == | ||
=== January 24, 2010 === | |||
Agenda: | |||
* Review written use cases | |||
* Continue review of metadata and documenting in "discussion" column. | |||
* Review example of use of format for [[#Documenting Metadata | Documenting Metadata]]. | |||
=== December 16, 2010 === | === December 16, 2010 === | ||
Agenda: | Agenda: | ||
* Review U.S. Direct Project [http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging XDR and XDM for Direct Messaging] | * Review U.S. Direct Project [http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging XDR and XDM for Direct Messaging] | ||
* Review [[#Documenting Metadata | Documenting Metadata]] | * Review [[#Documenting Metadata | 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. | |||
== Adjusting Metadata Requirements == | == Adjusting Metadata Requirements == | ||
| Line 24: | Line 32: | ||
| R2 | | R2 | ||
| R2 | | R2 | ||
| | | No concerns. | ||
|- | |- | ||
| classCode | | classCode | ||
| R | | R | ||
| R2 | | 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. | ||
|- | |- | ||
| confidentialityCode | | confidentialityCode | ||
| R | | R | ||
| R2 | | 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 | | creationTime | ||
| R | | R | ||
| R2 | | R2 | ||
| | | If the creation time of the document is unknown it is better to specify nothing than use a value that is misleading. | ||
|- | |- | ||
| entryUUID | | entryUUID | ||
| R | | R | ||
| R | | R | ||
| | | No concerns. | ||
|- | |- | ||
| formatCode | | formatCode | ||
| R | | R | ||
| R2 | | R2 | ||
| | | Diferentiating is available in mimeType and if there is no greater knowledge about the content then this element should be unspecified. | ||
|- | |- | ||
| healthcareFacilityTypeCode | | healthcareFacilityTypeCode | ||
| R | | R | ||
| R2 | | 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. | ||
|- | |- | ||
| languageCode | | languageCode | ||
| R | | R | ||
| R2 | | R2 | ||
| | | C80 points to IETF 4646 which has a value for "undetermined" and could use this for this case. | ||
|- | |- | ||
| mimeType | | mimeType | ||
| Line 184: | Line 192: | ||
* Requirements in use in XDM | * Requirements in use in XDM | ||
<br><b>References:</b> | <br><b>References:</b> | ||
= Regional/National Projects = | = Regional/National Projects = | ||
Revision as of 08:39, 21 December 2010
Current Work
Meetings
January 24, 2010
Agenda:
- Review written use cases
- Continue review of metadata and documenting in "discussion" column.
- Review example of use of format for Documenting Metadata.
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.
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. |
| 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. |
| 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 | No concerns. |
| formatCode | R | R2 | Diferentiating is available in mimeType and if there is no greater knowledge about the content then this element should be unspecified. |
| 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. |
| languageCode | R | R2 | C80 points to IETF 4646 which has a value for "undetermined" and could use this for this case. |
| mimeType | R | R | |
| patientId | R | R2 | |
| practiceSettingCode | R | R2 | |
| sourcePatientId | R | R2 | |
| sourcePatientInfo | R2 | R2 | |
| typeCode | R | R2 | |
| uniqueId | R | R |
Submission Set Metadata
This section lists the metadata associated with the submission set.
| Metadata Attribute | XDS | Minimal | Discussion |
|---|---|---|---|
| author | R2 | R | |
| contentTypeCode | R | R2 | |
| entryUUID | R | R | |
| intendedRecipient | O | R | |
| 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 2. A suggestion is to create a simple table without any explanation with columns:
- Attribute Name - just lists the common name of the attribute
- Data Type - identifies the type of content the attribute contains
- References - links to places where this attribute is discussed
- Requirements: - lists the required level of the attribiute in several different contexts
- Provide & Register (XDS)
- Provide & Register (XDR)
- Register
- Query Request
- Query Response
- Distribute Document Set on Media
Alternatively, the above table could be greatly simplified by having a section for each attribute that explains much of the above in appropriate details. So a section might look like:
4.1.7.n <Attribute Name>
Desciption:
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:
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