View source for XDR/XDM Metadata

__TOC__



= 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.  
<br><b>NOTE: </b>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.

<b>Current situation</b>
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.

<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. 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.  

{| style="width:95%" border="1" cellpadding="1"
! 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.

{| style="width:95%" border="1" cellpadding="1"
! 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 [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 
| R 
| R2 
| 
|-
| entryUUID 
| R 
| R 
|
|-
| homeCommunityId
| Cx
| NA
| 
|-
| intendedRecipient 
| O 
| 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 
| R 
| R2 
|
|-
| sourceId 
| R 
| R 
|
|-
| submissionTime 
| R 
| R 
|
|-
| title 
| O 
| O 
|
|-
| uniqueId 
| R 
| R 
| 
|-
|}

= New Approach to Documenting Metadata =

This project highlights the challenges that currently exist in our approach to documenting metadata in volume 3.  This section will explore ideas and examples for improving this documentation.

The following proposed approach focuses on improving Volume 3, Sections 4.1.7 Document Definition Metadata, 4.1.8 Submission Set Metadata and 4.1.9 Folder Metadata.  If adopted, these three sections will continue to exist, holding the same or extended technical content but expressed in a very different way.  Impacts outside of these sections will be necessary to adjust for the different approach to documentation but one goal is to keep those impacts as limited as is feasible. 

== Proposal Introduction ==
Each of the sections (4.1.7, 4.1.8 and 4.1.9) will hold a similar table to the one that currently exists, containing the same rows as the ones currently in the sections.  What will change is the columns and column content.
== Open Issues ==
* (1) How will this change effect the Metadata Update supplement (and any other supplement)?
* (2) This suggests updates to the detailed content but improvement is still needed to describe the high level content that encloses the metadata within the transactions.  Proposed Resolution: to keep the work managable, scope this issue out of this work item as much as possible.
* (3) How will these changes effect the Registry Stored Query transaction?  Should some of the content here be migrated to Vol. 3 or does it need to be replicated for ease of use by implementor of transaction?
* (4) Should this work item be expanded to address how each metadata attribute is used in a query request to narrow the list of responses, basically the use cases for each metadata attribute.  Proposed Resolution: to keep the scope limited to just what is needed for the new work the addition of this content should be deferred.  But an understanding of where the content would be placed when available might be appropriate.

== Section 4.1.7 Document Definition Metadata  ==

The introduction to 4.1.7 will stay the same, including Table 4.1-3, 4.1-4.  The big impact starts at table 4.1-5 which is replaced by the following table (example to be extended to contain all attributes of document entry)

=== Table 4.1-5 (replacement) ===
{| style="width:95%" border="1" cellpadding="1"
! 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]]
|-
| (etc.)
| (One row per metadata attribues in Document Entry)
| 
| 
|}


=== Section 4.1.7.1 author (example) ===
''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"

=== Section 4.1.7.8 creationTime (example) ===
<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>
{| 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
|-
|}

== Section 4.1.8 Submission Set Metadata  ==

The introduction to 4.1.8 will stay the same.  The big impact starts at table 4.1-6 which is replaced by the following table (example to be extended to contain all attributes of document entry)

