Minutes - Medication WG 2020-06-23

Attendees

• Jan Lenie
• Tom Henkens
• Marc Buckens
• Annemieke Vergauwe
• José Costa Teixeira
• Karlien Erauw
• Robin Bosman
• Elhassan Baazizi
• Nick Hermans
• Nico Tricarico
• Will van Norel
• Richard Francken

Excused

• Jens Penny

Agenda

• Review of recent updates on medication dispense profile
• Status of medication scheme/medication list
• AOB

Meeting Minutes

• Initial question on cardinalities: suggestion to restrict some cardinalities as there are several 0-many ones (someone suggested to provide a list where this is the case). An additional flag has been added (must support). How widely adopted is the must support flag ? If something is relevant, it should be on the logical model. All clinical relevant information should be in the “must support” fields, is pointed out. We might clarify this in the way of working of HL7 Belgium. Be careful that everything is extendable. There is no simple way of marking that you cannot extend, you have to do it everywhere. If we constrain too much, people will tend to deviate too much.

• Review of recent updates on medication dispense profile, see here

• Identifier – dispense GUID, has now a url for system identification: https://www.gfd-dpp.be/fhir/reference/sguid
• Medication codable concept : we don’t want snomed CT as first coding terminology for dispense (is name for substance, we want product)

• Binding has been removed

• Medication Reference, must support flag: do we refer to CNK level – we should specify that we could only reference BeMedication by using x. Using lot numbers can be done by showing an example, not in the profile
• Performer

• do we want this profile also for preparations ?
• an implicit extension exists
• location of pharmacy: see in example 2

• use contained resource having latitude and longitude
• contained resources are not profiled by HL7 Belgium
• organization resource has address that has an extension, i.e. geolocation
• vendors might not implement it
• should not be required

• NIDHI is not unique. If it is clear in the instance that the NIHDI is a professional/person (=practitioner) or an organization (=pharmacy), then the NIHDI is unique – shouldn’t we include the type to have a unique NIHDI number ? Then everyone has to put a type. Someone suggests that for software it should be clarified if it is a nurse, pharmacy, hospital pharmacy, doctor, … We will have the problem everywhere we use NIHDI so we would need a type everywhere. Using pool, add code or type ? We have to force people to add a type, everywhere in FHIR… https://www.gfd-dpp.be/fhir/NamingSystem/pharmacy/nihdi , use system

• 2 naming systems could be an option to guarantee uniqueness ?

• Naming system NIHDI professionals
• Naming system NIHDI organizations

• Note that there is no instance to lookup NIHDI numbers… people are allowed to prescribe, but not everything, checking if the prescriber was allowed to prescribe sthg must be done at prescription level, not in the medication dispense
• --> take this action point offline (see below)

• Quantity: must support, not mandatory
• Dosage: must support, not mandatory

• Review of Example 1: http://build.fhir.org/ig/hl7-be/hl7-be-fhir-medication/branches/master/MedicationDispense-medication-dispense-example-1.json.html
• Review of Example 2: http://build.fhir.org/ig/hl7-be/hl7-be-fhir-medication/branches/master/MedicationDispense-medication-dispense-example-2.json.html

Do we support the translation of the drug names ? Patient of physician might want to see this in French/other language than standard language, i.e. the language of the resource as indicated in the resource

• Medication code display: is by definition in the language of the resource
• If you want to send content in other language, use std FHIR extension in display

• Action points

• Email discussion on NIDHI (slicing, avoid overkill of slices) – by all, Karlien will initiate email and document
• Add another example with a lot number and a CNK identifier and dguid for product (there can be different lot numbers for same CNK)– by José
• Add example for preparation – need of functional content for this example
• Add more richness to examples, use another language