New Zealand Rheumatic Fever FHIR Implementation Guide
0.4.7 - draft

New Zealand Rheumatic Fever FHIR Implementation Guide - Local Development build (v0.4.7) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Consent Based Access Control

Business requirements overview

To register rheumatic fever patients and coordinate treatment, Rheumatic Fever Secondary Prevention Services (aka "Lead Providers") seek each patient's consent to:

  1. Receive treatment for the rheumatic fever condition, and
  2. Collection and sharing of data to coordinate treatment and associated health services.

Each Secondary Prevention Service organisation seeks these consents for its registered patients.

As the consent is obtained in writing (form) it may be deferred for practical reasons until the patient's first secondary prophylaxis encounter. This means there can be a delay between registering a patient (which requires personal data to be entered into RFCCS) and officially obtaining consent.

In these scenarios some kind of provisional protection is required to prevent data sharing outside of Rheumatic Fever Secondary Prevention services.

A patient may choose not to receive secondary prophylaxis treatment.

A patient can also elect not to give consent for data sharing (outside of Rheumatic Fever Prevention Services).

If a patient opts out of treatment and data sharing, Rheumatic Fever Secondary Prevention services, under current arrangements, retain the patient's information for analysis and in case the patient subsequently resumes treatment.

Custodianship of patient health data

The custodian of a rheumatic fever patient's data is the Rheumatic Fever Secondary Prevention Service organisation they are primarily registered with.

If a patient transfers to another district and so a different Secondary Prevention Service, the custodianship of the data also moves accordingly.

The significance of custodianship here is that it determines which parties have administrative access to rheumatic fever data which here means privileges like:

  • creating care plans
  • planning and adjusting secondary prophylaxis medication
  • scheduling appointments
  • recording patient's treatment preferences and allergies
  • monitoring the delivery of secondary prophylaxis treatment
  • coordinating other services that may be needed

Data is synchronised between RFCCS and FHIR by integration logic.

In the course of this synchronisation, patient-specific Consent instances are formed in the FHIR API.

  1. Each patient's expressed consent is represented as a pair of FHIR Consent instances
    • scope #patient-privacy (consent to collect/share data)
    • scope #treatment (consent to receive treatment).
  2. Each Consent instance has a provision of type #permit which identifies the patient (by NHI) and defines the period of their consent as a date range.
  3. The data collection/sharing Consent has in its provision a list of FHIR references which identify all the other FHIR resource instances this consent 'covers' (applies to).
  4. The status of the Consent instances can vary:
    • If patient consent has been obtained, the status of the instances is #active
    • If consent is anticipated but not yet obtained, the status of the instances is #proposed (a provisional arrangement)
    • When consent is denied / withdrawn, the status is #active BUT all #permit-type provisions are replaced with #deny-type provisions.
  5. Every consent identifies a performer as the party that is primarily responsible for upholding the policies consented-to. This will identify the Rheumatic Fever Secondary Prevention Service organisation (by HPI org ID).
  6. When consent is provisional, a special extra actor provision is added to the data FHIR Consent instance. This actor identifies a CareTeam whose members are all the Secondary Prevention Service organisations that will have provisional access to data (before consent is officially obtained from the patient).

The API performs consent-based data access control to instances of the following FHIR resources types (includes instances using profiles):

  • Appointment
  • CarePlan
  • Condition
  • Encounter
  • ServiceRequest
  • QuestionnaireResponse
  • Observation
  • Patient
  • Person / RelatedPerson

Every time an API-consuming application interacts with a FHIR resource instance of one of the above types, the API searches to find any Consent instances that refer to that instance:

  • If a valid Consent exists, the FHIR interaction can proceed,
  • If no valid Consent exists, the interaction does not proceed and a 403 Forbidden error is returned,
  • If the resource instance being surfaced is the result of a FHIR Search interaction, it will be redacted from the FHIR search results Bundle unless it is covered by a valid Consent.

