Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency in some profiles referencing AU profiles, and others not #774

Open
jaymeemurdoch opened this issue Jan 11, 2023 · 2 comments

Comments

@jaymeemurdoch
Copy link
Contributor

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:[email protected]

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?

@dt-r
Copy link
Collaborator

dt-r commented Jan 11, 2023

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
Copy link
Collaborator

F2F comment - would be good to highlight specific issues here and propose fixes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants