Unattributed Code Systems

Copyright Fragment

This fragment is available on download.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

Type Reference Content
web example.org what : http://example.org/blah/blah.pdf
web example.com http://example.com/nowhere.txt
web profiles.ihe.net Recommend ATNA , encouraged IHE-IUA or SMART-on-FHIR
web profiles.ihe.net Recommend ATNA , encouraged IHE-IUA or SMART-on-FHIR
web profiles.ihe.net
web profiles.ihe.net
web github.com Mobile access to Health Documents (MHD), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 4.2.3-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.MHD/ and changes regularly. See the Directory of published versions
web profiles.ihe.net This transaction is used to transfer documents and metadata and is analogous to a Provide and Register Document Set-b ITI-41 transaction.
web www.ihe.net IG © 2020+ IHE IT Infrastructure Technical Committee . Package ihe.iti.mhd#4.2.3-current based on FHIR 4.0.1 . Generated 2025-04-07
Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web profiles.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web www.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web profiles.ihe.net A Document Source that supports this option will provide metadata consistent with the additional document sharing requirements for an XDS Document Source described in ITI TF-3: 4.3.1- Submission Metadata Attribute Optionality and ITI TF-3: 4.5.1 Metadata Object Types mapped to FHIR .
web profiles.ihe.net A Document Recipient that supports this option will require that any metadata provided is consistent with the additional document sharing requirements for an XDS Document Source described in ITI TF-3: 4.3.1- Submission Metadata Attribute Optionality .
web profiles.ihe.net The Document Recipient that supports this option shall be able to be grouped with an XDS Document Source so that any publication request is passed on to that XDS environment. See the transaction specific requirements outlined in ITI-65 XDS on FHIR Option . The grouped XDS Document Source shall implement the Document Replacement Option , Document Addendum Option , Document Transformation Option , and Folder Management Option to ensure that these functionalities can be transferred from the MHD Document Source through to the XDS Document Registry .
web profiles.ihe.net The Document Recipient that supports this option shall be able to be grouped with an XDS Document Source so that any publication request is passed on to that XDS environment. See the transaction specific requirements outlined in ITI-65 XDS on FHIR Option . The grouped XDS Document Source shall implement the Document Replacement Option , Document Addendum Option , Document Transformation Option , and Folder Management Option to ensure that these functionalities can be transferred from the MHD Document Source through to the XDS Document Registry .
web profiles.ihe.net The Document Recipient that supports this option shall be able to be grouped with an XDS Document Source so that any publication request is passed on to that XDS environment. See the transaction specific requirements outlined in ITI-65 XDS on FHIR Option . The grouped XDS Document Source shall implement the Document Replacement Option , Document Addendum Option , Document Transformation Option , and Folder Management Option to ensure that these functionalities can be transferred from the MHD Document Source through to the XDS Document Registry .
web profiles.ihe.net The Document Recipient that supports this option shall be able to be grouped with an XDS Document Source so that any publication request is passed on to that XDS environment. See the transaction specific requirements outlined in ITI-65 XDS on FHIR Option . The grouped XDS Document Source shall implement the Document Replacement Option , Document Addendum Option , Document Transformation Option , and Folder Management Option to ensure that these functionalities can be transferred from the MHD Document Source through to the XDS Document Registry .
web profiles.ihe.net The Document Recipient that supports this option shall be able to be grouped with an XDS Document Source so that any publication request is passed on to that XDS environment. See the transaction specific requirements outlined in ITI-65 XDS on FHIR Option . The grouped XDS Document Source shall implement the Document Replacement Option , Document Addendum Option , Document Transformation Option , and Folder Management Option to ensure that these functionalities can be transferred from the MHD Document Source through to the XDS Document Registry .
web profiles.ihe.net The Document Recipient that supports this option shall be able to be grouped with an XDS Document Source so that any publication request is passed on to that XDS environment. See the transaction specific requirements outlined in ITI-65 XDS on FHIR Option . The grouped XDS Document Source shall implement the Document Replacement Option , Document Addendum Option , Document Transformation Option , and Folder Management Option to ensure that these functionalities can be transferred from the MHD Document Source through to the XDS Document Registry .
web profiles.ihe.net The Document Recipient that supports this option shall be able to be grouped with an XDS Document Source so that any publication request is passed on to that XDS environment. See the transaction specific requirements outlined in ITI-65 XDS on FHIR Option . The grouped XDS Document Source shall implement the Document Replacement Option , Document Addendum Option , Document Transformation Option , and Folder Management Option to ensure that these functionalities can be transferred from the MHD Document Source through to the XDS Document Registry .
web profiles.ihe.net The Document Responder that supports this option shall be able to be grouped with an XDS Document Consumer so that any query or retrieve requests can be passed on to, and responded to, by an XDS environment. The transaction specific requirements are outlined in ITI-66 XDS on FHIR Options and ITI-67 XDS on FHIR Option .
web profiles.ihe.net The UnContained Reference Option recognizes that a Community may choose to longitudinally maintain their provider and patient directories, for example, an mCSD Care Services Selective Supplier and PMIR Patient Identity Registry. When this longitudinal consistency is managed, then the author, authenticator, sourcePatientInfo, and author entries do not need to be a contained copy of the information known at the time of publication ITI-65 since a Reference to the information in these directories will be valid over the full lifecycle of the entries.
web profiles.ihe.net The UnContained Reference Option recognizes that a Community may choose to longitudinally maintain their provider and patient directories, for example, an mCSD Care Services Selective Supplier and PMIR Patient Identity Registry. When this longitudinal consistency is managed, then the author, authenticator, sourcePatientInfo, and author entries do not need to be a contained copy of the information known at the time of publication ITI-65 since a Reference to the information in these directories will be valid over the full lifecycle of the entries.
web profiles.ihe.net The Document Recipient claiming the Simplified Push Option shall implement the ITI-105 transaction. The Document Recipient will extract the document, translate the DocumentReference metadata elements into a SubmissionSet following the PCC TF-2: 4.1 Medical Document Binding to Document Sharing Metadata , and may have further metadata translation requirements specified by the local Document Sharing Community policy.
web profiles.ihe.net The Document Recipient claiming the Generate Metadata Option shall implement the ITI-106 transaction. The Document Recipient will interpret the document, create or update a DocumentReference metadata, convert DocumentReference elements into a SubmissionSet. The metadata derivation shall following the PCC TF-2: 4.1 Medical Document Binding to Document Sharing Metadata , and may have further metadata translation requirements specified by the local Document Sharing Community policy.
web profiles.ihe.net The MHD Profile enables sharing of patient documents to, or from, mobile or constrained devices. Other IHE profiles, chiefly Cross-Enterprise Document Sharing (XDS), describe sharing of patient document in less constrained environments, and many of the concepts from those profiles are applicable to the MHD environment. For more information on IHE Document Sharing, see Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper.
web profiles.ihe.net This use case presumes that the mobile device knows or discovers the patient identity. The patient identity might be obtained through some IHE transactional method such as the Patient Demographics Query for Mobile PDQm or Patient Identifier Cross-Reference for Mobile PIXm Profile. The patient id might simply be entered via some device interface (RFID, Bar-Code), a user interface, or be specified in a configuration setting (e.g., mobile PHR application). The use case also allows for identity cross-referencing to be implemented by the Document Recipient.
web profiles.ihe.net This use case presumes that the mobile device knows or discovers the patient identity. The patient identity might be obtained through some IHE transactional method such as the Patient Demographics Query for Mobile PDQm or Patient Identifier Cross-Reference for Mobile PIXm Profile. The patient id might simply be entered via some device interface (RFID, Bar-Code), a user interface, or be specified in a configuration setting (e.g., mobile PHR application). The use case also allows for identity cross-referencing to be implemented by the Document Recipient.
web profiles.ihe.net The publication of a new document(s) is done using the Provide Document Bundle [ITI-65] transaction or the Simplified Publish [ITI-105] transaction, which carries both the document and its metadata. The [ITI-65] transaction is analogous to an XDS Provide and Register Document Set-b [ITI-41] transaction. The [ITI-105] is a more simple transaction where the publication needs are more simple, moving the SubmissionSet mapping task to the Document Recipient.
web profiles.ihe.net See ITI TF-2x: Appendix Z.8 “Mobile Security Considerations” .
web profiles.ihe.net When MHD actors also implement actors in the Internet User Authorization (IUA) Profile, there are additional requirements documented in the IUA supplement .
web profiles.ihe.net When MHD actors also implement actors in the Internet User Authorization (IUA) Profile, there are additional requirements documented in the IUA supplement .
web profiles.ihe.net Not diagrammed here is how PDQm and/or PIXm could similarly be used and implemented.
web profiles.ihe.net Not diagrammed here is how PDQm and/or PIXm could similarly be used and implemented.
web profiles.ihe.net Editor, please add the following rows to Table 4.2.4.1-2: Error Codes (previously Table 4.1-11) in ITI TF-3: 4.2.4.1
web profiles.ihe.net This section documents the mapping between IHE Document Sharing Metadata and the FHIR Resources.
web profiles.ihe.net When encoding XDS identifiers into FHIR Resource data elements of type Identifier, the FHIR notation of OIDs and UUIDs uses the system identifier of urn:ietf:rfc:3986 . For more details and examples, see ITI TF-2: Appendix E.3 “FHIR Identifier Type” .
web profiles.ihe.net The documented mapping of the metadata elements associated with a Document Sharing DocumentEntry object attributes.
web profiles.ihe.net The documented mapping of the metadata elements associated with a Document Sharing SubmissionSet object attributes.
web profiles.ihe.net The documented mapping of the metadata elements associated with a Document Sharing Folder object attributes.
web example.org subject : http://example.org/Patient/FranzMusterNeedsAbsoluteUrl
web example.com http://example.com/xdsretrieve?uniqueId=urn:uuid:413eb0f7-aa72-4405-86a4-7793a23fcc27&repositoryUniqueId=2.999.756.42.1
web profiles.ihe.net Source Code - XDS Association Types are indicated as URN, they are here indicated as system and code
web profiles.ihe.net The Document Source shall assure the Simplified Publish DocumentReference resource are consistent with the Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1-3 “Sending Actor Metadata Attribute Optionality” . The Document Source that supports the Comprehensive Metadata or the XDS on FHIR Options shall assure consistency with column “XDS DS”; otherwise, the Document Source shall assure consistency with column “XDR MS”. Except that the Document Source does not need to provide any entryUUID values, as the entryUUID will be populated by the Document Recipient when necessary.
web profiles.ihe.net The Document Source shall assure the Simplified Publish DocumentReference resource are consistent with the Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1-3 “Sending Actor Metadata Attribute Optionality” . The Document Source that supports the Comprehensive Metadata or the XDS on FHIR Options shall assure consistency with column “XDS DS”; otherwise, the Document Source shall assure consistency with column “XDR MS”. Except that the Document Source does not need to provide any entryUUID values, as the entryUUID will be populated by the Document Recipient when necessary.
web profiles.ihe.net A Patient Reference to a commonly accessible server may be obtained through use of PDQm , PIXm , PMIR , or by some other means.
web profiles.ihe.net A Patient Reference to a commonly accessible server may be obtained through use of PDQm , PIXm , PMIR , or by some other means.
web profiles.ihe.net A Patient Reference to a commonly accessible server may be obtained through use of PDQm , PIXm , PMIR , or by some other means.
web profiles.ihe.net The Document Recipient should verify the FHIR resource elements for consistency with the Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1-3: “Sending Actor Metadata Attribute Optionality” .
web profiles.ihe.net The Document Recipient shall extract the document, translate the DocumentReference metadata elements into a SubmissionSet following the PCC TF-2: 4.1 Medical Document Binding to Document Sharing Metadata , and may have further metadata translation requirements specified by the local Document Sharing Community policy.
web profiles.ihe.net If the Document Recipient encounters any errors or if any validation fails, the Document Recipient shall return an error using a FHIR OperationOutcome. If appropriate, it shall use error codes from ITI TF-3: Table 4.2.4.1-2 .
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net The Document Recipient shall transform the DocumentReference content into a proper message for the given grouped actor (e.g., the XDS Document Source using the Provide and Register Document Set-b [ITI-41] transaction). The Document Recipient shall create appropriate metadata from Resources in the FHIR DocumentReference Resource, including SubmissionSet, and DocumentEntry.
web profiles.ihe.net Where values provided are References to FHIR resources (e.g., DocumentReference.encounter), the Reference should be converted to a Document Sharing CXi Identifier Datatype for recording in the Document Sharing ebRIM using the Identifier Type Codes when appropriate (see Appendix Z.9.1.2 ). The conversion may be by using the referenced Resource business .identifier. Note, there is not an obvious conversion of a reference .id to CXi identifier. Note that DocumentReference.encounter would be mapped into DocumentEntry.referenceIdList as an Identifier Type Code of urn:ihe:iti:xds:2015:encounterId .
web profiles.ihe.net Where values provided are References to FHIR resources (e.g., DocumentReference.encounter), the Reference should be converted to a Document Sharing CXi Identifier Datatype for recording in the Document Sharing ebRIM using the Identifier Type Codes when appropriate (see Appendix Z.9.1.2 ). The conversion may be by using the referenced Resource business .identifier. Note, there is not an obvious conversion of a reference .id to CXi identifier. Note that DocumentReference.encounter would be mapped into DocumentEntry.referenceIdList as an Identifier Type Code of urn:ihe:iti:xds:2015:encounterId .
web profiles.ihe.net Document Recipient shall provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3 indicating the transaction has been implemented.
web profiles.ihe.net Document Source should provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3 indicating the transaction has been implemented.
web profiles.ihe.net The security audit criteria are similar to those for the Provide and Register Document Set-b [ITI-41] transaction as this transaction does export a document.
web profiles.ihe.net The Document Recipient shall extract the document, generate the DocumentReference metadata, and translate the DocumentReference metadata elements into a SubmissionSet following the PCC TF-2: 4.1 Medical Document Binding to Document Sharing Metadata , and may have further metadata translation requirements specified by the local Document Sharing Community policy.
web profiles.ihe.net The Document Recipient shall generate Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1-3: “Sending Actor Metadata Attribute Optionality” .
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping MHD Document Recipient with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net The security audit criteria are similar to those for the Provide and Register Document Set-b ITI-41 transaction as this transaction does export a document.
web profiles.ihe.net The Document Source shall assure all FHIR resource elements are consistent with the Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1-3 “Sending Actor Metadata Attribute Optionality” . The Document Source that supports the Comprehensive Metadata or the XDS on FHIR Options shall assure consistency with column “XDS DS”; otherwise, the Document Source shall assure consistency with column “XDR MS”. Except that the Document Source does not need to provide any entryUUID values, as the entryUUID will be populated by the Document Recipient when necessary.
web profiles.ihe.net The Document Source shall assure all FHIR resource elements are consistent with the Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1-3 “Sending Actor Metadata Attribute Optionality” . The Document Source that supports the Comprehensive Metadata or the XDS on FHIR Options shall assure consistency with column “XDS DS”; otherwise, the Document Source shall assure consistency with column “XDR MS”. Except that the Document Source does not need to provide any entryUUID values, as the entryUUID will be populated by the Document Recipient when necessary.
web profiles.ihe.net Where the document content is On-Demand Document Option , the .hash and the .size shall be absent from the DocumentReference Resource. See On-Demand Document Use Cases Summary .
web profiles.ihe.net Where the document content is On-Demand Document Option , the .hash and the .size shall be absent from the DocumentReference Resource. See On-Demand Document Use Cases Summary .
web profiles.ihe.net Where the document content is Delayed Document Assembly , the .size of 0 (zero), and the .hash with the fixed value da39a3ee5e6b4b0d3255bfef95601890afd80709 (SHA1 hash of a zero length file).
web profiles.ihe.net If the Document Recipient encounters any errors or if any validation fails, the Document Recipient shall return an error, as documented in Provide Document Bundle Response Message . If appropriate, it shall use error codes from ITI TF-3: Table 4.2.4.1-2 .
web profiles.ihe.net This section applies to grouping the MHD Document Recipient Actor with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping the MHD Document Recipient Actor with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping the MHD Document Recipient Actor with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping the MHD Document Recipient Actor with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net This section applies to grouping the MHD Document Recipient Actor with XDS Document Source Actor, XDR Document Source Actor, XDR Limited-Metadata Document Source Actor, and XDM Portable Media Creator Actor (e.g., with the XDM ZIP over Email Option ).
web profiles.ihe.net The Document Recipient shall transform the Bundle content into a proper message for the given grouped actor (e.g., the XDS Document Source using the Provide and Register Document Set-b [ITI-41] transaction). The Document Recipient shall create appropriate metadata from Resources in the FHIR Bundle Resource, including SubmissionSet, DocumentEntry, Folder, and Associations.
web profiles.ihe.net Where values provided are References to FHIR resources (e.g., DocumentReference.encounter), the Reference should be converted to a Document Sharing CXi Identifier Datatype for recording in the Document Sharing ebRIM using the Identifier Type Codes when appropriate (See Appendix Z.9.1.2 ). The conversion may be by using the referenced Resource business .identifier. Note, there is not an obvious conversion of a reference .id to CXi identifier. Note that DocumentReference.encounter would be mapped into DocumentEntry.referenceIdList as an Identifier Type Code of urn:ihe:iti:xds:2015:encounterId .
web profiles.ihe.net Where values provided are References to FHIR resources (e.g., DocumentReference.encounter), the Reference should be converted to a Document Sharing CXi Identifier Datatype for recording in the Document Sharing ebRIM using the Identifier Type Codes when appropriate (See Appendix Z.9.1.2 ). The conversion may be by using the referenced Resource business .identifier. Note, there is not an obvious conversion of a reference .id to CXi identifier. Note that DocumentReference.encounter would be mapped into DocumentEntry.referenceIdList as an Identifier Type Code of urn:ihe:iti:xds:2015:encounterId .
web profiles.ihe.net ​ This section applies to grouping the MHD Document Recipient Actor with MHDS Document Registry Actor. As MHDS uses the same FHIR syntax, there is no changing of the ITI-65 bundle necessary.
web profiles.ihe.net ​ This section applies to grouping the MHD Document Recipient Actor with MHDS Document Registry Actor. As MHDS uses the same FHIR syntax, there is no changing of the ITI-65 bundle necessary.
web profiles.ihe.net FindSubmissionSets query in the Registry Stored Query [ITI-18] transaction, as documented in ITI TF-2: 3.18.4.1.2.3.7.2 .
web profiles.ihe.net FindSubmissionSets query in the Registry Stored Query [ITI-18] transaction, as documented in ITI TF-2: 3.18.4.1.2.3.7.2 .
web profiles.ihe.net FindFolders query in the Registry Stored Query [ITI-18] transaction, as documented in ITI TF-2: 3.18.4.1.2.3.7.3 .
web profiles.ihe.net FindFolders query in the Registry Stored Query [ITI-18] transaction, as documented in ITI TF-2: 3.18.4.1.2.3.7.3 .
web profiles.ihe.net identifier : This parameter, of type token, specifies an identifier for this List. The search results represent the results of a search on List.identifier. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net patient : This parameter is of type Reference(Patient). The Document Consumer may get this reference through the use of the PDQm or PIXm Profiles, or by some other method. When the patient parameter is used, the Patient reference would need to be accessible to both the Document Consumer and the Document Responder.
web profiles.ihe.net patient : This parameter is of type Reference(Patient). The Document Consumer may get this reference through the use of the PDQm or PIXm Profiles, or by some other method. When the patient parameter is used, the Patient reference would need to be accessible to both the Document Consumer and the Document Responder.
web profiles.ihe.net patient.identifier : This parameter, of type token, specifies an identifier associated with the patient to which the List Resource is assigned. See ITI TF-2x: Appendix Z.2 for use of the token data type for identifiers. This use of patient.identifier follows the FHIR Chaining Parameters search methodology.
web profiles.ihe.net source.given and source.family : These parameters, of type string, specify the name parts of the author person which is associated with the List. See ITI TF-2x: Appendix Z.2 for use of the string data type. This use of source.given and source.family follows the FHIR Chaining Parameters search methodology.
web profiles.ihe.net See ITI TF-2x: Appendix Z.6 for details.
web profiles.ihe.net The manner in which the Document Responder translates these parameters to ebXML to support the Registry Stored Query [ITI-18] transaction will depend on the type of the corresponding parameter within the FindSubmissionSets stored query (see ITI TF-2: 3.18.4.1.2.3.7.2 ).
web profiles.ihe.net Based on the query results, the Document Responder will either return an error or success. Guidance on handling Access Denied related to use of 200, 403 and 404 can be found in ITI TF-2x: Appendix Z.7 .
web profiles.ihe.net The response shall adhere to the FHIR Bundle constraints specified in ITI TF-2x: Appendix Z.1 .
web profiles.ihe.net Document Responders implementing this transaction shall provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3 indicating the transaction has been implemented.
web profiles.ihe.net The security audit criteria are similar to those for the Registry Stored Query [ITI-18] transaction.
web profiles.ihe.net author.given and author.family : These parameters, of type string, specify the name parts of the author person, which is associated with the DocumentReference Resource, or in Document Sharing nomenclature, the author of the Document Entry. See ITI TF-2x: Appendix Z.2 for use of the string data type. This use of author.given and author.family follows the FHIR Chaining Parameters search methodology.
web profiles.ihe.net category : This parameter, of type token, specifies the general classification of the DocumentReference Resource, or in Document Sharing nomenclature, the classCode of the Document Entry. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net event : This parameter, of type token, specifies the main clinical acts documented by the DocumentReference Resource, or in Document Sharing nomenclature, the eventCodeList of the Document Entry. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net facility : This parameter, of type token, specifies the kind of facility found in DocumentReference.context.facilityType, or in Document Sharing nomenclature, the healthcareFacilityTypeCode of the Document Entry. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net format : This parameter, of type token, specifies the format of the DocumentReference Resource, or in Document Sharing nomenclature, the formatCode of the Document Entry. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net identifier : This parameter, of type token, specifies an identifier for this DocumentReference and/or the contained document. The search results represent the results of a search on DocumentReference.masterIdentifier and DocumentReference.identifier. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net patient : This parameter is of type Reference(Patient). The Document Consumer may get this reference using the PDQm or PIXm Profile. When the patient parameter is used, the Patient reference would need to be accessible to both the Document Consumer and the Document Responder.
web profiles.ihe.net patient : This parameter is of type Reference(Patient). The Document Consumer may get this reference using the PDQm or PIXm Profile. When the patient parameter is used, the Patient reference would need to be accessible to both the Document Consumer and the Document Responder.
web profiles.ihe.net patient.identifier : This parameter, of type token, specifies an identifier associated with the patient to which the DocumentReference Resource is assigned. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type. This use of patient.identifier follows the FHIR Chaining Parameters search methodology.
web profiles.ihe.net security-label : This parameter, of type token, specifies the security labels of the document referenced by DocumentReference Resource, or in Document Sharing nomenclature, the confidentialityCode of the Document Entry. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net setting : This parameter, of type token, specifies the specific practice setting of the DocumentReference Resource, or in Document Sharing nomenclature, the practiceSettingCode of the Document Entry. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net type : This parameter, of type token, specifies the specific type of the DocumentReference resource or in Document Sharing nomenclature, the typeCode of the Document Entry. See ITI TF-2x: Appendix Z.2 for additional constraints on the use of the token search parameter type.
web profiles.ihe.net The Document Responder is grouped with an XDS Document Consumer when it supports the XDS on FHIR Option. The Document Responder shall map the query parameters as listed in Table 2:3.67.4.1.3.1-1 and shall execute a Registry Stored Query [ITI-18] for FindDocuments or FindDocumentsByReferenceIdList (see ITI TF-2: 3.18.4.1.2.3.7.1 and 3.18.4.1.2.3.7.14 ). All of the query parameters in Table 3.67.4.1.3-1 shall be supported by the Document Responder. No additional query parameters as defined in FHIR are required of the Document Responder, but they may be offered.
web profiles.ihe.net The Document Responder is grouped with an XDS Document Consumer when it supports the XDS on FHIR Option. The Document Responder shall map the query parameters as listed in Table 2:3.67.4.1.3.1-1 and shall execute a Registry Stored Query [ITI-18] for FindDocuments or FindDocumentsByReferenceIdList (see ITI TF-2: 3.18.4.1.2.3.7.1 and 3.18.4.1.2.3.7.14 ). All of the query parameters in Table 3.67.4.1.3-1 shall be supported by the Document Responder. No additional query parameters as defined in FHIR are required of the Document Responder, but they may be offered.
web profiles.ihe.net Note 4: The $XDSDocumentEntryReferenceIdList can only be mapped when using the XDS FindDocumentsByReferenceId query. This parameter support requires XDS Reference ID Option .
web profiles.ihe.net The response shall adhere to the FHIR Bundle constraints specified in ITI TF-2x: Appendix Z.1 . The response bundle for a MHD Find Document References Comprehensive Response is defined here , with an example .
web profiles.ihe.net XDS introduced the concept of a On-Demand Document Option , and is explained in the Use Cases Summary . The use of On-Demand Documents allows for documents that would be produced for a specific patient with content assembled at the time of processing the document consumer retrieve request.
web profiles.ihe.net XDS introduced the concept of a On-Demand Document Option , and is explained in the Use Cases Summary . The use of On-Demand Documents allows for documents that would be produced for a specific patient with content assembled at the time of processing the document consumer retrieve request.
web profiles.ihe.net XDS introduced the concept of a On-Demand Document Option , and is explained in the Use Cases Summary . The use of On-Demand Documents allows for documents that would be produced for a specific patient with content assembled at the time of processing the document consumer retrieve request.
web profiles.ihe.net On-Demand Documents are indicated in the DocumentReference by the DocumentReference.content.attachment with an absent .hash and .size element. For more background on On-Demand Documents . There is no need to declare an On-Demand Documents Option in MHD.
web profiles.ihe.net Informative note: When the Document Consumer retrieves the document using the Document location, then the retrieved document might exist as an IsSnapshotOf Association according to XDS [ITI-43] . The IsSnapshotOf Association is identified as a new DocumentReference with relatesTo.code of transforms .
web profiles.ihe.net XDS introduced the concept of Delayed Document Assembly Option , and is explained in the Use Cases Summary . The use of Delayed Document Assembly allows source systems to register the existence of stable document content but defer actually assembling the document content only if and when it is retrieved.
web profiles.ihe.net XDS introduced the concept of Delayed Document Assembly Option , and is explained in the Use Cases Summary . The use of Delayed Document Assembly allows source systems to register the existence of stable document content but defer actually assembling the document content only if and when it is retrieved.
web profiles.ihe.net XDS introduced the concept of Delayed Document Assembly Option , and is explained in the Use Cases Summary . The use of Delayed Document Assembly allows source systems to register the existence of stable document content but defer actually assembling the document content only if and when it is retrieved.
web profiles.ihe.net Delayed Document Assembly are indicated in the DocumentReference by the DocumentReference.content.attachment with an .size element of 0 (zero), and a .hash element with the fixed value da39a3ee5e6b4b0d3255bfef95601890afd80709 (SHA1 hash of a zero length file). For more background on the Delayed Document Assembly . There is no need to declare a Delayed Document Assembly in MHD.
web profiles.ihe.net Identifiers in XDS are encoded using the Document Sharing CXi Metadata datatype , which will indicate the kind of identifier. This kind of identifier shall be used when mapping values into DocumentReference elements (See Appendix Z.9.1.2 ). Specifically the CXi Identifier Type Code of urn:ihe:iti:xds:2015:encounterId would indicate the Identifier value be mapped into DocumentReference.encounter.
web profiles.ihe.net Identifiers in XDS are encoded using the Document Sharing CXi Metadata datatype , which will indicate the kind of identifier. This kind of identifier shall be used when mapping values into DocumentReference elements (See Appendix Z.9.1.2 ). Specifically the CXi Identifier Type Code of urn:ihe:iti:xds:2015:encounterId would indicate the Identifier value be mapped into DocumentReference.encounter.
web profiles.ihe.net Resource Bundling shall comply with the guidelines in ITI TF-2x: Appendix Z.1 .
web profiles.ihe.net The security audit criteria are similar to those for the Registry Stored Query [ITI-18] transaction.
web profiles.ihe.net The Document Responder may return other HTTP Status Codes. Guidance on handling Access Denied related to use of 200, 403 and 404 can be found in ITI TF-2x: Appendix Z.7 .
web profiles.ihe.net MHD is based on the IHE Document Sharing model,
web profiles.ihe.net the 3:4.1 Abstract Metadata Model , and
web profiles.ihe.net ebRIM implementation at 3:4.2.3.2 Document Entry .
web profiles.ihe.net with use-cases and constraints found in 3:4.3 Additional Document Sharing Requirements
web profiles.ihe.net ebRIM implementation at 3:4.2.3.4 Folder Attributes .
web en.wikipedia.org Both Bundle.link and Bundle.entry.link are defined to support providing additional context when Bundles are used (e.g. HATEOAS ).
web profiles.ihe.net ebRIM implementation at 3:4.2.3.3 SubmissionSet Attributes .
web profiles.ihe.net with use-cases and constraints found in 3:4.3.1 Submission Metadata Attribute Optionality for
  • MHD Comprehensive Option Document Source
  • aka the XDS Document Source requirements
  • aka the XDR Document Source requirements
