New Zealand Rheumatic Fever FHIR Implementation Guide - Local Development build (v0.4.8) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
When registering rheumatic fever patients to coordinate care/treatment, Rheumatic Fever Secondary Prevention Service organisations (aka "Lead Providers") seek each patient's consent to:
Receive treatment for the rheumatic fever condition, and
Collection and sharing of data to coordinate treatment and associated health services.
How and when consent is established
Each Secondary Prevention Service organisation seeks consent from patients it registers.
As consent is obtained in writing (form) it is typically deferred for practical reasons until the patient's first secondary prophylaxis encounter.
To handle these scenarios, when consent is officially established after the patient is registered (personal data to be entered into RFCCS), the FHIR API allows for a provisional arrangement in which Consent instances are created in a #proposed status, upgraded to #active when the consent is officially recorded.
Opting out / withdrawing consent
A patient cay choose NOT to receive secondary prophylaxis treatment.
A patient can also DECLINE consent to data sharing (outside of Rheumatic Fever Prevention Services).
When patients opt out of treatment and data sharing, Rheumatic Fever Secondary Prevention services retain patient information for service analysis and in case a 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 that registers that patient in RFCCS.
If a patient transfers to another district and so a different Secondary Prevention Service, data custodianship moves accordingly.
Custodian organisations are granted sufficient privilege (OAUTH scope) by HNZ to create and maintain RF records in the FHIR API.
Consent FHIR data models
Consent obtained from patient
Consent obtained from a related person to the patient (on-behalf)
Patient opted out from data sharing
Provisional consent (yet to be officially obtained from patient)
FHIR consent representation and data access control
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.
How patient consent is represented in FHIR data
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).
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.
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).
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.
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).
When consent is provisional, a special extra actorprovision 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).
How FHIR consent affects access to FHIR data
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.
Criteria for a consent to be valid
When a Consent instance meets the following five criteria, the API allows to the resources it protects:
Has scope Consent.scope = #patient-privacy
Has a #permit provision (not #deny),
Is current (current date must fall within Consent.provision.period start and end dates,
Identifies a Secondary Prevention Service as the custodian of the patient data in Consent.performer,
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:
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
The health application accessing the FHIR API MUST be using client credentials associated with one of the HPI organisations in the CareTeam (6).
What happens when a consent is not valid?
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).
Consent given on-behalf by related person
Sometimes patient consent has to be given by a person related to the patient (eg. children).
These scenarios are handled in FHIR using:
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
An additional Consent.performer[] entry which refers to the RelatedPerson instance.
