We hebben deze pagina gebruikt om initiele bevindingen te documenteren als voorbereiding/scratchpad op de FHIR NL Criteria check en Jira taak.
Respons van ZIBcentrum team:
Medicatiegerelateerde HN-6 - Getting issue details... STATUS
| Bespreking/Conclusie validatieteam | FHIR element | ZIB | Reviewer Bevinding / Opmerking | |
|---|---|---|---|---|
| 1 | Dit is conform de FHIR profiling guidelines van Nictiz voor R4. Het is een duivels dilemma tussen maximale validatie en sturing van implementatie en de ambitie van de profielen om generiek te zijn. Het generieke karakter maakt ze 'open'. Je kunt er dan een specifiekere overheen leggen indien gewenst voor implementatie-ondersteuning. >>algemene vraag/suggestie: misschien zouden de zibs meer met oog op implementeerbaarheid moeten worden ontworpen. Als niet in zibs zelf, dan door IG toe te voegen voor relevante voorbeeld use cases? | MedicationRequest.requester | https://zibs.nl/wiki/MedicationAgreement-v1.2(2020EN) MedicatieAfspraak | ZIB (eigenlijk standaard MP) definieert voorschrijver als zorgverlener die bevoegd is tot voorschrijven medicatie. //////////// Algemene opmerkingen over references: ZIb modelleerkeuze om gerefereerde ZIBs niet te 'profileren'. is in context van medicatieproces (MP) NB requester referefeert naar zib HealthProfessional Reference (... | ...| etc) in vergelijking: Reference(Medication| zib PharmaceuticalProduct) Wat betekent dat? zorgverlener reference is wel ingeperkt? Verwarrend verschillende aanpak Reference. 1 zoals andere References en 1 met een pattern die niet overeenkomt met het zib element. Implicaties toelichten met name voor implementeren. |
| 2 | Goed punt. Zib ticket aangemaakt https://bits.nictiz.nl/browse/ZIB-1653 | MedicationRequest.requester | MedicatieAfspraak | formulering in zib "De zorgverlener die de medicatieafspraak met de patiënt heeft vastgelegd" verwijst naar MedicationRequest.recorder, niet MedicationRequest.requester //////////// tekst aanpassen |
| 3 | Besproken. We konden ons voorstellen dat dit is zodat een ontwikkelaar niet te licht dit veld overlaat aan de standaardwaarde, maar we horen graag de argumentatie. Core resource stelt hem verplicht dus profiel moet er iets mee. IG toevoegen? | MedicationRequest.intent | MedicatieAfspraak intent wel (verplicht) in profiel, maar geen zib onderdeel. | definitie spreekt over default value "order" (order tenzij). niet als mapping in diff opgenomen. //////////// intent wel (verplicht) in profiel, maar geen zib onderdeel. Expliciet in profiel specificeren wat er mee moet, niet open laten. zou liefst in mappings en tenminste in voorbeelden uitgewerkt moeten zijn. ook (verwijzingen naar) voorbeelden van andere values voor intent. Er wordt "order" voorgesteld. Kan ik niet uit de zib definitie halen. Dus dan zou ik eigenlijk dit weglaten uit het profiel. //////////// zie boven - staat als suggestie in definitie: order tenzij. Zou ik niet weglaten: MedicatieAfspraak heeft al voldoende usecases te ondersteunen ( zie https://informatiestandaarden.nictiz.nl/wiki/mp:V9_2.0.0_Ontwerp_medicatieproces#Use_cases_Voorschrijven) Oftewel: zou je hier niet gewoon binding op Order moeten doen? |
| 4 | Misschien hier iets beter het issue toelichten voordat we dit aan Nictiz teruggeven Algemeen punt, werd ook bij andere profielen genoemd: levels van containers in zib niet congruent met data-elementen en resources in FHIR levert onduidelijkheden en onhandigheden op die je niet wilt | MedicationRequest.dosageInstruction | MedicatieAfspraak | "Chaos" mapping van InstructionsForUse en DosageInstruction. (Vertalingen helpen niet) InstructionsForUse sub-zib lijkt te groot, hij zit in FHIR op meerdere plekken. En: waarom extensions Additionalinstructions en RouteOfAdministration niet in dosageInstruction zib/profiel? Plus renderedDosageInstruction extension. PeriodOfUSe? see below //////////// Ook inhoudelijk: Doseerinstructie NL-CM:9.12.22095 hangt in zib onder gebruiksinstructie NL-CM9.12.22504. Vraag is of dat pasend is: verschillende soorten/doelgroep voor instructie? niet compatibel met FHIR specs? in ieder geval zijn verhelderende voorbeelden gewenst: hoe wordt men geacht dit in de praktijk toe te passen. Nu niet te volgen. In de beschrijving van Medication.Request, dosageinstruction worden de verwarrende implicaties van zib versus fhir keuzes zo beschreven.: "Comments This element mostly represents the DosingInstructions container from zib InstructionsForUse, but also includes the AdditionalInstructions and RouteOfAdministration concepts, which are normally placed on the same level as this container. As a result, these concepts are duplicated in every repetition of this element, even though these concepts should be present just once according to the zib. This element does not contain a mapping to the Dosage container from zib InstructionsForUse. However, the child concepts of Dosage are all mapped. Multiple Dosage instances are represented by another DosingInstructions that contains a similiar SequenceNumber." Voorbeelden graag... |
| 5 | de DefinitionCode bij zib-elementen komt niet altijd in het profiel. Suggestie is dat als dat wel zo is, er beter over de profielen geredeneerd kan worden bijvoorbeeld via OWL.
| |||
| 6 | ConceptMap niet van toepassing want core binding is example, maar een beetje toelichting op het element zou goed doen | MedicationRequest.category MedicationStatement.category | MedicatieAfspraak DefinitionCode MedicationUse2 DefinitionCode | In FHIR (en Epic) is dit inpatient, outpatient, e.d. In de zib een SCT. Ik mis hier de ConceptMap. //////////// waar zie je SCT? >> in de zib definitie |
| 7 | Dat zit in de FHIR profiling guidelines voor r4, open world modeling | MedicationRequest.medication[x] MedicationStatement.medication[x] | MedicatieAfspraak.Product MedicationUse2.ProductUsed | Waarom geef je de keuze in FHIR om de Medication resource te gebruiken of de zib Product?? Vergelijkbaar is dat ook bij reasonReference en requestorReference gedaan. |
| 8 | >> betere voorbeelden nodig cq IG: wanneer/hoe reasonCode, wanneer/hoe reasonReference | MedicationRequest.reasonCode MedicationRequest.reasonReference(Condition | Observation | zib-Problem) | MedicatieAfspraak.ReasonMedicationAgreement | In FHIR wordt als reden altijd een Probleem/Diagnose/Verrichting genomen, oftewel de DHD DT of VT. De zib codelijst is veel algemener dan een specifieke diagnose. |
| 9 | "will usually be" overal vervangen door "SHOULD"? | MedicationStatement.status | MedicationUse2 verschillende | "Usually" is een beetje vaag. Komen de regels overeen met de interne regels van de resource? E.g. status mag alleen completed zijn als Period end is verstreken. ////////// zie instructies over .status in verhouding tot PeriodofUse en Stoptype. Deze zijn impliciet, niet voorgeschreven? Wat als status element in FHIR resource recorded is (zie tekst "unless status is explicitly recorded") - hoeven instructies/regels dan niet gevolgd te worden? |
| 10 | Door de meervoudige semantiek van NL-CM:9.6.22094 RedenMedicatieafspraak zou je dit element als het een startreden betreft op .reasonCode willen mappen, maar als het een stopreden betreft op .statusReason. Zou behoud je reden voor starten naast reden voor stoppen. .reasonCode is specifieke ingeperkt tot max 1 t.o.v. de resource. Dat lijkt niet volgens de profiling guidelines en leidt ertoe dat dus naast de startreden sowieso niet ook een stopreden kwijt kunt. | MedicatieRequest.reasonCode | koppeling met stopType extension niet heel elegant. eerste voorbeeld hieronder: DatumTijd krijgt nu definitief vulling van stop-voorschrift, moment van voorschrijven valt weg. Let ook op MedicatieAfspraak.Reden: inhoudelijk is dit reden van stoppen. Wat moet er gebeuren met een eventuele oorspronkelijke RedenVoorschrijven....? //////////
| |
| 11 | Prima punten. | Algemeen vragen voor alle resources | 1) Algemene vraag: hoe gedragen instances van de MedicatieProces resources zich in workflow / tijd? Dus wanneer een nieuwe instance en wanneer een update. B.v. Bij een stop valt informatie weg, namelijk de reden van het oorspronkelijke voorschrijven als we het stoppen met een update gaan doen. De reden zit dan in de history. 2) Veel implementatie voorkeuren, regels en instructies zitten verstopt in de zib of profiel commentaren of nog verder in e.g. het MedicatieProces. Deze zijn essentieel voor implementatie. B.v. welk stelsel is primaire code voor farmaceutisch product vs welke alternatieve zijn er. 3) En als er meerdere (gelijke) codes zijn uit andere stelsels, dan moet er richtlijn zijn voor hoe het in de code velden komt. Waar is dit te vinden in de implementatiegids? (/ informatiestandaard) 4) Er lijkt alleen nl-core examples te zijn. Waar zijn de zib examples? 5) notes/toelichtingen en tekst-redenen (en andere qualifiers) zijn niet specifiek voor bepaalde data-elementen gedefinieerd. Soms/vaak wel nodig (let op praktijk implementaties? meerdere notes mogelijk, met auteur en datum). ////////// eenduidige implementatie is zo niet te waarborgen. als ZIB profielen bedoeld zijn ter implementatie, is goede, duidelijke en expliciete documentatie nodig met voorkeurskeuzes en richtlijnen voor de implementatoren
| |
| 11 | Medicatieafspraak is een MedicationRequest en Verstrekkingsverzoek is ook een MedicationRequest. De eerste is de therapeutische kant van de zaak en de tweede is de logistieke kant van de zaak. Dit is kern aan hoe we in NL met medicatie willen omgaan. Er is dus heel bewust voor 2 profielen gekozen vanuit procesoverwegingen. | MedicationRequest.extension:periodOfUse-Period, -Duration | Hoe verhoudt deze extension(s) zich tot MedicationRequest.dispenseRequest (MP modelleert verstrekkingsverzoek als aparte bouwsteen, ook hier wordt zib tijdsinterval 1-op-1 gebruikt). Maar waarom dan dan niet dispenseRequest 1-op-1 kopieren? in fhir specs wordt aangegeven dat deze vaak los van request wordt verstuurd. | |
| 12 | Lijkt een issue met de zib te zijn meer dan iets met het profiel. De zib zegt alleen dat het een opmerking bij de MA is en zegt verder niks over updaten gedurende de levenscyclus | MedicationRequest.note | MedicatieAfspraak Toelichting 9.6.22273 | card 0..1: medicatieafspraak heeft een levenscyclus (kan gestopt worden) en kent ook verschillende aspecten (redenvoorschrijven, gekozen medicatie, periode/dosering, etc etc. Waar hoort een specifieke note bij? en wat als aanvullende toelichting nodig is...? ////////// overlap met statusReason codes? implemetatieinstructie: waarschuwen dat note niet(?) gebruikt mag worden voor opmerkingen die relevant zijn voor medicatiebewaking? |
13 | De code https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=112201000146104 is een observable entity maar waar je aan koppelt is een Condition resource wat een finding is. Tweede bijkomstigheid is dat in de zib niet goed duidelijk is waarom je juist PrescriptionReason::Problem of juist ReasonMedicationAgreement wilt gebruiken | MedicationRequest.reasonReference MedicationRequest.reasonCode | MedicationAfspraak | MedicationRequest.reasonReference verwijst naar Problem Zib. Klopt dat wel met Snomed code medische reden voorschrijven? Mogelijk voorbeeld: anesthesie? wel in Medicatieafspraakcodelijst note: The BST401T file of the G standard contains a “special reference” to indicate that “exchange of the reason for prescription is essential”. ////////////// zib issue: klopt de snomed codering hier wel? Voorbeelden nodig, van situaties waar wel en niet beide reason-elementen gebruikt (zouden moeten) worden. |
14 | Zib bevat het woord Appointment waar geen sprake is van een Appointment. Dat is een ongelukkige vertaling. Vraag: hebben alle systemen, mn. HIS-sen eigenlijk wel beschikking over datum én tijd? | MedicationRequest.authoredOn | MedicationAfspraak | in def: Appointment date + time are required. Niet correct. Er hoeft voor een MedicationAfspraak geen appointment (bekend) zijn. staat ook niet in MP standaard. /////// aanpassen |
| 15 | Voorbeelden niet gevonden in Simplifier van het farmaceutisch product | MedicationRequest.medication[x]:medicationReference | MedicationAfspraak | Example Instances alleen maar text/beschrijvingen. Hoe werkt het als ook codes en form, ingredient etc elementen als code beschikbaar zijn? nu weinig over te zeggen. Dan wordt ook duidelijk wat beschreven is over ml versus andere eenheden in introtekst Farmac product. //////////// voorbeelden toevoegen. Voorkeuren aangeven over meerdere codestelsels? |
Onze voorlopige conclusie rondom medicatie profielen: De documentatie van het medicatie profiel moet de kwaliteit van de implementatie waarborgen. Op dit moment is dat nog niet het geval doordat
1. Veel details en/of aanvullende informatie is verborgen
2. Op veld niveau wordt niet expliciet vermeld wat verplicht is en wat daar gebruikt moet worden
3 Als er op veld niveau meerdere mogelijkheden zijn ( code/reference ) wordt geen voorkeur uitgesproken
4. Er zijn implementatiegidsen/instructies nodig - zeker voor medicatieproces profielen.