web www.omg.org Mappings for ServD ( http://www.omg.org/spec/ServD/1.0/ )
web profiles.ihe.net with use-cases and constraints found in 3:4.3.1 Submission Metadata Attribute Optionality for
  • Document Source implementing not implementing Comprehensive Metadata Option
  • Document Source implementing UnContained Option but not Comprehensive Option
  • equivalent to XDR Document Source implementing Metadata-Limited Option requirements
  • aka the default MHD Document Source
web profiles.ihe.net with use-cases and constraints found in 3:4.3.1 Submission Metadata Attribute Optionality for
  • MHD Document Source that has implemented both Comprehensive Metadata Option and UnContained References Option
web profiles.ihe.net see Appendix Z
web github.com IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted to the Public Comment form .
web www.ihe.net IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted to the Public Comment form .
web github.com As issues are submitted they will be managed on the MHD GitHub Issues , where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).
web wiki.ihe.net As issues are submitted they will be managed on the MHD GitHub Issues , where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).
web www.ihe.net As issues are submitted they will be managed on the MHD GitHub Issues , where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).
web github.com MHD_063 : Should MHD defined CapabilityStatement requirements so that a client can determine that the server supports MHD and which MHD server actor? Today we do require servers to support metadata endpoint returning their CapabilityStatment, but do not require it to contain anything specifically. We could first require that the CapabilityStatment.implementationGuide be populated with MHD canonical IG URL. We could additionally require specific .transaction values for DocumentRecipient, and .rest.resource.supportedProfile for DocumentResponder. Might we need an extension in .transaction to be more specific for Document Recipient? Should a DocumentRecipient need to publish that it is capable of receiving a create/update on these .rest resources (which we only defined thru the transaction, not individually REST)? Might we add an extension on CapabilityStatement.implementationGuide to hold the actor name and options?
web github.com MHD_061 : The new IUA supplement includes guidance on use of OAuth scopes when grouped with MHD. That text updates MHD, but be maintained in MHD until IUA goes Final Text. see https://profiles.ihe.net/ITI/IUA/index.html#33-mhd-profile
web github.com MHD_055 : List.source does not allow for Organization which is needed for SubmissionSet.author. So created an extension (SourceOrg) to hold the SubmissionSet sourceId as a Reference(Organization). This could be reverted if the submitted CR changes R5 https://jira.hl7.org/browse/FHIR-30154
web github.com MHD_058 : The profile requires that the document submitted is encoded in a FHIR Binary. Is there interest in also allowing a Bundle of type Document? This would be useful when publishing FHIR-Documents. The FHIR-Document would still need to be seralized into a Bundle of type Document, but that Bundle would not need to be further encoded into a Binary (e.g. base64 encoding). Note that the mime-type in this case would be forced to be the same mime-type as the ITI-65 Bundle, where a Document Source wants to encode ITI-65 in a mime-type that is different than the document, the Binary methodology would need to be used.
  • note that retrieve (ITI-68) does allow the Document Client to ask for the document content in various mime types, thus allowing support for preferred mime type encoding if the Document Responder has the ability to return the content in a encoding other than the DocumentReference indicates.
