This page is part of the Privacy Consent on FHIR (PCF) (v1.0.0-comment: Publication Ballot 1) based on FHIR v4.3.0. . For a full list of available versions, see the Directory of published versions

Privacy Consent on FHIR (PCF) Home

Official URL: https://profiles.ihe.net/ITI/PCF/ImplementationGuide/ihe.iti.pcf				Version: 1.0.0-comment
Active as of 2023-05-04				Computable Name: IHE_ITI_PCF

The Privacy Consent on FHIR (PCF) Profile provides support for patient privacy consents and access control where a FHIR API is used to access Document Sharing Health Information Exchanges.

This includes refinement of the consent handling defined in MHDS. The scope does not intend to cover all consent use cases, such as the consent use cases for within an organization, or more advanced consents that may be addressed in future versions of PCF.

Organization of This Guide

This guide is organized into the following sections:

1. Volume 1: Profiles
   1. 53 Introduction
   2. 53.1 Actors, Transactions, and Content
   3. 53.2 Actor Options
   4. 53.3 Actor Required Groupings
   5. 53.4 Overview
   6. 53.5 Security Considerations
   7. 53.6 Cross Profile Considerations
   8. Appendix P: Privacy Access Policies
2. Volume 2: Transaction Detail
   1. 3.71 Get Access Token [ITI-71]
   2. 3.72 Incorporate Access Token [ITI-72]
   3. 3.102 Introspect Token [ITI-102]
   4. 3.103 Get Authorization Server Metadata [ITI-103]
   5. 3.108 Access Consent [ITI-108]
3. Volume 3: Metadata and Content
   1. 5.8 Privacy Consent Patterns
4. Other
   1. Changes to Other IHE Specification
   2. Updates to ITI-71
   3. Download and Analysis
   4. Test Plan

See also the Table of Contents and the index of Artifacts defined as part of this implementation guide.

Conformance Expectations

IHE uses the normative words: Shall, Should, and May according to standards conventions.

Must Support

The use of mustSupport in StructureDefinition profiles equivalent to the IHE use of R2 as defined in Appendix Z.

mustSupport of true - only has a meaning on items that are minimal cardinality of zero (0), and applies only to the source actor populating the data. The source actor shall populate the elements marked with MustSupport, if the concept is supported by the actor, a value exists, and security and consent rules permit. The consuming actors should handle these elements being populated or being absent/empty. Note that sometimes mustSupport will appear on elements with a minimal cardinality greater than zero (0), this is due to inheritance from a less constrained profile.