Health New Zealand Te Whatu Ora Shared Care FHIR API - Local Development build (v0.4.2) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Remote Patient Monitoring
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
CarePlan Activities CarePlan Context Resources Captured Data CommunicationRequest subject : Reference to Patient Task codeText : string[1..1] "Human-readable label" status : code[1..1] "Task status" authoredOn : dateTime[1..1] basedOn : Reference[0..*] "Reference(CarePlan)" subject : Reference[1..1] "Reference(Patient)" owner : Reference[0..1] "Reference(Patient)" requester : Reference[1..1] "Reference(Practitioner)" code : CodeableConcept[1..1] "Bound to RPMEducationalCSVS (syllabus/unit/module)" ServiceRequest subject : Reference to Patient Condition subject : Reference to Patient performer : Reference to Practitioner code : CodeableConcept (TBD) category : CodeableConcept (TBD) Encounter period_start : datetime period_end : datetime diagnosis_condition_reference : Reference to Condition status : string ("in-progress", "finished", etc.) class_code : CodeableConcept (e.g. VR = virtual) serviceType_code : CodeableConcept (e.g. 554 = Chronic Disease Management) priority_code : CodeableConcept (e.g. R = routine) subject : Reference to Patient (with identifier and display) participant : Reference to Practitioner (identifier + display) reasonCode : CodeableConcept (e.g. patient-initiated encounter) serviceProvider : Reference to Organization (identifier + display) CareTeam meta_versionId : string meta_profile[] : string identifier_use : string identifier_system : string identifier_value : string participant_member_identifier_use : string participant_member_identifier_system : string participant_member_identifier_value : string participant_member_display : string managingOrganization_identifier_value : string managingOrganization_identifier_use : string managingOrganization_identifier_system : string managingOrganization_display : string status : string ("active", etc.) name : string ("Remote Monitoring CareTeam") participant_member_type : string ("Practitioner") managingOrganization_type : string ("Organization") Observation subject : Reference to Patient basedOn : Reference to CarePlan QuestionnaireResponse subject : Reference to Patient basedOn : Reference to CarePlan Consent subject : Reference to Patient period optional provisionData : Reference[] CarePlan meta_profile : "RPM CarePlan" subject : Reference to Patient condition : Reference to Condition activity : Reference[] Provenance addresses.reference encounter.reference careTeam.reference activity.reference activity.reference activity.reference relevantHistory basedOn basedOn
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.
AdminPractitioner Practitioner View Shared Care FHIR Server Queue Common Messaging Service Patient Alphero App Education Content Bucket AdminPractitioner AdminPractitioner Practitioner View Practitioner View Shared Care FHIR Server Shared Care FHIR Server Queue Queue Common Messaging Service Common Messaging Service Patient Patient Alphero App Alphero App Education Content Bucket Education Content Bucket Patient Onboarding Inital Encounter POST Condition POST Encounter POST CareTeam POST Task POST Consent Create CarePlan Search Plan Definitions Apply Plan Definition, with patient, practitioner, and encounter POST CarePlan PUT Consent, attaching CarePlan Add Service Requests Search Activity Definitions Apply Action Definition, with patient, practitioner, and CarePlan POST Service Request PUT Consent, attaching Service Request PUT CarePlan, attaching Service Request Patient Notification via CMS POST CommunicationRequest Handle incoming Communication Request POST CommunicationRequest (via Subscription) Send Email POST Communication (inidcating email sent)
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.
AdminPractitioner Practitioner View Shared Care FHIR Server Queue Common Messaging Service Patient Alphero App Education Content Bucket AdminPractitioner AdminPractitioner Practitioner View Practitioner View Shared Care FHIR Server Shared Care FHIR Server Queue Queue Common Messaging Service Common Messaging Service Patient Patient Alphero App Alphero App Education Content Bucket Education Content Bucket Routine Questionnaire Response Collection Opens App Fetches relevant Questionnaire Render Questionnaire Completes Questionnaire POST QuestionnaireResponse PUT Consent
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.
Practitioner View Shared Care FHIR Server Piki te Ora Patient Education Content Bucket Practitioner View Practitioner View Shared Care FHIR Server Shared Care FHIR Server Piki te Ora Piki te Ora Patient Patient Education Content Bucket Education Content Bucket Patient Onboarding POST CarePlan and Associated resources POST Top Level Task (Syllabus) POST Unit Level Tasks POST Module Level Tasks PUT CarePlan (attaching tasks) Educational Content Consumption Opens App, Selects and Consumes Module Fetches Education Content Render Content Completes Module GET Task?code=exampleModuleCode&owner=nhi&profile=rpmEducationalTask PUT Task (module Task.status=completed) alt [Update Parent Tasks Directly] Client knows all modules/units are completed, so it directly updates the parent Task(s) to completed PUT Unit Task (status=completed) PUT Syllabus Task (status=completed) Complete Feedback Questionnaire POST QuestionnaireResponse (completed) Provider View Rendering GET CarePlan GET Task?basedOn=CarePlan/example&owner=nhi&profile=rpmEducationalTask
When a patient completes a given module, unit or syllabus, the status of the task is updated to reflect this.
CarePlan: Education Plan id = "careplan-education" status = "active" intent = "plan" description = "Care plan defining the patient's educational syllabus" Task: Educational Syllabus id = "task-syllabus" Task: Group 1 id = "task-group-1" Task: Module 1.1 id = "task-module-1-1" Task: Module 1.2 id = "task-module-1-2" activity basedOn activity basedOn activity basedOn activity basedOn partOf partOf partOf