When a Consent instance meets the following five criteria, the API allows to the resources it protects:

  1. Has scope Consent.scope = #patient-privacy

  2. Has a #permit provision (not #deny),

  3. Is current (current date must fall within Consent.provision.period start and end dates,

  4. Identifies a Secondary Prevention Service as the custodian of the patient data in Consent.performer,

  5. Identifies a patient as subject (Consent.patient is a logical reference by NHI identifier).

In the case of a provisional consent (Consent status = #proposed) there are two further criteria:

  1. The proposed consent MUST include a provision referencing a CareTeam which identifies the Rheumatic Fever Secondary Prevention Services (as HPI organisation ids) which are custodians of patient data, AND
  2. The health application accessing the FHIR API MUST be using client credentials associated with one of the HPI organisations in the CareTeam (6).

The API returns HTTP 401 Unauthorized or 403 Forbidden errors, depending on the operation being requested.

In FHIR search operations, instances in search results which are not properly covered by consents are REDACTED (are counted as matches, but not included in the results Bundle).

Sometimes patient consent has to be given by a person related to the patient (eg. children).

These scenarios are handled in FHIR using:

  1. A RelatedPerson resource identifying the related party (by name is sufficient) and their relationship to the patient. The RelatedPerson instance can be contained inside the Consent instance, and
  2. An additional Consent.performer[] entry which refers to the RelatedPerson instance.

Example data models

FHIR Consent instances for confirmed patient consent Representation of consent when confirmed by patient's signed form Patient data covered by data access provision2Consent to treatment:CONSENTstatus:#ACTIVEscope:#treatmentpolicy: reference to regs/leg.treatment provisiontype:#PERMITperiod:2023-01-21to2026-01-20Consent to collect/share data:CONSENTstatus:#ACTIVEscope:#patient-privacypolicy: reference to regs/leg.data access provisiontype:#PERMITperiod:2023-01-21to2026-01-20«logical reference»NHI patient:PATIENTlogical id: NHI«logical reference»Rheumatic fever prevention service(custodian org):ORGANIZATIONHPI Org Id:GnXnnnplanned appointments, etc.:CAREPLAN security label:R (restricted)condition severity and specifics:CONDITION security label:R (restricted)appointments:ENCOUNTER                                security label:R (restricted)preferences, health assessments:QUESTIONNAIRERESPONSE security label:R (restricted)diagnosis detail:OBSERVATION                          security label:R (restricted) .provision .data.reference2 .patient3 .organizationHPI org. ref1 .patient .provision .organizationHPI org. ref1Notes1. Consent instances identify the data subject in.patientreferences.2.Consent.organizationidentifies which org is custodian of the patient data.3. All patient data stored in R-labelled resource instances.4. The custodian organisation must obtain administrative privilege (parameterizedOAUTH scope) to updateR-labelledresource types (including label changes).Health NZ/Te Whatu Ora. FHIR instance data model generated from PlantUML source on 08/08/2024



FHIR Consent instance data - on-behalf consent Representation of patient consent when given on behalf by a related person Patient data covered by data access provision2Consent to treatment:CONSENTstatus:#ACTIVEscope:#treatmentpolicy: reference to regs/leg.treatment provisiontype:#PERMITperiod:2023-01-21to2026-01-20Consent to collect/share data:CONSENTstatus:#ACTIVEscope:#patient-privacypolicy: reference to regs/leg.data access provisiontype:#PERMITperiod:2023-01-21to2026-01-20«contained»person giving consent:RELATEDPERSON4name.given:Berylname.family:Hackettrelationship:#PRN«contained»person giving consent:RELATEDPERSON4name.given:Berylname.family:Hackettrelationship:#PRN«logical reference»NHI patient:PATIENTlogical id: NHI«logical reference»RF Secondary Prevention Service(custodian org):ORGANIZATIONHPI Org Id:GnXnnnplanned appointments, etc.:CAREPLAN security label:R (restricted)condition severity and specifics:CONDITION security label:R (restricted)appointments:ENCOUNTER                                security label:R (restricted)preferences, health assessments:QUESTIONNAIRERESPONSE security label:R (restricted)diagnosis detail:OBSERVATION                          security label:R (restricted) .provision .data.reference2 .patient3 .organizationHPI org. ref1 .performer4 .patient .provision .organizationHPI org. ref1 .performer4 Notes1.Consent.organizationidentifies a specificRF Secondary Prevention Servicewhich:    a. Coordinates treatment for patients in that district/region, and    b. Operates the consent process (forms etc.), and    c. Is the custodian of data collected from these patients.2. This list of referenced FHIR instances is maintained by Mulesoft integration.3. All Consent instances identify via.patienttheperson the consent applies to.4. Note the RelatedPerson instance is contained within AND linked from (via .performer) the Consent instance. Health NZ/Te Whatu Ora. FHIR instance data model generated from PlantUML source on 08/08/2024



Patient opted out from data sharing

FHIR Consent instances for patient opted-out (of treatment / data sharing) Representation of consent denied (or withdrawn) by patient Patient data covered by data access provision2Consent to treatment:CONSENTstatus:#ACTIVEscope:#treatmentpolicy: reference to regs/leg.treatment provisiontype:#PERMITperiod:2023-01-21to2026-01-20Consent to collect/share data:CONSENTstatus:#ACTIVEscope:#patient-privacypolicy: reference to regs/leg.data access permit provisiontype:#DENYperiod:2023-06-23to-«logical reference»NHI patient:PATIENTlogical id: NHI«logical reference»RF Secondary Prevention Service(custodian org):ORGANIZATIONHPI Org Id:GnXnnnplanned appointments, etc.:CAREPLAN security label:R (restricted) security label:break-the-glasscondition severity and specifics:CONDITION security label:R (restricted) security label:break-the-glassappointments:ENCOUNTER                                security label:R (restricted) security label:break-the-glasspreferences, health assessments:QUESTIONNAIRERESPONSE security label:R (restricted) security label:break-the-glassdiagnosis detail:OBSERVATION                          security label:R (restricted) security label:break-the-glass .provision .data.reference2 .patient3 .organizationHPI org. ref1 .patient .provision .organizationHPI org. ref1Notes1. Consent instances identify the data subject in.patientreferences.2.Consent.organizationidentifies which org is custodian of the patient data.3. All patient data stored in resource instances withRandbreak-the-glasslabels.4. The custodian organisation must obtain administrative privilege (parameterizedOAUTH scope) to updateR-labelledresource types (including label changes).5. Any other authenticated API consumer wanting to read data in these labelled instancesmustbreak the glass(request a break-glass parameterized OAUTH scope).Health NZ/Te Whatu Ora. FHIR instance data model generated from PlantUML source on 08/08/2024



FHIR Consent instances when patient consent is pending Representation of limited provisional consent when patient's signed form pending but not received Patient data covered by temporary data access provision2consent to treatment:CONSENTstatus:#PROPOSEDscope:#treatmentpolicy: reference to regs/leg.treatment provisiontype:#PERMITperiod:2023-01-21to2026-01-20Consent to collect/share data:CONSENTstatus:#PROPOSEDscope:#patient-privacypolicy: reference to regs/leg.data access provisiontype:#PERMITperiod:2023-01-21to2026-01-20«logical reference»NHI patient:PATIENTlogical id: NHI«logical reference»RF Secondary Prevention Service(custodian org):ORGANIZATIONHPI Org Id:GnXnnnplanned appointments, etc.:CAREPLAN security label:R (restricted)condition severity and specifics:CONDITION security label:R (restricted)appointments:ENCOUNTER                                security label:R (restricted)preferences, health assessments:QUESTIONNAIRERESPONSE security label:R (restricted)diagnosis detail:OBSERVATION                          security label:R (restricted) .provision .data.reference2 .patient3 .organizationHPI org. ref1 .patient .provision .organizationHPI org. ref1Notes1. Consent instances identify the data subject in.patientreferences.2.Consent.organizationidentifies which org is custodian of the patient data.3. Start date is when the custodian provisionally-assumes consent to start;End date is empty (provision doesn't expire).4. All patient data stored in R-labelled resource instances whichonly the custodian     org can access while consent is pending.5. The custodian organisation must obtain administrative privilege (parameterizedOAUTH scope) to updateR-labelledresource types (including label changes).Health NZ/Te Whatu Ora. FHIR instance data model generated from PlantUML source on 08/08/2024