Australian Medicare FHIR Consent Directive Use Case and xml examples by Russell McDonald
Back to HL7 FHIR Consent Directive Project
Back to FHIR Consent Directive Use Cases
FHIR Consent Directive AU Examples
Background
There are four parties here - patient, GP, third party Care Planning company, and Telstra Health. We want the Care Planning company to send Telstra Health the GP's data (which they extract from the GP system) about the Patient's data, along with the Care Plan that the GP created on the third party's system.
Scenario 1 - patient sees GP; needs a Care Plan; agrees to use third party Care Planning company. Whilst creating the care plan, GP asks patient 'Are you interested in viewing your care plan on your mobile phone/tablets and update it yourself, using a Telstra Health service?'. If patient says 'yes', then GP ticks box in care plan, which is saved by Care Planning company.
Action: Consent Directive - pre-registration (consent to be contacted by Telstra Health) sent from Care Planning company to Telstra Health - Bundle containing minimal Patient details and Contract. [NOTE: receipt of the Contract resource by Telstra Health from Care Planning company is deemed evidence that consent has been given, which can be traced back to an audit log of the GP (witness to consent) ticking a box on a web form]
Scenario 2 - Telstra Health contacts patient and asks if they agree to Telstra Health's Ts&Cs (which include consent for all data to be sent from Care Planning company to Telstra Health and consent for Telstra Health to hold all patient data forever, plus consent for Telstra Health to provide de-identified and summarized copies of the patient data to the State or Federal government if so requested). Patient ticks 'agrees to Ts&Cs' - including all the 'fine print'.
Action: Consent Directive - post-registration (consent to sending all data from Care Planning company to Telstra Health) sent from Telstra Health to Care Planning company. [NOTE: receipt of the Contract resource from Telstra Health by Care Planning company is deemed evidence that consent has been given, which can be traced back to an audit log from Telstra Health systems of the patient ticking a box on a web form]
P.S. - when we started this (DSTU Version 0.4.0) type and subtype had meaningful codes (Security-Privacy) and (Consent-Directive). The move to DSTU 2 (1.0.1) has made these less meaningful. Now I was WRONG! - we can't pick any coding system we like for type and subType - they are tied to specific HL7 FHIR valuesets. HOWEVER, these are 'example' so we can add to them. The problem, as I see it, is pre-coordination and post-coordination. I don't think a two level coding system is going to cut the mustard. You end up with 20 type codes for various types of Consent, each of which has a limited subset to subType codes. Or you have one type code for 'Consent' and 80 subType codes to cover off all the permutations and combinations. Furthermore you have term.type and term.subType which could conflict with type and subType! Perhaps these should be term.termType and term.termSubType which must be consistent with type and subType and provides levels 3 and 4 of granularity for the 'Type of Consent'?
