Uploaded image for project: 'MedMij Standaarden'
  1. MedMij Standaarden
  2. MM-1839

Aanvullen FHIR IG met duiding voor gebruik van stabiele resource identifiers

    Details

    • Type: Wijzigingsverzoek
    • Status: Gesloten
    • Priority: 3
    • Resolution: Resolved
    • Fix Version/s: 2020.01 - Mei 2021
    • Component/s: None
    • Blokkerend:
      Nee
    • Informatiestandaard:
      Alle
    • Informatiestandaard onderdelen:
      Technisch, FHIR, Kwalificatie
    • Impact:
      Laag, gezien dit betere tekstuele uitleg betreft en verwachtingen beschrijft, geen verplichtingen.
    • Voorgestelde oplossing:
      Hide
      FHIR IG aanvullen met generieke verwachtingen omtrent Resource.identifier

      - Middels een should stellen dat systemen Resource.identifier vullen wanneer zij ook beschikken over een stabiele identifier voor het object.
      - Beschrijven waarom dit nodig is en hoe dit gebruikt kan worden (duplicaatdetectie).
      - Test- en kwalificatiematerialen worden met Resource.identifier aangevuld middels MM-2165.
      Show
      FHIR IG aanvullen met generieke verwachtingen omtrent Resource.identifier - Middels een should stellen dat systemen Resource.identifier vullen wanneer zij ook beschikken over een stabiele identifier voor het object. - Beschrijven waarom dit nodig is en hoe dit gebruikt kan worden (duplicaatdetectie). - Test- en kwalificatiematerialen worden met Resource.identifier aangevuld middels MM-2165 .
    • Release notes:
      Hide

      In the FHIR IG, the use of Resource.identifier is made "recommended".

      Show
      In the FHIR IG, the use of  Resource.identifier is made "recommended".

      Description

      Wijzigingsverzoek ontstaan vanuit MM-1823, MM-1157 en gesprekken met bijv. VZVZ.

      Er is een behoefte aan stabiele identificaties om resources mee te duiden, om zo onder andere gedegen duplicaatdetectie mogelijk te maken. MM-1823 beschrijft de problemen die PGO's ondervinden bij het opvragen van Resources.

      Relevante informatie vanuit MM-1823 over het gebruik van identificaties in FHIR:

      FHIR heeft twee identificaties waar de meeste systemen er slechts één hebben. Verder deelt FHIR de wereld op in resources en hoeft die doorsnede niet noodzakelijk overeen te komen met hoe systemen werken.

      De twee identificaties die FHIR onderscheidt zijn Resource.id en Resource.identifier (nagenoeg iedere resource). De eerste dient RESTful communicatie en wordt gebruikt in het datatype reference bij verwijzingen tussen resources. We komen in Nederland (en meer plekken in de wereld) van een hele lange traditie van messaging (berichtgebaseerde informatie-uitwisseling) waarbij er geen equivalent is voor Resource.id in de onderliggende systemen. Deze HL7v3 gebaseerde uitwisseling heeft wel een element id maar die verhoudt zich tot de Resource.identifier en is een "business identifier". Sommige daarvan zijn op zichzelf ook wel in te zetten als Resource.id (zoals een UZI of URA of zelfs bsn en dat doen de Nictiz-mappings dan ook), maar FHIR heeft een nogal belangrijke beperking in de Resource.id: je mag heel erg weinig vanwege URL compatibiliteit en heel veel Resource.identifiers kun je dan ook niet in een Resource.id stoppen (het formaat is[A-Za-z0-9\.-]
      Unknown macro: {1,64}
      ). 

      Lastiger is echter dat systemen normaal wel het object Practitioner kennen voor een zorgverlener, maar PractitionerRole die de zorgverlenerrelatie aan een rol in een organisatie dekt niet. Ook andere begrippen komen niet overeen met systeemwerkelijkheid: zo hebben huisartssystemen de grootste moeite met het begrip contact(moment), hebben ICPC-coderingen op een journaalregel niet noodzakelijk een eigen identificatie en meer.

      Kortom: dat je in FHIR dingen uniek kunt identificeren wil niet zeggen dat dat praktisch gezien ook altijd gebeurt. Niet omdat men dat niet zou kunnen als men nu een systeem zou ontwerpen, maar omdat het vertrekpunt met de huidige systemen dat (nog) niet altijd kan. Ontvangende systemen zoals die van jullie kunnen daarmee dus niet zonder meer uitgaan van Resource.id en verwachten dat het daarmee werkt.

      De huidige FHIR IG geeft veel duiding over het gebruik van Resource.id en fullURL en stelt het volgende over Resource.identifier in paragraaf 5.8.1:

      The usage of the .identifier field, i.e. the business identifier, cannot be described in general terms and will be dictated one a use-case basis by the particular profiles.

      De huidige gebruikte FHIR-profielen bevatten op veel plekken een mapping voor het zib-basiselement 'Identificatie'. Meer wordt hier vaak niet over gezegd, op een aantal informatiestandaarden na, zoals Medicatieproces en PDF/A.
       
      Hierbij het verzoek om te onderzoeken of de FHIR IG kan worden aangevuld met een generiek verwachting voor het gebruik bij Resource.identifier. Hierbij zou gedacht kunnen worden aan:

      • Middels een SHOULD stellen dat systemen Resource.identifier vullen wanneer zij ook beschikken over een stabiele identifier voor het object.
      • Duiding/advies geven hoe de Resource.identifier.system gevuld kan worden.
      • Beschrijven waarom dit nodig is en hoe dit gebruikt kan worden (duplicaatdetectie).
      • Test- en kwalificatiematerialen aanvullen met Resource.identifier waar mogelijk middels MM-2165

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              toonstra Ardon Toonstra
              Reporter:
              toonstra Ardon Toonstra
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Estimations By Role

                  No roles have been estimated yet.