De grootste paradigmashift in Koppeltaal 2.0 is de afscheid van de bus-architectuur, waar berichten door middel van een postbus worden uitgewisseld, naar een FHIR resource service waar de gegevens binnen het domein door middel van opgeslagen FHIR objecten worden uitgewisseld. Met deze wijziging wordt een significante verantwoordelijkheid die bij de applicatieleveranciers ligt, het in stand houden van de status quo door het correct verwerken van de berichten, weggenomen. De FHIR resource service is binnen het domein een bron van waarheid waar applicaties op elk gekozen moment terecht kunnen voor de laatste versie van de resources binnen het domein. Deze paradigmashift vereist dat er wordt nagedacht over hoe naar Koppeltaal 2.0 te migreren.
Koppeltaal 1.x maakt gebruik van FHIR DSTU3 en message bundles. Alle resources binnen de bundle, net als de bundle zelf, moeten uniek geïdentificeerd worden met de resource link. Verder, hebben sommige entiteiten, maar niet alle, een een FHIR identifier. Een FHIR identifier bestaat uit een system en een waarde. Het system maakt het mogelijk te differentiëren in verschillende type identifiers.
<identifier>
<system>https://example.com/identifiers/email</system>
<value>bert@example.com</value>
</identifier>
Koppeltaal 2.0 maakt gebruik van R4, in FHIR R4 kent elk object een logical id en een type. Met de combinatie van deze twee is het mogelijk een canonical URL te maken, hetgeen lijkt op de resource link. Daarnaast kan, net als in FHIR DSTU3 een object één of meerdere identifier hebben.
In Koppeltaal 2.0 en FHIR R4 is er echter een belangrijk verschil rond de logical id / resource link. Waar in Koppeltaal 1.x deze door de maken van de resource wordt toegewezen, gebeurt dit in Koppeltaal 2.0 door de FHIR resource service, zie ook TOP-KT-003 - Logische ID, bedrijfsidentifier, referenties en referentie integriteit .
Gegeven de bovenstaande observaties is er een oplossingsrichting bedacht waar gebruik wordt gemaakt van een tijdelijk, migratiespecifieke, identifier. Deze identifier heeft een specifiek systeem en in de waarde is de resource link waarmee de resource in Koppeltaal 1.x uniek wordt geïdentificeerd. Deze tijdelijke identifier maakt het mogelijk de Koppeltaal 1.x identifier van resources van de bron van de resource naar de afnemers van de resource te communiceren. Bij het aanmaken van de resource in het Koppeltaal 2.0 domein voegt het bronsysteem de waarde van de Koppeltaal 1.x resource link toe aan de entiteit, zodat het systeem wat deze ontvangt op basis van deze identifier de entiteit in de database correct kan verwerken.
De tijdelijke identifiers maken geen gebruik van versionering, enkel de laatste versie van het koppeltaal 1.x object wordt gebruikt.
Het systeem van de tijdelijke identifier is:
http://koppeltaal.nl/migration/identifier/<resource-type>
De use van de identifier heeft de waarde temp.
Een voorbeeld van een identifier van een patient resource:
{
"resourceType": "Patient",
"id": "patient-botje-minimaal",
"meta": {
"profile": [
"http://koppeltaal.nl/fhir/StructureDefinition/KT2Patient"
]
},
"identifier": [
{
"use": "temp",
"system": "http://koppeltaal.nl/migration/identifier/Patient",
"value": "..."
},
{
"use": "official",
"system": "irma",
"value": "berendbotje01@vzvz.nl"
}
],
"active": true,
...
}
In KT1.x zijn de Tasks onderdeel van het CarePlan en hebben geen eigen resource link, maar wel een unieke identifier in de vorm van een id. In dit geval stellen we voor een niet-bestaande resource-type te gebruiken, de CarePlanActivity. Het system van de tijdelijke identifier is dan http://koppeltaal.nl/migration/identifier/CarePlanActivity.
Vooralsnog zijn er geen andere geneste datatypen bekend, indien deze worden gevonden, wordt aangeraden ook in dat geval gebruik te maken van een fictieve, nog overeen te komen, resource-type.
De oplettende lezer van het voorgaande neemt waar dat er in de bovengestelde oplossingsrichting een sterke afhankelijkheid bestaat tussen de bronhouder en afnemer van de resource; waar verwijzingen bestaan tussen resources is het onmogelijk de resources te publiceren alvorens deze zelf te publiceren. Er ligt dus letterlijk een kleine puzzel aan afhankelijkheden die per domein gelegd moet worden.