Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Plaatsen known-issue in nl-core-humanname voor .given

Description

Vanuit MM-1699 blijkt dat het nl-core-humanname profiel niet correct is. 
Op basis van de FHIR spec en de voorbeelden blijkt dat elke `.given` een aparte naam is. Dat kan in de vorm zijn van een volledige naam of van een initiaal, maar het is niet zo dat de ene given een versie is van de andere given. Voor het communiceren van de roepnaam lijkt het geijkte mechanisme te zijn om twee `name` elementen te maken met verschillende `use`'s. En er lijkt geen standaard mechanisme te zijn om een voornaam én een initiaal van die voornaam door te geven (en waarom zou je dat inderdaad willen?)

We dienen hiervoor een known issue te plaatsen om te melden dit afwijkt van hoe FHIR het bedoelt en dat er custom logica nodig is om de zib gegevens uit te wisselen. Mogelijk kan er ook al meer gestuurd worden op de `name.text`. Hiervoor is dit isuse. MM-1699 zal zorg dragen voor het corrigeren van de specificaties in de volgende major release.

 

Verduidelijking van Impact

Er is geen impact op bestaande systemen.

Proposed solution (NL)

In het profiel nl-core-humanname wordt een "known issue"-commentaar geplaatst dat het gebruik afwijkt van de internationale standaard omdat initialen en de roepnaam binnen een enkele HumanName worden doorgegeven. De opmerking dat het profiel nog steeds als internationaal geldende HumanName gebruikt kan worden, wordt verwijderd.

Proposed solution (EN)

None

Release notes (NL)

A "known issue" remark was added to the nl-core-humanname profile to explain that it is not entirely compatible with how names are normally communicated in FHIR – initials and nicknames are added to the same name element rather than additional elements. Guidance has been added on how implementers should deal with this.

Release notes (EN)

None

Activity

Show:

Ardon Toonstra May 20, 2021 at 12:18 PM

Beide akkoord.

Pieter Edelman May 20, 2021 at 10:16 AM

Former user zou jij de review willen doen? Former user  het zou fijn zijn als jij nog met een derde paar ogen mee kan kijken.

Pieter Edelman May 20, 2021 at 10:15 AM

Pieter Edelman May 11, 2021 at 8:41 AM
Edited

Ik probeer de situaties op een rijtje te zetten om te kijken of een ontvangend systeem altijd ondubbelzinnig de informatie kan terughalen in beide situaties:

 

Huidige aanpak

Internationale aanpak

Alleen een officiële naam

  • 1 instance

  • .use optioneel

  • 1 instance

  • .use ws. gevuld, maar kan afwezig zijn

Ook initialen/roepnaam

  • 1 instance

  • .use afwezig

  • meerdere instances

  • .use gevuld (of niet? ^)

Een ontvanger krijgt te maken met de volgende situaties:

  • 1 instance

    • .use afwezig => huidige aanpak óf internationaal, niet te onderscheiden of .given's dubbel zijn of niet.

    • .use aanwezig => naam is conform .use, dubbele .given's kunnen niet bestaan. Indien slechts de officiële naam wordt doorgegeven is er geen verschil tussen de huidige en internationale situatie.

  • meerdere instances

    • .use afwezig => dit zou niet moeten kunnen (of wel? ^)

    • .use gevuld => naam is conform .use, dubbele .given's kunnen niet bestaan.

Oplossingsrichting:

  • Zendende en ontvangende systemen moeten de extensies ondersteunen.

  • Zendende systemen worden aangemoedigd om .text altijd te vullen.

  • Zendende systemen worden aangemoedigd de huidige aanpak te volgen omdat dat tot nog toe het uitgangspunt was, maar ze kunnen hier naar eigen inzicht van afwijken.

  • Indien zendende systemen de huidige aanpak volgen, kunnen ze .use niet vullen (want dit conflicteert met de extra namen in .given).

  • Indien zendende systemen de internationale aanpak volgen, zouden ze .use altijd moeten vullen – ook als er slechts 1 instance is.

  • (Alleen) indien ontvangende systemen 1 instance ontvangen, en de extensies differentiëren de verschillende .given's, en .use is afwezig, dan moet het geïnterpreteerd worden als de huidige situatie; .given's kunnen niet achter elkaar gezet worden maar moeten als alternatieve representaties van dezelfde naam worden gezien.

  • In elke andere situatie zullen ontvangende systemen de .use volgen.

^ In principe zou je ook de verschillende gebruiken kunnen doorgeven adh. de extensies, zonder .use te gebruiken. Ik weet niet of dit een realistisch scenario is.

Ardon Toonstra May 7, 2021 at 1:00 PM

Former user, de huidige specs laten dat opzich wel toe. Patient.name en Pracititoner.name is bijvoorbeeld 0..*. Het wordt echter niet door ons expliciet beschreven dat het op de internationale manier kan/zou moeten en belangrijker: al onze test- en kwalificatiematerialen maken gebruik van maar één naam element. Het is dus niet getest of systemen het op de internationale manier kunnen.

Resolved
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Classification

Informatiestandaard onderdelen

FHIR-package

Information standard

Alle

Fix versions

Priority

Better Excel Exporter

Created April 23, 2021 at 1:33 PM
Updated January 12, 2024 at 12:53 PM
Resolved June 1, 2021 at 7:42 AM