Working drafts of HL7™ FHIR® Release 3 (STU) artefacts authored and maintained by the Clinical Informatics team at the Australian Digital Health Agency.
Other
11
stars
0
forks
source link
List of Medicine Items with Change Information Authored by Practitioner profile - relax List.entry.flag to 0..1 #74
[x] I have searched open and closed issues to make sure it isn't already requested or reported
[x] I have written a descriptive issue title
The issue / feature
Change description
The profile 'List of Medicine Items with Change Information Authored by Practitioner' (list-sml-pracchanges-1) mandated the element List.entry.flag to be 1..1
External review of the SML specifications to support Pharmacist Shared Medicines List has requested that this be relaxed to optionally allow the List.entry.flag element, rather than mandating it:
List flag is the concept of 'Medicine status' which is optional in the requirements for PSML but is currently mandatory in the implementation guide.
The concern is that this medicine status concept is mainly used in a hospital setting where the status of medicine can be determined by comparing the status of meds between admission and discharge. Hence, the medicine status makes sense in the hospital setting.
However the community pharmacy has no concept of a medicine status and won't be able to default it to anything. If that remains mandatory, then this would force some sort of nonsense value or nullFlavor.
What it actually enables people to do
Instances of List complying to this profile do not have to supply a value for List.entry.flag
How awesome would it be?
This facilitates sending the data that systems can actually sent - greater implementer flexibility.
Prerequisites
The issue / feature
Change description
The profile 'List of Medicine Items with Change Information Authored by Practitioner' (
list-sml-pracchanges-1
) mandated the elementList.entry.flag
to be 1..1External review of the SML specifications to support Pharmacist Shared Medicines List has requested that this be relaxed to optionally allow the
List.entry.flag
element, rather than mandating it:What it actually enables people to do
Instances of List complying to this profile do not have to supply a value for
List.entry.flag
How awesome would it be?
This facilitates sending the data that systems can actually sent - greater implementer flexibility.
Workarounds
nil
Additional context
nil