Health New Zealand Te Whatu Ora Shared Care FHIR API
0.4.3 - release

Health New Zealand Te Whatu Ora Shared Care FHIR API - Local Development build (v0.4.3) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

## Remote Patient Monitoring

The Remote Patient Monitoring initiative is an initiative the seeks to deliver care to patients in Remote parts of the country, leveraging a Patient facing App and Consumer Technology to record patient wellbeing, with a clinician being able to monitor and provide advice to these patients from afar using the Provider View.

### Remote Patient Monitoring in FHIR

### Data Structure

### Patient Onboarding

The Remote Patient Monitoring Flows and Experience for any given Patient are centered around their CarePlan. At the time of a Patients commencement in the RPM programme this CarePlan along with a series of related resources are created.

### Data Gathering

Throughout the period of care, Questionnaires are used to gather clinical insights into the Patients wellbeing and experience, along with feedback surrounding the quality of experience surrounding the Piki Te Ora App.

Observations are generated via a Series of Smart Devices, that interact with the Piki App, that are then posted to the Shared Care API.

Via the use of the $flat-export function, observations of a given nature can be requested in a flat format, suitable for graphing and aggregations.

### Educational Content

Patients on certain CarePlans may be assigned educational content to engage with.

If a patient is assigned educational content, a series of tasks representing the syllabus, the units that make up the syllabus and the modules that make of the unit are added to the CarePlan as activities.

When a patient completes a given module, unit or syllabus, the status of the task is updated to reflect this.

### Consent Rotation

Given the large number of ongoing resources(Questionnaire Responses and Observations) that are generated by Patients, it may be required for clients to create further consents beyond the one created at patient onboarding time, as these can grow too large. When a client GETs a consent to update it with further data provisions, if it find that this consent will be greater than 10,000 lines (as a rule of thumb), the client should create a new consent.