| Pages and organization | Separate display of normative content | True | Pages: ITI-65.html, 1331_actors_and_transactions.html, ITI-67.html, ITI-106.html, ITI-66.html, ITI-105.html, 1333_required_grouping.html, 32_fhir_maps.html, ITI-68.html |
| Pages and organization | Separate display of non-normative content | True | Pages: testplan.html, download.html, artifacts.html, index.html, toc.html |
| Pages and organization | Presence of index page | True | Page: index.html |
| Pages and organization | Presence of toc page | True | Page: toc.html |
| Pages and organization | Presence of artifacts page | True | Page: artifacts.html |
| Pages and organization | Presence of background page | False | No background page |
| Pages and organization | Presence of downloads page | True | Page: downloads.html |
| Writing and narrative | Index page starts with a patient-friendly explanation of the purpose of the IG | True | Extract (page index.html): 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. |
| Writing and narrative | Presence of a section that explains key information that needs to be understood prior to reading the IG | True |
- Extract (page index.html): 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.
- Extract (page 1334_overview.html): 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.
- Extract (page 1335_security_considerations.html): See ITI TF-2x: Appendix Z.8 “Mobile Security Considerations”. When MHD actors also implement actors in the Internet User Authorization (IUA) Profile, there are additional requirements documented in the IUA supplement.
- Extract (page 1336_cross_profile_considerations.html): Considerations when applications group MHD actors with other IHE actors.
- Extract (page ITI-65.html): The Provide Document Bundle [ITI-65] transaction passes a Provide Document Bundle Request from a Document Source to a Document Recipient.
- Extract (page ITI-66.html): This section corresponds to transaction [ITI-66] of the IHE Technical Framework.
- Extract (page ITI-106.html): This section corresponds to transaction [ITI-106] of the IHE Technical Framework.
- Extract (page artifacts.html): This page provides a list of the FHIR artifacts defined as part of this implementation guide.
- Extract (page testplan.html): MHD is an API between four actors. The transactions between actors specify semantics of the data exchanged. The MHD test plan focuses on these semantics and on the expected actions on the server-side actors (Document Recipient and Document Responder). The overall scope of MHD testing is affected by the infrastructure that MHD is connected to.
|
| Writing and narrative | Presence an explanation of what "mustSupport" means for different types of implementations of the IG | True |
- Extract (page index.html): Must Support when the element minimal cardinality is not zero means R.
- Extract (page 1331_actors_and_transactions.html): To claim compliance with this guide, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).
- Extract (page 32_fhir_maps.html): The value of the meta.profile is a soft indicator of conformance expectation. Receivers may choose to validate actual conformance and fail transactions due to non-conformance.
|
| Writing and narrative | Presence of information on how to engage with the community | True |
- Extract (page ITI-65.html): To engage with the community, users can propose a change or submit a new issue. These options are accessible through the provided links on the page, indicating avenues for feedback and collaboration.
|
| Writing and narrative | Presence of an explanation of the relationship of the IG to any other guides | True |
- Extract (page index.html): 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.
- Extract (page 1334_overview.html): 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.
- Extract (page 1335_security_considerations.html): See ITI TF-2x: Appendix Z.8 “Mobile Security Considerations”. When MHD actors also implement actors in the Internet User Authorization (IUA) Profile, there are additional requirements documented in the IUA supplement.
- Extract (page 1336_cross_profile_considerations.html): Considerations when applications group MHD actors with other IHE actors.
- Extract (page ITI-65.html): 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.
- Extract (page ITI-66.html): This section corresponds to transaction [ITI-66] of the IHE Technical Framework. Transaction [ITI-66] is used by the Document Consumer and Document Responder Actors. This transaction is used to locate and return metadata for previously stored document submission sets or folders.
- Extract (page ITI-67.html): This section corresponds to transaction [ITI-67] of the IHE Technical Framework. Transaction [ITI-67] is used by the Document Consumer and Document Responder Actors.
- Extract (page ITI-106.html): This section corresponds to transaction [ITI-106] of the IHE Technical Framework.
- Extract (page artifacts.html): MHD is based on the IHE Document Sharing model, the 3:4.1 Abstract Metadata Model, and the use defined here is FHIR DocumentReference implementation of the ebRIM implementation at 3:4.2.3.2 Document Entry.
- Extract (page testplan.html): MHD does not mandate the functionality to be provided by the data communicated via MHD transactions. How MHD actors use the data communicated via these transaction is out-of-scope for MHD testing, but may apply to other related Implementation Guides or IHE Profiles.
- Extract (page download.html): This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (ihe.iti.mhd.r4) and R4B (ihe.iti.mhd.r4b) are available.
|
| Security and privacy considerations | Presence of a section focused on security or privacy | True |
- Extract (page index.html): Security Considerations
- Extract (page 1331_actors_and_transactions.html): Overview
Security Considerations
- Extract (page 1332_actor_options.html): Overview
Security Considerations
- Extract (page 1333_required_grouping.html): Overview
Security Considerations
- Extract (page 1334_overview.html): The MHD Profile is focused on a subset of the use cases that XDS supports and does not try to reproduce the full scalability, flexibility, privacy, or security supported by a more robust XDS infrastructure.
- Extract (page 1335_security_considerations.html): See ITI TF-2x: Appendix Z.8 "Mobile Security Considerations". When MHD actors also implement actors in the Internet User Authorization (IUA) Profile, there are additional requirements documented in the IUA supplement.
- Extract (page 1336_cross_profile_considerations.html): The proxy might convert user authentication credentials, and fully implement the ATNA Secure Node or Secure Application Actors.
- Extract (page ITI-65.html): 2:3.65.5 Security Considerations
See MHD Security Considerations.
2:3.65.5.1 Security Audit Considerations
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.
- Extract (page ITI-66.html): This transaction should not return information that the Document Consumer is not authorized to access. Where authorization here is inclusive of system, app, and user according to local policy, patient consents, and security layering. However, the transaction may return List resources that have Reference elements that the Document Consumer may not have access to.
- Extract (page ITI-67.html): This transaction should not return information that the Document Consumer is not authorized to access. Where authorization here is inclusive of system, app, and user according to local policy, patient consents, and security layering.
- Extract (page ITI-68.html): 2:3.68.5 Security Considerations
This transaction should not return information that the Document Consumer is not authorized to access.
- Extract (page ITI-105.html): 2:3.105.5 Security Considerations
See MHD Security Considerations.
2:3.105.5.1 Security Audit Considerations
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.
- Extract (page ITI-106.html): 2:3.106.5 Security Considerations
See MHD Security Considerations.
- Extract (page 31_xds.html): Overview
Security Considerations
- Extract (page 32_fhir_maps.html): Security Considerations
- Extract (page artifacts.html): Security Considerations
- Extract (page testplan.html): Security Considerations
- Extract (page download.html): Basic Audit Log Patterns (BALP) Implementation Guide is a Content Profile that defines some basic and reusable AuditEvent patterns. This includes basic audit log profiles for FHIR RESTful operations to be used when there is not a more specific audit event defined. A focus is enabling Privacy centric AuditEvent logs that hold well formed indication of the Patient when they are the subject of the activity being recorded in the log.
- Extract (page toc.html): 6:1:33.5 Security Considerations
|