Scalable Consent Management, published by HL7 International / Community Based Collaborative Care. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-consent-management/ and changes regularly. See the Directory of published versions

Consent Network

Page standards status: Informative

This section provides implementors a functional understanding of how a Consent Network is formed as a result of CONSENT resource sharing across organizations which then requires managing in a collective way which is what this Implementation Guide addresses.

Background

The creation of a Consent resource, regardless of classification, defined by its Consent.category, is by its nature, an extension of a Healthcare consumer's longitudinal patient record and thus treated as PHI as well as a MUST resource exchanged between organizations in a set of Implementation Guides such as PDEX's Payer-to-Payer Exchange, in both (single member) and (bulk).

As these cross-organization exchanges occur, and expand, a relationship chain or "network" of systems is created. This relationship chain is encapsulated through a combination of inheritance and Operational means.

Consent Network Relationship (Inheritance-based)

An inheritance-based relationship is one in which the Consent resource itself encapsulates one side of the relation through a means of retaining the originating system as an attribute of the Consent.

When any System creates and subsequently exchanges a Consent resource with another System, the originating system must convey its identity within the Consent resource itself. Inheritance of the Consent resource received by any system is the encapsulation of the origins of the Consent.

Please refer to the figure below as a functional level depiction of the Inheritance-based relationship.

Each subsequent sharing of the same consent will retain its origin, thus creating an inherent relationship between the system retaining the Consent resource and the system that created the Consent resource irrespective of the system from which the Consent was sent.

For example, if System A created a Consent, System A would add a system identifier to the Consent to establish itself as the manager of the Consent. This originator identifier is encapsulated using the Consent.Manager extension. This attribute denotes to all recipients of the shared Consent what system originated it and in which the results of the consent ceremony were captured regardless of what organization executed the ceremony. Thus, when the Consent resource is shared with another system or systems, a relationship between sender and recipient system(s) is formed.

Consent Network Relationship (Operational based)

Consent resources when shared from System to System operationally instantiate a relationship through the creation of a Subscription within the System from which it was received.

This is achieved through the use of standard FHIR Subscription operations

1. Example sequence

System A shares Consent123 with System B.

System B decides to subscribe to updates to Consent123 in which System A performs

System B creates a Subscription in System A targeted to the resource Consent123

Consent Network Relationship Tree

The inherent network created by the relationships across systems in which the same Consent resource is shared forms a tree of relationships based on the Consent.

The figure below represents a 3 layered Consent Network illustrating this virtual Network Relationship Tree