TE-WI.*: Waardelijsten zouden niet per informatiestandaard ingeperkt mogen worden

helmavdl commented 4 months ago

Beschrijving issue

TE-WI.001: Waardelijsten in informatiestandaarden MOGEN minder waarden bevatten dan de corresponderende waardelijsten in de zibs

Dit issue geldt voor alle TE-WI.* requirements.

Waarom mag deze lijst ingeperkt worden en hoe voorkom je dat een zib die in meerdere informatiestandaarden gebruikt wordt gaat leiden tot incompatible inperkingen?

Voorgestelde wijziging

Bronnen en referenties

Extra informatie

pieter-edelman-nictiz commented 4 months ago

Een inperking kan per definitie niet incompatibel zijn, dan is het namelijk geen inperking meer.

rjpnienhuis commented 4 months ago

TE-WI.002 geeft een verdere invulling van TE-WI.001. In mijn ogen geeft TE-WI.002 een oplossing voor de problemen die ontstaan door TE-WI.001?

pieter-edelman-nictiz commented 4 months ago

TE-WI.002 geeft een verdere invulling van TE-WI.001. In mijn ogen geeft TE-WI.002 een oplossing voor de problemen die ontstaan door TE-WI.001?

Ik denk dat dit te vrijblijvend is, hier zou je ook wel harmonisatie willen. Maar ik denk dat de oplossing zit in "Verwerking waarden". Daar zou je uitspraken kunnen doen over wat een systeem moet doen wanneer die waarden buiten bereik ontvangt, heeft uit de historie (zie #6), of moet ontsluiten omdat waarden in een andere context zijn verkregen. Hangt ook samen met #8.

helmavdl commented 4 months ago

Een inperking kan per definitie niet incompatibel zijn, dan is het namelijk geen inperking meer.

In zichzelf niet, maar als de zib waardes 'a,b,c,d' toestaat en informatiestandaard 1 beperkt tot 'a,b' en informatiestandaard 2 tot 'b,c', dan zijn de lijsten in de informatiestandaarden wel incompatible.

helmavdl commented 4 months ago

TE-WI.002 geeft een verdere invulling van TE-WI.001. In mijn ogen geeft TE-WI.002 een oplossing voor de problemen die ontstaan door TE-WI.001?

Nee juist niet. Maar ik kan het eens zijn met Pieter's opmerking dat je moet afspreken hoe waarden verwerkt moeten worden.

pieter-edelman-nictiz commented 4 months ago

Een inperking kan per definitie niet incompatibel zijn, dan is het namelijk geen inperking meer.

In zichzelf niet, maar als de zib waardes 'a,b,c,d' toestaat en informatiestandaard 1 beperkt tot 'a,b' en informatiestandaard 2 tot 'b,c', dan zijn de lijsten in de informatiestandaarden wel incompatible.

Klopt. Dat is ook niet te voorkomen als de usecases in kwestie om verschillende invullingen vragen. Dat probleem is niet op te lossen in de informatielaag van het lagenmodel, dat zit in de lagen erboven. Je kan het alleen mitigeren door afspraken maken over de verwerking van codes die buiten het bereik vallen.

rjpnienhuis commented 3 months ago

In de WG discussie van 13-05-2024 is aangedragen dat:

Dit is eigenlijk een registratierichtlijn. De vraag is of je dit op het niveau van uitwisseling moet willen regelen
Dit kan alleen maar als de context (welke informatiestandaard) duidelijk is
Dit lijkt wel op wat in openEHR gebeurt: een template is een verdere constraint op archetypes. Het template is de context en die is igv openEHR zeer expliciet
ER is onderscheid tussen PUSH (of notify-pull) use case met documenten of meer pull/ resource gebaseerde patronen. In PULL/ resource pattern is use-case denken minder logisc...de ontvanger bepaald immers de query.

Voorstel: Uitsplitsen in ontvangende en verzendende partij. Verzender zend alleen de geminimaliseerde set. Ontvanger past query aan (PULL scenario). Uitgangspunt is dan dat je het expressievermogen nodig hebt maar dat dit wel met voorzichtigheid moet worden toegepast.

Voorstel: je zou eigenlijk in de informatiestandaard moeten vastleggen wat MINIMAAL moet kunnen worden uitgewisseld. Want wellicht ondersteun je wel meer informatiestandaarden op dezelfde API.

jjhengel commented 3 months ago

Ik begrijp niet wat je bedoelt @rjpnienhuis. Waarom zou de ontvanger zijn query moeten aanpassen? In een informatiestandaard beperk je de waardenlijsten toch altijd tot de waarden die in de context van toepassing zijn? Ik heb ook moeite met voorbeelden van APIs verzinnen die over informatiestandaarden heen bruikbaar zijn. Je wilt toch meestal resources opvragen die in bepaalde context van toepassing zijn, dus een relatie hebben met andere resources in die context. Bijvoorbeeld: de MedischHulpmiddelen in de context van de Blaasfunctie (= incontinentiemateriaal).

helmavdl commented 3 months ago

@jjhengel Door dit soort inperkingen niet expliciet te maken, maar impliciet is het een stuk eenvoudiger om de code voor het opleveren van de bewuste informatie te hergebruiken.

Als we als voorbeeld nemen: bij de Blaasfunctie moet ook de MedischeHulpmiddelen, beperkt tot incontinentiemateriaal, opgeleverd worden. Voor een andere informatiestandaard over Mobiliteit moet ook MedischeHulpmiddelen opgeleverd worden, maar beperkt tot mobiliteitshulpmiddelen.

Dat kan op verschillende manieren geïmplementeerd worden.

Expliciet coderen De opvragend/zendend en opleverend/ontvangend systemen implementeren de informatiestandaard waar deze zibs bij horen en beperken de opgeleverde lijst van waardes hard op de lijst van incontinentiemateriaal resp. Mobiliteitshulpmiddelen. Dit betekent dus in beide systemen dat ze voor 2 informatiestandaarden dezelfde zib op 2 manieren moeten implementeren. De systemen vertellen elkaar (via een andere parameter) wat er opgeleverd moet worden.
Impliciet coderen Het opvragend systeem geeft in de query voor de MedischeHulpmiddelen exact aan wat voor gegevens ze willen hebben (incontinentiemateriaal of mobiliteitshulpmiddelen). Het opleverend systeem levert exact aan wat gevraagd wordt, nl. alleen incontinentiemateriaal of alleen de mobiliteitshulpmiddelen. Hiermee wordt expliciet beschreven wat uitgewisseld wordt. Voor het opvragende systeem betekent dit alleen een parameter aanpassing in de query (en dus geen extra parameter om de gewenste informatie aan te geven) en voor het ontvangende systeem is er geen verschil tussen het opleveren van dezelfde zib met incontinentiemateriaal en met mobiliteitshulpmiddelen.

In de laatste situatie is het heel eenvoudig om dezelfde zib in verschillende use cases toe te passen.

Ik zou willen stellen dat:

het opleverende systeem niet gedwongen wordt om zelf restricties te bouwen op basis van deel-waardelijsten die in de ene of de andere use case/informatiestandaard gebruikt wordt.
tijdens kwalificaties niet gecontroleerd wordt dat een opleverend systeem ook daadwerkelijk geen andere waardes dan de voor die use case toepasselijke lijst oplevert.
een opvragend systeem altijd precies aangeeft wat gewenst wordt, dus niet alleen de zib, maar ook alle bijbehorende parameters om aan te geven dat informatie over incontinentiemateriaal of mobiliteitshulpmiddelen gevraagd wordt.

jjhengel commented 3 months ago

@helmavdl Als ik het goed begrijp moet het opvragende systeem in manier 2) weten dat de bij de Blaasfunctie horende MedischHulpmiddelen kinderen van incontinentiemateriaal zijn, en de codering van incontinentiemateriaal meegeven in de query voor MedischHulpmiddel. In manier 1) hoeft het opvragende systeem dat niet te weten en de codering niet te kennen.

helmavdl commented 3 months ago

@jjhengel Klopt. Maar dat is evenveel werk dan via een andere parameter aangeven welke informatie ze willen.

Nictiz / zib-transitie-richtlijnen-docs