- See Sync for Science and Sync for Genes for more details about the research project use case that pertains to this interoperability need.
- To learn more about how APIs can help patients participate in research, see the Patient Engagement Playbook.
- The Kantara Initiative's UMA (User Managed Access) Work Group project's use case is designed to develop specifications that allow individual control of authorized data sharing and service access to promote interoperability in support of this interoperability need.
- See FHIR, API, and Open API projects in the Interoperability Proving Ground.
- Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
- The SMART on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need.
- When using the SMART on FHIR model, the authentication model is OAuth2. The other security patterns listed do not apply.
|
- System Authentication – The information and process necessary to authenticate the systems involved
- User Details – identifies the end user who is accessing the data
- User Role – identifies the role asserted by the individual initiating the transaction
- Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed
- May be required to authorize any exchange of patient information
- May be required to authorize access and use of patient information
- May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply
- Purpose of Use – Identifies the purpose for the transaction
- Security Labeling – the health information is labeled with security metadata necessary for access control by the end user
|
Submitted by John Moehrke on 2021-09-08
IHE Basic Patient Privacy Consent
The IHE Basic Patient Privacy Consent (BPPC) provides a means for recording the ceremony of patient consenting to a policy. The BPPC profile is normative and widely used to record consent in cross-enterprise settings, such as HIE or research. The BPPC profile includes support for gross coded consent, enabling basic consents to be supported. The IHE normative specification -- https://profiles.ihe.net/ITI/TF/Volume1/ch-19.html 19 Basic Patient Privacy Consents (BPPC) The document sharing infrastructure provided by XD* allow for the publication and use of clinical documents associated with a patient. This profile allows for a Patient Privacy Policy Domain (e.g., an XDS Affinity Domain to have a number of Patient Privacy Policies that can be acknowledged (aka consent). This allows for more flexibility to support some patient concerns, while providing an important and useful dataset to the healthcare provider. Without BPPC, the XDS Profile requires that the administrators of an XDS Affinity Domain creates and agrees to a single document publication and use policy (see ITI TF-1: Appendix L ). Such a single XDS Affinity Domain Policy is enforced in a distributed way through the inherent access controls of the systems involved in the XDS Affinity Domain. This profile will use terms consistent with ISO 22600 - Privilege Management and Access Control (PMAC), but is not restricted to systems that implement PMAC. This profile uses the term “Patient” to refer to the human-subject of health-related data. In this context “Patient” is not to imply only those subjects under current treatment, this is sometimes referred to as “consumer”. This profile uses the term “Consent” to mean acknowledgement of a privacy policy, also known as an information access policy. In this context the privacy policy may include constraints and obligations. The systems involved in XDS are expected to support sufficient Access Controls to carry out the Policy of the XDS Affinity Domain. See the IHE white paper Enabling Document Sharing Health Information Exchange Using IHE Profiles published on the IHE web site. ...