web github.com MHD_065 : Is it needed to have a mapping between XDS RegistryError and FHIR OperationOutcome at the element level, and also addressing OperationOutcome.issue.code vocabulary could be mapped to the XDS error vocabulary between XDS https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.4.1 and FHIR OperationOutcome?
web github.com MHD_066 : Note that On-Demand may become supported in FHIR R5 https://jira.hl7.org/browse/FHIR-22501
web github.com MHD_067 : Potential use of $docref operation from HL7 Implementation Guide. This operation is currently in US-Core, and is being added/moved to IPA. It is unclear how MHD would be able to use just this operation without being fully dependant upon all of IPA.
web github.com MHD_068 : Document Source “replace” methodology to better support FHIR backends like MHDS.
web github.com The source code for this Implementation Guide can be found on IHE ITI.MHD Github Repo .
web www.ihe.net Some content from IHE® Copyright © 2015 IHE International, Inc .
Show Usage
web profiles.ihe.net Applications specific to resource-constrained and mobile devices are an emerging platform for healthcare-enhancing software. The MHD Profile is not limited to mobile devices, using the term “mobile” only as a grouping for mobile applications, mobile devices or any other systems that are resource and platform-constrained. These constraints may drive the implementer to use simpler network interface technology. There are numerous deployed implementations of Document Sharing Health Information Exchange that need a simpler network interface technology, for example those hosted by a Health Information Exchange (HIE), large health provider electronic health record (EHR), or personal health record (PHR).
web profiles.ihe.net The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health document sharing (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. In this context, mobile devices include tablets, smart-phones, and embedded devices including home-health devices. This profile is also applicable to more capable systems where needs are simple, such as pulling the latest summary for display. The critical aspects of the “mobile device” are that it is resource-constrained, has a simple programming environment (e.g., JSON, JavaScript), simple protocol stack (e.g., HTTP), and simple display functionality (e.g., HTML browser). The goal is, in part, to avoid burdening the client with additional libraries such as those that are necessary to process SOAP, WSSE, MIME-Multipart, MTOM/XOP, ebRIM, and multi-depth XML.
web profiles.ihe.net The transactions defined here leverage the document content- and format-agnostic metadata concepts that were initially developed for XDS but simplify them for access in constrained environments including mobile devices.
web profiles.ihe.net The transactions defined here leverage the document content- and format-agnostic metadata concepts that were initially developed for XDS but simplify them for access in constrained environments including mobile devices.
web profiles.ihe.net The MHD Profile can be used as an API to a Document Sharing exchange using XDS or XCA . The MHD Profile is used by the MHDS Document Sharing solution. The MHD Profile can be used in push solutions alone or as an API to solutions like XDR or XDM. These are further elaborated in Cross Profile Considerations .
web profiles.ihe.net The Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile combines MHD with the PCC Query for Existing Data for Mobile (QEDm) Profile to provide element level access to the medical information available in a Document Sharing exchange. More details can be found in the white paper on Document Sharing Health Information Exchange .
web profiles.ihe.net The Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile combines MHD with the PCC Query for Existing Data for Mobile (QEDm) Profile to provide element level access to the medical information available in a Document Sharing exchange. More details can be found in the white paper on Document Sharing Health Information Exchange .
web profiles.ihe.net MHD is part of IHE – IT-Infrastructure Domain and part of the IHE Document Sharing Health Information Exchange solution.
web profiles.ihe.net MHD is part of IHE – IT-Infrastructure Domain and part of the IHE Document Sharing Health Information Exchange solution.
web profiles.ihe.net MHD is part of IHE – IT-Infrastructure Domain and part of the IHE Document Sharing Health Information Exchange solution.
web www.google.com Search this IG
web profiles.ihe.net MHD defines Must Support in StructureDefinition profiles as the element, when the minimal cardinality is zero, is R2 Required if Known , as found in Appendix Z . Must Support when the element minimal cardinality is not zero means R .
web gazelle.ihe.net Capability Statement Checks
web gazelle.ihe.net Setup proxy tools
web gazelle.ihe.net Document Recipient without Comprehensive Metadata Option - MHD_11_Toolkit_RecipMinimal
  • Should be Document Recipient declaring UnContained Option can handle it.
web gazelle.ihe.net Document Recipient with Comprehensive Metadata Option - MHD_12_Toolkit_RecipComprehensiv
web gazelle.ihe.net MHD_22_ProvideDocBundle_ITI-65 - Testing of ITI-65
  • alternative flows for Comprehensive Metadata Option and UnContained Option and XDS on FHIR Option
  • alternative flows for Replace, Append, and Transform
web gazelle.ihe.net Document Source with Comprehensive Metadata Option - MHD_13_Toolkit_SourceComprehensive
  • alternative flow for UnContained Option
web gazelle.ihe.net MHD_22a_ITI-65_Resource_Check - AuditEvent tests
web gazelle.ihe.net MHD_25_Create_with_List_Resource – testing Folders
web gazelle.ihe.net MHD_70_Submit_XDSonFHIR - basic ITI-65 test of Document Recipient declaring XDS On FHIR Option
web gazelle.ihe.net MHD_71_XDSonFHIR_Replace
web gazelle.ihe.net MHD_72_XDSonFHIR_Append
web gazelle.ihe.net MHD_73_XDSonFHIR_Transform
web gazelle.ihe.net MHD_30a_ITI-66_Resource_Check - AuditEvent tests
web gazelle.ihe.net MHD_30_FindDocumentLists_ITI-66 - Test ITI-66
  • should be Document Consumer declaring UnContained Option can handle it.
web gazelle.ihe.net MHD_31a-ITI-67_Resource_Check AuditEvent tests
web gazelle.ihe.net MHD_31_FindDocReferences_ITI-67 - Test ITI-67
  • should be Document Consumer declaring UnContained Option can handle it.
web gazelle.ihe.net MHD_33a-ITI-68_Resource_Check AuditEvent tests
web gazelle.ihe.net MHD_32_RetrieveDocument_ITI-68 - test ITI-68
web gazelle.ihe.net MHD_75_QryRetr_XDSonFHIR - The Doc Responder supports the XDS on FHIR and is grouped with an XDS Document Consumer

Internal Images

Figure33.6.1-1.png
Figure33.6.1-1.png
Figure33.6.2-1.png
Figure33.6.2-1.png
Figure33.6.3-1.png
Figure33.6.3-1.png