Page tree
Skip to end of metadata
Go to start of metadata

HL7NL Logo

Chair:  @

Scribe: @ 

NOTE: This attendance applies if you are present at the related meeting/call, regardless if you have signed a different attendance for your WG. 

Attendees

Present

Name

Affiliation


@username





















Minutes Approved as Presented 


This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."


Agenda Topics

Agenda Outline

Agenda Item

Meeting Minutes from Discussion

Decision Link(if not child)
Management Minutes Approval

Methodology

Michael van der Zel Ik hoorde een verhaal van Nictiz hoe zij omgaan met FHIR profielen die worden ontwikkeld vanuit en in relatie met informatiestandaarden en de zib FHIR profielen. 
Met name ook hoe software ontwikkelaars zich kunnen kwalificeren/certificeren en hoe je daarin die FHIR proflenen gebruikt. Ik heb geen oplossing, maar maak me wel zorgen over de hoeveelheid werk die dit voor (kleine) ontwikkelaars met zich mee brengt. Daarnaast denk ik dat we moeten zorgen voor een beperkt aantal profielen en zorgen dat er een gesloten lus ontstaat tussen de zibs en de FHIR profielen en CDA en de implementatie in de EPDs en ... (zeg alles van Registratie aan de Bron).
Op dit moment wordt die lus (en met name de consistentie / traceability) voornamelijk door (goede!) mensen in de gaten gehouden, maar het wordt al steeds lastiger door steeds meer materiaal en versies.
Ik vind dat we hier iets over moeten vinden vanuit FHIR-NL als onafhankelijke party (😉).

@Marten Smits 

Zelf ben ik er niet bij in november, dus wil mijn mening hierover nu via deze weg vast kwijt:

Ik denk dat dit voornamelijk een verantwoordelijkheid van RadB is. Waarbij zibs door een strenger ballot proces gaan: lees meer testen bij en actiever feedback vragen bij de grote gebruikers (MedMij, CDA-mensen), zodat veranderingen meer gebasseerd zijn op praktijk ervaringen en gebruikers niet geconfronteerd worden door onverwachte wijzigingen.

Men is eindelijk zibs aan het inbouwen (voornamelijk versie 2017). Dat betekent dat RadB zich ook moet realiseren dat wijzigingen pijn doen. Bij de auteurs van de FHIR profielen/CDA templates, maar ook en vooral bij de software ontwikkelaars. Idealiter zouden er daarom eigenlijk alleen maar breaking changes moeten worden doorgevoerd als iets écht fout is. En moet bij elke breaking change het veld geconsulteerd worden. De zibs worden als volwassen beschouwt, dan moeten we ze ook zo behandelen.

Het vooraf publiceren en bespreken van gedetaileerde wijzigingen/release-notes helpt hierbij enorm.

Over het beperken van het aantal FHIR profielen: nu worden er naar mijn weten voor MedMij FHIR profielen gemaakt per ZIB, mits die gebruikt worden in een use-case. Dat is vast mooi meegenomen neem ik aan?

Daarnaast kan niemand tegenhouden dat er daarnaast andere profielen gemaakt worden, die daarvan afgeleid zijn, of daarnaast leven. De wereld bestaat nou eenmaal niet alleen maar uit zibs, er zijn genoeg use-cases die iets specifiekers nodig hebben dan een zib, of iets uit willen wisselen wat niet kan worden uitgedrukt in een zib.

Dan zijn er twee mogelijkheden:

  1. a) RadB moet ambities hebben om de hele wereld uit te drukken in zibs (lijkt me niet nuttig/haalbaar).
  2. b) Men moet accepteren dat er FHIR Profielen/ CDA templates ontstaan die niet op een zib zijn gebasseerd, of een zib inperken voor het uitdrukken van iets wat specifiekers is.

Om te voorkomen dat er dubbele profielen ontstaan/worden gepubliceerd is het FHIR-NL initiatief opgericht, we doen wat we kunnen.

Ik wil trouwens deze discussie helemaal niet verder voeren via email, maar hierbij dus alvast mijn input voor het agendapunt van de vergadering in november, ik lees het verder wel in de notulen.



Management Next agenda

 Adjournment
 Adjourned at

Supporting Documents

Outline Reference

Supporting Document

Minute Approval


Tasks

  •