Introduction¶
The recording of HeadtoHelp activity in the PMHC MDS will be implemented as an extension to the as yet unreleased core PMHC-MDS version 3 specification. This is to minimise the amount of work required to implement a HeadtoHelp-usable MDS.
The extension will comprise 3 new tables with new fields, and a small number of additions to existing fields in existing record types.
The new tables are HeadtoHelp Episode, HeadtoHelp Service Contact, and IAR-DST Measure.
The extension is intended to be used in two contexts. The HeadtoHelp Intake teams and the HeadtoHelp hubs. Using the same specification for both contexts reduces duplication and reduces the amount of changes required to the MDS in order to capture this new activity type.
Within the PMHC-MDS system a single Victorian intake team and individual hubs will each have their own organisation path and report data against those organisations. It is noted that some HeadtoHelp hubs may be existing provider organisations within the PMHC-MDS. The HeadtoHelp extension is compatible with this reality.
In the Intake context Client, Episode, Collection Occasion, and IAR-DST Measure data would be extracted from the HeadtoHelp Intake system and transformed to match the PMHC-MDS + HeadtoHelp extension specification. Service activity is not submitted in this context. The existing core Episode - Referrer Profession and Episode - Referrer Organisation Type fields are used to record referral in sources. The extension HeadtoHelp Episode - Intake Organisation Path and HeadtoHelp Episode - Intake Episode Key are left blank. Where items in the core PMHC-MDS specification are inapplicable, existing N/A and missing values should be used.
In the hub context the extension specification works almost the same as a service reporting via the core PMHC-MDS specification using the extension fields to identify additional detail regarding referrals in from the HeadtoHelp intake teams (HeadtoHelp Episode - Intake Organisation Path and HeadtoHelp Episode - Intake Episode Key), referrals out to additional services (HeadtoHelp Episode - Referral Out Organisation Type), and the involvement of additional practitioners involved in service contacts (HeadtoHelp - Service Contact - Practitioner Category) which allows multiple endorsements.
HeadtoHelp Episode¶
The model requires a new HeadtoHelp Episode record for every intake process, plus a second new HeadtoHelp Episode record for any subsequent referral to a PMHC MDS reporting service (hub or non-hub). If the intake process results in the client being referred to a service that does not report to the PMHC only the intake record is required. We refer to the two usages as “intake episode record” and “hub episode record”.
The HeadtoHelp Episode table comprises a composite foreign key to link it back to a standard episode record on which all the standard information is recorded plus three new fields. The first two new fields are required only in hub context, the last in both hub and intake contexts.
- The identifier of the intake team (HeadtoHelp Episode - Intake Organisation Path)
- The episode identifier of the intake team (HeadtoHelp Episode - Intake Episode Key)
- The organisation(s) to which the organisation (intake team or hub) refers the client (HeadtoHelp Episode - Referral Out Organisation Type)
Different sets of HeadtoHelp Episode - Referral Out Organisation Type are applicable in intake and hub contexts, but the field values are a fixed superset of both contexts’ legitimate options. The field has been derived from the existing MDS Episode field Episode - Referrer Organisation Type, but with two extra options to accommodate the referral options when exiting the intake process. The new options are HeadtoHelp Hub - for when the intake team refers the client to a hub - and Non HeadtoHelp Hub PHN funded service. The HeadtoHelp Hub option is not applicable in hub context.
HeadtoHelp Episode - Intake Organisation Path and HeadtoHelp Episode - Intake Episode Key are the two fields required to link the hub episode back to the intake episode. These fields must be null on an intake record, but completed on a hub record.
HeadtoHelp Service Contact¶
This new record type is pertinent only to hub activity. Contacts are not recorded against intake episodes. The HeadtoHelp Service Contact extends the existing Service Contact record with two new fields:
- A multi choice HeadtoHelp - Service Contact - Practitioner Category, which allows the type of professionals used in multidisciplinary teams to be recorded against a contact
- The time that the contact started (HeadtoHelp - Service Contact - Start Time)
The HeadtoHelp - Service Contact - Practitioner Category field is in addition to the standard PHMC MDS field for identifying a specific practitioner. The standard model only allows a single practitioner to be recorded against a contact. The extended process still requires identification of a single practitioner (intended to be the ‘main’ one) but also allows capturing the discipline(s) of other practitioners who might be involved. The discipline (practitioner type) of the main practitioner is already stored on an existing table and does not need to be added to the new practitioner categories field.
HeadtoHelp - Service Contact - Start Time is intended to enable identification of activity undertaken during extended hours.
IAR-DST Measure¶
A new record type is required to capture the domains and the recommended level of care pertinent to the IAR-DST that clients have completed for them as part of the HeadtoHelp intake process. A new IAR-DST Measure record, and corresponding collection occasion record, will be created for each intake process.
Consistent with the existing measures in the MDS, the domain scores will be captured as well as the recommended level of care. The purpose of collecting both domain scores and recommended level of care is to:
- allow verification of IAR-DST scoring processes, thereby catching scoring implementation errors early should they arise, and
- provide a resource that can be used to better understand how the IAR-DST scoring algorithm performs in real world environments supporting ongoing improvement of the tool.
Example Data¶
The below example episode data is provided to demonstrate how the specification is used to link the intake and hub episodes. For clarity, not all episode fields have been provided, only those necessary to help describe the linkage. In a proper upload file all fields would need to be provided.
Intake Episodes¶
| organisation_path | episode_key | client_key | episode_end_date | client_consent | episode_completion_status | referral_date |
|---|---|---|---|---|---|---|
| PHN999:Intake01 | CL0001-E01 | CL0001 | 18102020 | 1 | 5 | |
| PHN999:Intake01 | CL0002-E01 | CL0002 | 17122020 | 1 | 5 | 10092020 |
| PHN999:Intake01 | CL0003-E01 | CL0003 | 18122020 | 1 | 1 |
Intake HeadtoHelp Episodes¶
| organisation_path | episode_key | intake_organisation_path | intake_episode_key | referral_out_organisation_type |
|---|---|---|---|---|
| PHN999:Intake01 | CL0001-E01 | 22 | ||
| PHN999:Intake01 | CL0002-E01 | 22 | ||
| PHN999:Intake01 | CL0003-E01 | 16 |
Hub Episodes¶
| organisation_path | episode_key | client_key | episode_end_date | client_consent | episode_completion_status | referral_date |
|---|---|---|---|---|---|---|
| PHN999:Hub01 | AB01CD-E01 | AB01CD | 16122020 | 1 | 4 | 18102020 |
| PHN999:Hub01 | AB01CE-E01 | AC01CE | 1 | 0 | 17122020 |
Hub HeadtoHelp Episodes¶
| organisation_path | episode_key | intake_organisation_path | intake_episode_key | referral_out_organisation_type |
|---|---|---|---|---|
| PHN999:Hub01 | AB01CD-E01 | PHN999:Intake01 | CL0001-E01 | 0 |
| PHN999:Hub01 | AB01CE-E01 | PHN999:Intake01 | CL0002-E01 | 0 |
Data release and confidentiality¶
All data collection and reporting requirements are required to comply with relevant Commonwealth, State and Territory Information Privacy and Health Records regulations. Clients will be informed that some de-identified portions of the information collected through the HeadtoHelp Hubs Service will be utilised for Commonwealth, State and Territory planning and statistical purposes. Appropriate consent and ethics approval processes will be adhered to.