Tupaia

Background

Tupaia is an extension of the Whanau Ora programme, designed to fund health interventions for Whanau Ora clients. Specifically it is designed to highlight needs for the following issues/areas, and then fund treatment options:

1. Dental
2. Eye
3. Long-term conditions (LTC)
4. Surgery
5. Mental health.

Configuration

Data capture and reporting for this programme has been rather a PITA, to be quite honest. The current model is as follows:

• Needs assessment is initially done by Whanau Ora navigators using an MS Forms form.
• A Flows flow simply emails the text of this assessment back to the submitter.
• This flow also adds some 'codes' to the form, depending on question responses. This component is intended to flag needs which can be picked out from note data once entered into Indici (see below).
• The email response can then be copy-pasted into one of the bazillion systems that Whanau Ora is required to use. Specifically, in this case:
  • Indici
  • Penelope - the Whanau Ora CMS forced upon us by the funder
  • Aiga - K'aute's current in-house CMS.
• The codes are subsequently pulled out of QuickConsult data when it comes through overnight. Postgres function rpt.fn_tupaia() executes the following steps:
  • Pulls out the client details of anyone having QuickConsult data containing specified keywords indicating an assessment has been completed
  • Cohort is separated by children (18yrs and under) and adults
  • Subsequently codes for all the above 5 pathways are searched in turn
  • Summary data is then written to rpt.tupaia_overview.

This will present a table of unique individuals with a range of columns flagging which codes have been assigned to them.

Note that codes are always assigned manually (even from the initial assessment, code assignment is based on question response). The current list of codes and meaning is:

Pathway	Code	Description
Long term conditions	LTC1	LTC need is identified
Long term conditions	LTC2	Follow-up with GP booked
Long term conditions	LTC3	LTC needs dealt with by GP
Long term conditions	LTC4	Patient will follow up with their own GP
Eye	EYE1	Eye needs identified
Eye	EYE2	Clinic follow-up is booked
Eye	EYE3	Eye needs have been treated
Eye	EYE4	Decline/NA
Dental	DEN1	Dental needs identified
Dental	DEN2	Dental appointment booked
Dental	DEN3	Dental treatment completed
Dental	DEN4	Decline/NA
Surgical	SUR1	Surgery need identified
Surgical	SUR2	Surgery is booked
Surgical	SUR3	Surgery has been completed
Surgical	SUR4	On public waitlist
Mental health	MH1	Mental health needs identified
Mental health	MH2	Appointment with psychologist booked
Mental health	MH3	Mental health treatment plan completed
Mental health	MH4	Mental health support is declined

Finally, a reporting summary is prepared using view rpt.vw_tupaia. Currently this is used as the sole data source for overview/detail reporting into Power BI.

Available data

Domains of available structured data are shown below:

Domain	Field	Description
Assessment	Person identifier	NHI and Indici PatientID
Assessment	Person details	Name, location, age etc.
Assessment	Date	Date of assessment entered in Indici
Assessment	Identified needs	Flag for one of 5 needs pathways based on code in Indici
Treatment	Treatment booked	Flag indicating booking for any pathway
Treatment	Treatment complete	Flag indicating pathway complete (reliant on manual data entry)
Treatment	Treatment decline or not eligible	Depending on pathway, patient is either not eligible or declines intervention
Treatment	Treatment booked	Flag indicating booking for any pathway
Treatment	Treatment activity	Interactions recorded in Indici for GP/Psychology interventions
Treatment	Treatment detail	For Dental/Eye pathways, invoice snapshots let us summarise 'acuity' or complexity of treatments
Screening	Identified needs	Flag patient does not have current screening
Costs	Treatment costs	For Dental and Eye only, summary data on treatment costs

Views using above structured data are available in the Power BI app (or on-demand) to show summary data such as:

• Proportion of assessed people needing a treatment pathway
• Of these, currency of booking and treatment status
• Proportion of people 'completed' for specific pathways or all identified needs
• Screening/needs/treatment volumes
• Time series of assessment volumes
• Impact on service delivery by team.

Issues

Since this is a fairly manual process, it is particularly dependent on data entry and timely access to data.

Now that rpt schema functions are being run via pg_cron, execution times are static and not stateful. Because the arrival time of incoming Indici data is quite variable, this has caused some problems. Currently the deduplication job for quickconsult and patient data runs at 0300 and 0700, with the rpt.fn_tupaia() job running an hour later.

There have also been occasions where Valentia have incorrectly sent empty files. Please check data in indici_staging.auditlog as well as inspecting S3 content where necessary if there are any suspicions about missing data. Issues around missing data can be raised with Indici helpdesk.