XDR/XDM Metadata: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older edit
Witting (talk | contribs)
editor
1,865 edits
Witting (talk | contribs)
editor
1,865 edits
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
__TOC__
__TOC__


= Current Work =
= Push Metadata Supplement Development =
== Use Case ==


=== Primary care provider refers patient to specialist ===
Ongoing work on
Dr. Smith is referring a patient to Dr. Jones. Dr. Smith’s referral coordinator uses her web e-communication 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 emailed to Dr. Jones community email endpoint.
* Introduction
* Open/Closed Issues
* Use Cases
* Vol. 1 updates to XDR and XDM


Dr. Jones' system is able to receive XDR SOAP messages and the community that Dr. Jones participates with has agree to provide a conversion mechanism from email submissions to XDR.  Upon receipt of the email the community infrastructure will probably be able to decrypt the content but will not be able to automatically generate the metadata required for XDR.
has been moved to a MS Word document in the [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr9-2011-2012/Technical_Cmte/Profile_Work/Push-metadata/ ftp directory].  Look for the latest dated document with name IHE_Supplement_Push_Metadata.mm.dd.doc


<b>Current situation</b>
== Adjusting Metadata Requirements ==
Typically one of the following two approaches are used:
Specific documentation of the adjusted metadata requirements has not been integrated into the MS Word document yet so remains here.
* For all required metadata which cannot be generated, a default value is defined by the community infrastructure and, possibly, communicated to Dr. Jones.  Dr. Jones' system 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. Jones' system must be adjusted for this level of requirement and make appropriate choices for processing input that is not conformant with the XDR standard.


<b>Improved situation</b>
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. Jones ensures that his system supports this IHE specified level.  When Dr. Jones receives the content it is processed consistent with the use case, generally requiring human intervention to support routing and integration.  If Dr. Jones or the community did not want to support the requirement for human intervention the message could be rejected and that rejection communicated to the submitter.
== Adjusting Metadata Requirements ==
==== Document Entry Metadata====  
==== Document Entry Metadata====  


Line 25: Line 21:
! Metadata Attribute
! Metadata Attribute
! XDS
! XDS
! Minimal
! Push
! Discussion
! Discussion
|-
|-
Line 31: Line 27:
| R2  
| R2  
| R2  
| R2  
| No concerns.
| No concerns.  Note that the sender information is carried in the Submission Set author attribute, not this one.
|-
|-
| availabilityStatus
| availabilityStatus
Line 75: Line 71:
| hash
| hash
| Cp
| Cp
| O
| O/R
|  
| Optional in Provide & Register - XDR.  XDM requires this value.
|-
|-
| healthcareFacilityTypeCode  
| healthcareFacilityTypeCode  
Line 85: Line 81:
| homeCommunityId
| homeCommunityId
| Cx
| Cx
| O
| N/A
|  
| Does not apply to the XDR or XDM environment
|-
|-
| languageCode  
| languageCode  
Line 106: Line 102:
| R  
| R  
| R2  
| 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.
| 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  
| practiceSettingCode  
| R  
| R  
| R2  
| R2  
|
| This attribute is a coded value indicating the specialty where the document was produced.
|-
|-
| repositoryUniqueId
| repositoryUniqueId
Line 120: Line 116:
| serviceStartTime
| serviceStartTime
| R2
| R2
| O
| R2
|  
| Valuable if available
|-
|-
| serviceStopTime
| serviceStopTime
| R2
| R2
| O
| R2
|  
| Valuable if available
|-
|-
| size
| size
| Cp
| Cp
| O
| O/R
|  
| Optional in Provide & Register - XDR.  XDM requires this value.
|-
|-
| sourcePatientId  
| sourcePatientId  
| R  
| R  
| R2  
| 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  
| sourcePatientInfo  
| O
| O
| R2  
| 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
| title
Line 160: Line 156:
| URI
| URI
| O
| O
| O
| O/R
| Used by XDM maybe?
| Optional in XDR - no meaning in thiat transaction.  Required in XDM to address the location in the zip package of the document
|-
|-
|}
|}
Line 171: Line 167:
! Metadata Attribute
! Metadata Attribute
! XDS
! XDS
! Minimal
! Push
! Discussion
! Discussion
|-
|-
| author  
| author  
| R2  
| R2  
| R
| 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 [http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging#authorTelecommunication 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  
| contentTypeCode  
Line 188: Line 194:
| R  
| R  
|
|
|-
| homeCommunityId
| Cx
| NA
|
|-
|-
| intendedRecipient  
| intendedRecipient  
| O  
| O  
| R
| R2
|
| Extended to add an optional XTN value to the end of the string.  Format becomes XON|XCN|XTN.  XTN hold the email address of the intended recipient, if available.  See the [http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging#authorTelecommunication example from the Direct Project].  See author for an example of the XTN format.
|-
|-
| patientId  
| patientId  
Line 218: Line 229:
| 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:
{| style="width:95%" border="1" cellpadding="1"
! 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:
= Metadata Docmentation Restructuring Supplement Development =


<b>4.1.7.n <Attribute Name></b>
Ongoing work on
<br><b>Description:</b>
* Introduction
<br><b>Coding:</b>
* Open/Closed Issues
* Coding in Provide & Register and Register Transactions
* Sections 4.1.7, 4.1.8 and 4.1.9
* Coding in Query Request
* Coding in Query Response
<br><b>Required Use:</b>
* Requirements in use in XDS
* Requirements in use in XCA
* Requirements in use in XDR
* Requirements in use in XDM
<br><b>References:</b>


has been moved to a MS Word document in the [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr9-2011-2012/Technical_Cmte/Profile_Work/Push-metadata/ ftp directory].  Look for the latest dated document with name IHE_Supplement_Metadata-redoc.mm.dd.doc.


=== Example ===
== Open Issue ==  
{| style="width:95%" border="1" cellpadding="1"
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]]
! Metadata Attribute
! Description
! Data Type
! Details
|-
| author
| Represents the humans and/or machines that authored the document.
| ebRIM Classification
| [[#4.1.7.1 author | Section 4.1.7.1 author]]
|-
| creationTime
| Represents the time the author created the document in the Document Source.
| DTM
| [[#4.1.7.8 creationTime | Section 4.1.7.8 creationTime]]
|-
|}
 
==== 4.1.7.1 author ====
''The following is copied verbatim from the TF Vol. 3 metadata table''
<br>
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 ====
<br><b>Description:</b>Represents the time the author created the document in the Document Source.
Shall have a single value.
<br><b>Coding:</b>
* Coding in Provide & Register and Register Transactions - coded as a single value within a Slot in the DocumentEntry.
<br>Example:
<pre>
<rim:Slot name="creationTime">
<rim:ValueList>
<rim:Value>20041225212010</rim:Value>
</rim:ValueList>
</rim:Slot>
</pre>
 
* Coding in Query Request - coded as a single value within the $XDSDocumentEntryCreationTimeFrom and $XDSDocumentEntryCreationTimeTo Slots on selected stored queries.
<br>Example - to specify a creation time range of 200412252300 to 200501010800:
<pre>
<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>
</pre>
* Coding in Query Response - same as Provide & Register and Register Transactions
 
<br><b>Required Use:</b>
* 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
<br><b>Required Use: (alternative presentation </b>
{| style="width:95%" border="1" cellpadding="1"
! 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 =
= Meetings =

Latest revision as of 15:23, 12 April 2011

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:

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:

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

Proposal Documents

Retrieved from "http://wiki.ihe.net/index.php?title=XDR/XDM_Metadata&oldid=49946"