dt-r
commented
1 year ago I agree that the design principle hasn't been correctly applied to the diagnostic profiles - most of them are in conflict with the design principle.
I am not sure any narrative is useful, and the narrative for use case profiles is different to non-use case profiles at this time.
We do have have these decisions recorded, including as tracked in change log that links the previous change (or will as soon as the change log is updated to to list the changes and provide links to where that decision was made). I would be concerned to see decision making / ballot resolution narrative be present in the standard itself.
Is there a set of implementers who are confused on this? So far this discussion is a fairly internal set of concern, and I think the design decision should be applied.
An additional consideration that I would be happy to support is the content of a Design decisions and principles section.
brettesler-ext
Raised as ballot issue for 4.1.0: https://jira.hl7australia.com/browse/FHIRIG-236
This discussion has taken place in the past with the decision to remove references from one AU profile to another, except for specialised use case profiles (ie identifier types or observations) - see https://jira.hl7australia.com/browse/FHIRIG-183. However it was flagged during ballot review that there are some inconsistencies, or instances where AU profiles could be referenced but are not. Below are two examples.
For AU Base Diagnsotic Result; AU Base Imaging Result; AU Base Pathology Result - Observation.baseOn - reference (... ServiceRequest) Given that these are profiles for exchanging Diagnositc Results, the .baseOn elemement should reference AU Base Diagnositic Request or consider adding AU Base Diagnositc Request in addition to ServiceRequest (https://hl7.org.au/fhir/4.1.0-ballot/StructureDefinition-au-diagnosticrequest.html)
The AU Base reports:AU Base Diagnsotic Report AU Base Imaging Report AU Base Pathology Report DiagnosticReport.baseOn - Reference(ServiceRequest | AU Base Diagnostic Request | ...)
For AU Base MedicationAdministration; AU Base MedicationDispense; AU Base MedicationRequest. These profile all include:
slices for medication[x] for PBS, AMT, mimsPackage, gtin They also include slice for medication[x] medicineCodeableConcept medicineReference - reference(mediation) not reference AU Base Medication) What is the purpose of creating an AU Base Medication profile and not to use it in the Request | Dispense | administration profiles? What is | are the reason(s) of creating the slices for medication[x] for PBS, AMT, mimsPackage, gtin in the AU Base Request | Dispense | admin profiles instead of simply include AU Medication profiles (as shown in the following example)? .medication[x] medicationCodeableConcept medicationReference - Reference (medication | AU Base Medication) Reporter:Jaymee Murdoch (on behalf of Agency) Email:jaymee.murdoch@digitalhealth.gov.au
DTR comment: The diagnostic profiles of pathology and imaging are specialised cases. 'Base Diagnostic Report' it, like AU Base Medication or any other 'Base' profile is not a specalised use case.
The earlier design decision ratified in the previous ballot to remove references between non-use case profiles applies to all but specialised use case profiles.
If AU Base Diagnostic Report is to remain a true base profile it should have reference to any base profiles removed but retain reference to specialised use case profiles.
AU Base Diagnostic Request and AU Base Diagnostic Result are also specialised use case profiles - no changes required to be consistent with the design principle on base profiles.
Agency: Can some narrative be added to explain this design decision? What is the criteria for referring to AU profiles?