=== Table 4.1-6 (replacement) ===
{| style="width:95%" border="1" cellpadding="1"
! Metadata Attribute
! Description
! Data Type
! Details
|-
| author
| Represents the humans and/or machines that authored the documents in the submission set.
| ebRIM Classification
| [[#4.1.8.1 author | Section 4.1.8.1 author]]
|-
| availabilityStatus
| 
| String
| [[#4.1.8.2 availabilityStatus | Section 4.1.8.2 availabilityStatus]]
|-
| comments
| Comments associated with the Submission Set. 
| String
| [[#4.1.8.3 comments | Section 4.1.8.3 comments]]
|-
| contentTypeCode
| The code specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS-Submission Set.
| Coded
| [[#4.1.8.4 contentTypeCode | Section 4.1.8.4 contentTypeCode]]
|-
| entryUUID
| This globally unique identifier is primarily intended for use as a document registry management identifier. 
| UUID
| [[#4.1.8.5 entryUUID | Section 4.1.8.5 entryUUID]]
|-
| homeCommunityId
| A globally unique identifier for a community.
| 64 character OID in URI syntax
| [[#4.1.8.6 homeCommunityId | Section 4.1.8.6 homeCommunityId]]
|-
| intendedRecipient
| Represents the organization(s) or person(s) for whom the Submission set is intended.  
| XON|XCN
| [[#4.1.8.7 intendedRecipient | Section 4.1.8.7 intendedRecipient]]
|-
| patientId
| The patientId represents the medical record identifier of subject of care whose longitudinal record is being maintained.
| CX
| [[#4.1.8.8 patientId | Section 4.1.8.8 patientId]]
|-
| sourceId
| OID identifying the instance of the Document Source that contributed the Submission Set.  
| OID
| [[#4.1.8.9 sourceId | Section 4.1.8.9 sourceId]]
|-
| submissionTime
| Point in Time at the Document Source when the Submission Set was created and issued for registration to the Document Registry.
| DTM
| [[#4.1.8.10 submissionTime | Section 4.1.8.10 submissionTime]]
|-
| title
| Represents the title of the Submission Set. 
| String
| [[#4.1.8.11 title | Section 4.1.8.11 title]]
|-
| uniqueId
| Globally unique identifier for the submission-set instance assigned by the Document Source in OID format.
| OID
| [[#4.1.8.12 uniqueId | Section 4.1.8.12 uniqueId]]
|}

=== Section 4.1.8.7 intendedRecipient (example) ===
<br><b>Description:</b>Represents the organization(s) or person(s) for whom the Submission set is intended.  If present, shall have one or more values. Each entry should include one organization, one person, or both. It is highly recommended to define the organization for all the persons, avoiding errors in the transmission of the documents internally at the Document Recipient side.
<br><b>Coding:</b>
* Coding in Provide & Register and Register Transactions - coded as one or more values within a Slot in the Submission Set.
<br>Example below shows two doctors from the same organization, another doctor without precision of the organization and another organization without the precision of the person. 
<br><b>THIS SENTENCE NEEDS TO BE FIXED: </b>If this attribute is received in a Provide and Register Document Set-b [ITI-41] or Register Document Set-b [ITI-42] transaction, it shall be ignored.
<br>There is a “|” character separator between the organization and the person, which is required when the person information is present.
<pre>
<rim:Slot name="intendedRecipient">
	<rim:ValueList>
		<rim:Value> Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45|^Wel^Marcus^^^Dr^MD</rim:Value>
		<rim:Value> Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45|^Al^Peter^^^Dr^MD</rim:Value>
		<rim:Value>|12345^John^Smith^^^Dr^MD</rim:Value>
		<rim:Value>Main Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.2364</rim:Value>
	</rim:ValueList></rim:Slot>
</pre>
<br><b>Required Use:</b>
{| style="width:95%" border="1" cellpadding="1"
! Profiles
! Transactions
! Request
! Response
! Details
|-
| XDS
| ITI-41 Provide & Register
ITI-42 Register
| Optional, but "ignored"
| N/A
| Unclear whether a Repository must remove or pass on a value.  Registry required to ignore.
|-
| XDS
| ITI-18 Registry Stored Query
| Not Allowed
| Not Allowed
| Not "supported" by XDS
|-
| XDR
| ITI-41 Provide & Register
| Required
| N/A
| Requirement based on XDR use case
|-
| XDM
| ITI-32 Distribute Document set on Media
| Required
| N/A
| Requirement based on XDM use case
|-
| XCA
| ITI-38 Cross Gateway Query
| Not Allowed
| Not Allowed
| Not "supported" by XCA
|-
|}

== Section 4.1.9 Folder Metadata  ==
TBD

= Meetings =
== January 24, 2010 ==
Agenda:
* Review [[#Use Case | use case]].
* Continue review of [[#Adjusting_Metadata_Requirements | metadata]] and documenting in "discussion" column.
* Review example of use of format for [[#Documenting Metadata | 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 [http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging XDR and XDM for Direct Messaging]
* 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.



<br><b>References:</b>
* 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 - [http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging XDR and XDM for Direct Messaging]
* Australia  - [http://ihe-australia.wikispaces.com/XDR-2 SMD/XDR/XDS harmonization]
* Continua
* epSOS

= Proposal Documents =
* [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr9-2011-2012/Planning_Cmte/BriefProfileProposals/IHE%202011-2012%20Profile%20Proposal%20XD_%20Metadata_v2.doc Brief Proposal]
* [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr9-2011-2012/Planning_Cmte/BriefProfileProposals/IHE2011-2012ProfileProposalXD_Metadata.ppt Brief Proposal Presenation]
* [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr9-2011-2012/Technical_Cmte/Detailed-Proposals/IHE2011-2012ProfileProposalXD_%20Metadata-detailed.doc Detailed Proposal]
* [ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr9-2011-2012/Technical_Cmte/Detailed-Proposals/IHE2011-2012ProfileProposalXD_Metadata.ppt Detailed Proposal Presentation]