Bij deze een eerste set feedback. Steven had gevraagd dit als een ticket met bullets te doen.

• "This FHIR Implementation Guide specifies the Generic Function Addressing (GFA)": de GF is meer dan de in dit document beschreven techniek. Wellicht iets als "specifies the technical components of the ..."?
• "across systems"; welke?
• van mij mag het hele marketing deel eruit ("In today's ...). Er staan claims in die niet onderbouwd worden en mogelijk ook niet juist zijn. Hoe zien jullie dit?
• Concepten als "Administration Directory" kan ik zo snel niet vinden in de mCSD documentatie. Wellicht andere termen voor gebruiken of deze termen expliciet introduceren?
• Zouden de ITI's op de lijnen van het diagram kunnen?
• Wat voor soort diagram is dit (deployment/ logisch/ iets anders)?
• CIBG wordt niet in het document genoemd, kan uit diagram?
• "A practitioner and/or system (EHR) can now use the Query Directory to search for a healthcare service, organization, department, location, endpoint, or practitioner." -> "A practitioner and/or system (EHR) can now use the Query Directory to search for the resource defined within mCSD"?
• De "Administration Client" is een nieuw ding volgens mij en niet iets wat besproken is in de meetings. Op zich logisch om te hebben als je de "Administration Directory" als een off-the-shelve FHIR store ziet, het is denk ik alleen niet een noodzakelijk onderdeel van de oplossing?
• 2.3.2 - het heeft mijn voorkeur om performance dingen buiten dit document te laten omdat deze afspraken denk ik een ander niveau horen. Is dit voor jullie ook OK?
• "status" is nieuw voor mij. Is dit al eens eerder besproken?
• "The LRZa Administration Directory contains a list of healthcare providers" => "list of Organization resources"?
• "and the healthcare provider's Administration Directory endpoint (URL)" => "... Endpoint resource referencing the ... "
• "An Administration Directory is only authoritative for the healthcare providers that registered this Administration Directory endpoint (URL) at the LRZa. Information about other healthcare providers MUST be disregarded." - dit gaat over Organization resources toch? Zoals het er nu staat lijkt het dat er enkel organizations toegestaan worden die in het LRZa staan (het punt daarna geeft de uitleg met sub-organisaties).
• Ik mis bij 2.3.3 nog iets over het herschrijven van relaties tussen entiteiten indien dit gebeurd op basis van de technische ids. Moet dat nog gedaan worden of is het wel duidelijk genoeg zo?
• 2.3.4 punt proprietary api's (update & query directory en query client & query directory) kan er uit toch? Dit document zou als scope de koppelvlakken moeten hebben toch?
• 2.4 in het profiel zijn een aantal keuzes gemaakt die volgens mij nog niet besproken zijn en waarvan ik de achtergrond nog mis (address op endpoint immutable bijvoorbeeld). Is er een overzicht van de keuzes die specifiek nieuw zijn ten opzichte van het basis nl profiel?
• 2.4.2 is er een use-case voor de replacedBy? Is dit dan ook iets wat binnen een van de PoCs getest zou moeten worden?
• "in stead" => instead
• 2.4.2.1 in welk scenario zou er naar een endpoint gelinkt worden in de medische administratie? Sowieso is linken op basis van het FHIR id in een adresboek risicovol. Alle data in het adresboek wordt via replicatie opgebouwd; hierbij zullen id's door het adresboek toegewezen kunnen worden die niet hetzelfde zijn bij meerdere adresboeken. Het voorbeeld lijkt ook een concept waar je volgens de payloadType voor wilde inzetten in de id (URI pad) te plaatsen. Mijn aanname was dat een client altijd een query doet op het adresboek indien je op zoek bent naar een endpoint op basis van de organisatie en endpoint eigenschappen?
• 2.4.3 er staan hier verwijzingen in naar ActivityDefinition en PlanDefinition. Is de gedachte dat deze ook mee gerepliceerd worden of is hier een ander plan bij?
• 2.4.5 wat is gedachte van de verwijzing naar de UZI-pas?
• 2.4.6 is deze buiten scope voor alle PoCs?
• 2.4.7 dit diagram hoort niet meer bij affiliation toch? Wat is de gedachte bij dit diagram ten opzichte van het mCSD diagram?
• 2.5 "For cross-border data exchange using mTLS, support for additional CA's is required." => "... additional CA's could be allowed to ..."; het is niet verplicht toch om andere CA's te ondersteunen?
• 2.6 is het een optie om concrete queries / attributen etc. op te nemen bij de use cases?
• 2.7 "should be supported" staat er wat sterk; het is een optie dat update clients dit ondersteunen maar is, afhankelijk van de use cases niet perse verplicht toch?
• 2.7.4 is het profiel stuk of de software? Software issues hoeven niet in deze guide toch?