ADFTest Summary: verschil tussen versies

Uit Zorginformatiebouwstenen
Naar navigatie springen Naar zoeken springen
Update bot (overleg | bijdragen)
Geen bewerkingssamenvatting
Update bot (overleg | bijdragen)
Geen bewerkingssamenvatting
Regel 1: Regel 1:
De NL-CM:13.1.34 LaboratoriumUitslag.Aanvrager is niet implementeerbaar zoals deze nu is. De aanvrager is deel van het Aanvraag object waarvan meer informatie vereist is om deze te kunnen samenstellen. Status, aanvraagcode om maar wat te noemen.<br>
Naast een feitelijke verrichting kan de zib Verrichting ook informatie bevatten over toekomstige verrichtingen. Het lijkt alsof er twee verschillende concepten in &#233;&#233;n model zijn samengevoegd, door de definites van een verrichting te veruimen zonder eigenlijk extra context toe te voegen die bij een toekomstige verrichting hoort.&#160;<br>


Op dit moment kun je daardoor Aanvrager in zowel in FHIR als Cda niet goed implementeren.<br>
Het is onduidelijk hoe een toekomstige verrichting in de systemen &#39;leeft&#39; als het niet een aanvraag/plan/order is om de verrichting uit te voeren. De zib bevat het concept Aanvrager. Dit lijkt nadrukkelijk een concept te zijn dat bij een aanvraag van een verrichting thuishoort en niet bij de feitelijke verrichting.&#160;<br>


Voorstel: Aanvrager verwijderen of zorgen dat de Aanvraag volwaardig door de zibs wordt ondersteund.<br>
Hoe kan via het zib model worden aangegeven dat een toekomstige verrichting, na een tweede keer uitwisselen na de geplande datum, is uitgevoerd? Of dat de toekomstige verrichting juist niet is uitgevoerd maar aangepast naar een andere verrichting?<br>
 
Het lijkt de moeite om te onderzoeken of de zib ook niet gesplits zou moeten worden in een feitelijke verrichting en een toekomstige verrichting.<br>

Versie van 22 jan 2026 23:22

Naast een feitelijke verrichting kan de zib Verrichting ook informatie bevatten over toekomstige verrichtingen. Het lijkt alsof er twee verschillende concepten in één model zijn samengevoegd, door de definites van een verrichting te veruimen zonder eigenlijk extra context toe te voegen die bij een toekomstige verrichting hoort. 

Het is onduidelijk hoe een toekomstige verrichting in de systemen 'leeft' als het niet een aanvraag/plan/order is om de verrichting uit te voeren. De zib bevat het concept Aanvrager. Dit lijkt nadrukkelijk een concept te zijn dat bij een aanvraag van een verrichting thuishoort en niet bij de feitelijke verrichting. 

Hoe kan via het zib model worden aangegeven dat een toekomstige verrichting, na een tweede keer uitwisselen na de geplande datum, is uitgevoerd? Of dat de toekomstige verrichting juist niet is uitgevoerd maar aangepast naar een andere verrichting?

Het lijkt de moeite om te onderzoeken of de zib ook niet gesplits zou moeten worden in een feitelijke verrichting en een toekomstige verrichting.