| Pages and organization | Separate display of normative content | True | Pages: security.html, conformance.html, artifacts.html |
| Pages and organization | Separate display of non-normative content | True | Pages: downloads.html, toc.html, change-log.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): This specification describes how an application acting on behalf of a patient can access information about the patient from a clinical records system using a FHIR R4 based API. |
| 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): This specification describes how an application acting on behalf of a patient can access information about the patient from a clinical records system using a FHIR R4 based API.
- Extract (page conformance.html): Note: Readers are advised to understand FHIR Terminology requirements, FHIR RESTful API based on the HTTP protocol, along with FHIR DataTypes, FHIR Search and FHIR Resource formats when implementing IPA requirements.
- Extract (page synchronization.html): Many applications that access patient records keep a synchronized copy of the patient record elsewhere. To make this a safe process, application developers should code defensively. Notably, there are a few surprising reasons why a FHIR server may no longer return previously accessible resources.
- Extract (page internationalization.html): The International Patient Access specification provides an underlying base specification intended to be localized by individual countries to meet national laws, regulations, and accepted practices.
- Extract (page security.html): This specification depends on Smart App Launch which profiles an OAuth 2.0 authorization process, such that the user decides what access to grant to the application that they are using.
|
| Writing and narrative | Presence an explanation of what "mustSupport" means for different types of implementations of the IG | True |
- Extract (page index.html): This page describes the rules to claim conformance to this guide and defines the expectations for must-support elements in the IPA Profiles.
- Extract (page conformance.html): Must Support and Obligations
In the context of IPA, Obligations defines how an actor (Server or Client) must “support” a given element. All MustSupport elements in this publication are accompanied by an explicit obligation, which identifies structured expectations for a given actor. If a MustSupport element has no obligation for a given actor, that element need not be supported by that actor. Obligations can be found in the formal view section of a resource.
- Extract (page internationalization.html): The authors of the specification welcome feedback and suggestions on what should be required of implementations.
- Extract (page security.html): This specification labels some elements as must-support. This does not override the patient's right to decide whether to authorize an application to access their information.
- Extract (page change-log.html): This release changes Patient.identifier's MustSupport Obligation to "SHALL: explain", which deviates from the previous default, narrative definition of MustSupport. Removed the default MustSupport requirement for the Client actor from the following elements: AllergyUIntolerance.patient, Condition.category, Condition.subject, DocumentReference.date, MedicatioNRequest.intent, MedicationRequest.encounter, MedicationRequest.authoredOn, MedicationStatement.context, Patient.identifier.value, patient.active, patient.name, Practitioner.name, PractitionerRole.practitioner.
|
| Writing and narrative | Presence of information on how to engage with the community | True |
- Extract (page index.html): This project intends to create and maintain a registry of FHIR implementation guides consistent with IPA as countries adopt it in their national FHIR standards.
Declaring support for IPA
As jurisdiction-specific FHIR profiles proliferate, specification authors should strive to build on top of IPA to better serve their implementors, caregivers, and patients.
- Extract (page conformance.html): Feedback to IPA is encouraged on the use of Obligations and generally how IPA can be more useful for local use-cases.
- Extract (page internationalization.html): The authors of the specification welcome feedback and suggestions on what should be required of implementations.
|
| Writing and narrative | Presence of an explanation of the relationship of the IG to any other guides | True |
- Extract (page index.html): This International Patient Access specification describes how to access patient records worldwide. It provides a very minimal set of access methods and content rules that are true everywhere. Jurisdictions are encouraged to use this specification directly and may also publish their patient access specifications that further refine the profiles in this implementation guide.
- Extract (page conformance.html): Because IPA is a foundational standard – consideration is given to implementation guides, their authors and implementors that inherit from IPA.
- Extract (page fetching.html): If a server conforms to this specification and also to IPS, this API can be used to generate IPS documents, using the $docref operation with a specific code as defined in the IPS implementation guide.
- Extract (page internationalization.html): The International Patient Access specification provides an underlying base specification intended to be localized by individual countries to meet national laws, regulations, and accepted practices.
|
| Security and privacy considerations | Presence of a section focused on security or privacy | True |
- Extract (page index.html): Security and Privacy: This page documents the IPA security requirements and discusses patient privacy and safety topics.
- Extract (page conformance.html): Security and Privacy
- Extract (page access.html): Security and Privacy
Artifact Index
SMART on FHIR Obligations and Capabilities:
An application is authorized to access a patient record using the SMART App Launch Protocol's standalone launch sequence.
- Extract (page fetching.html): Security and Privacy
Once an application has obtained access to the patient record with a SMART on FHIR access token, it can find and retrieve information about the patient. Initial Patient Identity Check
The first thing the application should do is retrieve the patient record it has obtained access to and confirm that it is about the right patient. ... If the app suspects it has been incorrectly granted access, consider: informing the resource server owner, aborting the workflow without showing data to the current user, and looking to local jurisdictional policies for guidance.
- Extract (page synchronization.html): Security and Privacy
To make this a safe process, application developers should code defensively. Notably, there are a few surprising reasons why a FHIR server may no longer return previously accessible resources: ... The record was marked as "confidential" on the server side, and the policy is not to provide access to confidential information across the API.
- Extract (page internationalization.html): Security and Privacy
- Extract (page security.html): Servers and clients SHALL follow the security requirements and SHOULD follow the security best practices as outlined in FHIR Security and elsewhere.
- Extract (page artifacts.html): Security and Privacy
- Extract (page downloads.html): Security and Privacy
- Extract (page change-log.html): Release 1.0.0 was the first trial use publication of the HL7 IPA IG, towards a goal of helping patients access their data through universal realm FHIR APIs and SMART (OAuth 2.0) security mechanisms useable in any region in the world.
- Extract (page toc.html): 4 Security and Privacy
|