AIR profiles on Patient / subject have AU IHI rules introduced - impact assessment & design agreement documentation needed
Closed this issue · 3 comments
Prerequisites
- I have verified the problem exists in the available content
- I have searched open and closed issues to make sure it isn't already reported
- I have written a descriptive issue title
The bug
In 2.0.0 additional constraints on identifier population have been added to the AIR profiles only.
Please provide the evidence that the design approach change to the provision and handling logical identifiers for a patient to the Medicare FHIR payload provided by Services Australia to the MHR system has been understood and agreement by parties.
Out of interest was this a requested by NIO or Services Australia? very handy to know if either of those parties were the originator of this request.
Evidence may be satisfied by attachment of emails, or links to other pages etc.
Please identify in the comment the benefit proposition to enforcing these specific constraints.
Please identify in the comment what the expected impact or action is to the rest of the Medicare data provided by Services Australia - has a migration plan been agreed for the others, is this set of changes only to be limited to the AIR portion? Is this now a commitment by the MHR system when or if they surface this data to provide content in this exact way.... are they actually storing the FHIR and thus able to meet this requirement? I thought they threw it away?
What I expected to happen
Evidence of design agreement or reversion of introduced change.
Original response from modelling team 04/03/2021:
- Older Medicare profiles, such as Explanation of Benefit Medicare, have guidance to use a logical identifier for patient, but do not mandate it.
- In the requirements spreadsheet from Farshad that Dusi forwarded to Richard on 20 October 2020 the only data in patient is the patient's IHI.
- The change started on 21/Oct with an invariant GitHub commit, subsequently replaced with structure.
- Confirmed orally that the only patient data is IHI, in a meeting that included NIO staff. MyHR requires IHI to function.
- Modellers decided to add strong and explicit constraints that Patient.identifier is a logical identifier.
- Modellers believed that they were expected to make choices on profiling.
Impacts:
- This should not impact SA or NIO, as long as they continue to do what we believe that they do.
- Using structure to say to use IHIs is clearer than the existing text and also shows how to encode the IHI.
- It is different, and may prompt queries as to why there is a change.
No record that these exact rules match the data provided - the justification noted above 'orally confirmed that only patient data is IHI' is sufficient justification to remove these rules without any further record. Did the 'oral confirmation' including explicitly asking if the addition of these rules was a feature that they wanted?
Justification notes that there is no change to their payload... then there is no reason to introduce these rules that have no obvious basis - I cannot determine why these are an appropriate set of rules for an IHI - that part of the issue description has not been addressed.
Note that moving to an R4 compliant set of content would require change to these rules due to the code system namespace change in R4. This content seems like it should form a backlog for refactoring rather than introducing different handling of a common identifier across the set of profiles.
@dbojicic-agency 26/06/2021: Removed the rules from the Australian Immunisation Register Immunisation and Australian Immunisation Register Notice profiles, and added implementation guidance.