aangemaakt om de example en kwalificatieresources aan te passen.

Goed overzicht! Ik denk dat dit een heel goed vertrekpunt is. Probleem van vertrouwen op het .identifier veld is alleen dat deze niet altijd (met dezelfde system) ingevuld hoeft te worden op dit moment. Mijns inziens zullen we daar dus een identifier alsnog voor moeten verzinnen.

We hebben het over identiteit van een object/resource. Die heeft verschillende use cases, niet in volgorde van belang

1. RESTful communicatie - Alleen Resource.id

2. Duplicaatdetectie - FHIR stelt dat dat aan Resource.id hangt, onze werkelijkheid heeft ook alternatieven nodig

We gebruiken op dit moment de volgende resources bij huisartsgegevens. Hebben we hier iets aan als vertrekpunt? Merk op dat de tabelinhoud lichtelijk uit de losse pols is, dus mogelijkerwijs klopt niet iedere komma.

Edit by Ardon: .identifier kolom aangevuld. Alles behalve Medication heeft een .identifier.

Ik begrijp niet helemaal waarom we het nogsteeds hebben over Resource.id. Dat veld dient alleen een logische ID te bevatten die alleen uniek hoeft te zijn binnen de FHIR server (de RESTful ID in bevragingen als [base]/Observation/[id] inderdaad). Veel FHIR servers gebruiken hier simpelweg incrementele waardes voor, wat natuurlijk direct conflict met andere servers. RESTful reads op basis van de universele business identifier gaan nooit mogelijk zijn, aangezien deze identifier niet als logical ID in de FHIR server gebruikt wordt.

Is het daarom niet handig om Resource.id achterwege te laten en onze te focussen op business identifiers zoals Patient.identifier, Observation.identifier, etc. Niet elke resource ondersteunt dit veld, maar een groot gedeelte wel. Voor resources die het niet ondersteunen zou eventueel een extension gedefinieerd kunnen worden.

Als je stateless telkens tot dezelfde identificatie wilt komen dan moet de input die je daarvoor gebruikt stabiel blijven. Er zijn voorbeelden waar dat lukt:

• UZI en AGB van zorgverlener

  • Maar ... als je eerst een zorgverlener op basis van AGB voorbij ziet komen en deze krijgt later een UZI-pas, dan wordt het virtueel toch ineens een andere zorgverlener.

• URA en AGB van zorgaanbieder. Zie eerdere opmerking bij zorgverlener

• HL7v3 Act.id, Role.id, Entity.id zijn van datatype Instance Identifier en hebben in FHIR termen een system en een value (V3: root en extension). Als het V3-object in 1 resource landt met dezelfde semantiek dan kun je de V3 id overnemen als FHIR Resource.identifier

  • Mappingvraagstuk: is een V3 author.assignedEntity.id de FHIR Practitioner.identifier of de PractitionerRole.identifier of beide? Wij hebben nu een mapping in Practitioner.identifier, en voor PractitionerRole heeft V3 geen specifieke data voorhanden.

• Als de concatenatie van een V3 id niet te lang wordt (<= 64 tekens) dan kun je diezelfde V3 id ook nog als Resource.id gebruiken. Echter: II.root is een OID van max 128 tekens en II.extension is een string van max 64 tekens. De extension kan daarbij ook eens speciale tekens bevatten die Resource.id niet wil ondersteunen. Bron voor datatype II bij HL7 NL.

Als het al lastig was om identiteit van een resource stateless vast te stellen dan is er nog een factor: RESTful. We hebben het tot nu toe over duplicaatdetectie als voornaamste drijfveer achter Resource.id. De Resource.id heeft echter ook RESTful implicaties. Je verwacht van een Observation.id = abcdef dat je daar een read op kunt doen met [base]/Observation/abcdef.

Dat vraagt van een server echter dat hij behalve dat hij vanaf een stuk of wat inputvelden een Resource.id kan maken, hij dat andersom ook kan, dus vanaf een Resource.id 'weet' wat dat is. Ik denk dat als we compleet willen zijn, we ook daar rekening mee moeten houden. Stel dat ik als server GET [base]/Observation/1.2.3.4.5.abcdef13 ontvang, dan zou ik "1.2.3.4.5.abcdef13" weer moeten opsplitsen in de oorspronkelijke root+extension en moeten weten of dat een algemene meting, een labbepaling of een journaalregel is om een HIS succesvol te bevragen en het juiste antwoord op te leveren.