Difference between revisions of "Minutes - Medication WG 2020-06-23"
From Health Level 7 Belgium Wiki
KarlienErauw (talk | contribs) |
KarlienErauw (talk | contribs) |
||
| Line 25: | Line 25: | ||
* Initial question on cardinalities: suggestion to restrict some cardinalities as there are several 0-many ones, no list has been provided yet. 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 and are flagged must support. All clinical relevant information should be in the “must support” fields, is pointed out. We might clarify that 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 but you have to do it everywhere. If we constrain too much, people will tend to deviate too much | * Initial question on cardinalities: suggestion to restrict some cardinalities as there are several 0-many ones, no list has been provided yet. 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 and are flagged must support. All clinical relevant information should be in the “must support” fields, is pointed out. We might clarify that 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 but 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 [http://build.fhir.org/ig/hl7-be/hl7-be-fhir-medication/branches/master/StructureDefinition-be-medicationdispense.html here] | * Review of recent updates on medication dispense profile, see [http://build.fhir.org/ig/hl7-be/hl7-be-fhir-medication/branches/master/StructureDefinition-be-medicationdispense.html here] | ||
| − | :: * Identifier – dispense GUID, has now a url for system identification: https://www.gfd-dpp.be/fhir/reference/sguid | + | ::* 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 for first coding terminology for dispense (is name for substance, we want product) | + | ::* Medication codable concept : we don’t want snomed CT for first coding terminology for dispense (is name for substance, we want product) |
:::: o Binding has been removed | :::: o Binding has been removed | ||
::* Medication Reference, | ::* Medication Reference, | ||
Revision as of 09:59, 23 June 2020
Contents
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
- Review of updates on medication 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, no list has been provided yet. 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 and are flagged must support. All clinical relevant information should be in the “must support” fields, is pointed out. We might clarify that 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 but 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 for first coding terminology for dispense (is name for substance, we want product)
- o Binding has been removed
- Medication Reference,
- Performer
- NIDHI is not unique. If it is clear in the instance if the NIHDI is a professional/person (=practioner) or an organization (=pharmacy), then the NIHDI is unique – shouldn’t we include the type to have a unique NIHDI number but then everyone has to put a type. For software it should be clarified if it is a nurse, pharmacy, hospital pharmacy, doctor, … We will have the problem everywhere we use NIHDI. 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
- 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 A resource has a language
- 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 point: offline propose how to handle NIHDI
