Onco:V1.0Implementatiegids-MDO-verslagen
Dit is een eerste aanzet tot een implementatiegids voor MDO verslagen, i.h.k.v. oncologie voor IKNL uit te wisselen tussen EPD’s en de NKR. De definitieve versie van de implementatiegids wordt opgesteld conform de richtlijnen van FHIR (zal dus ook in HTML beschikbaar komen). Deze voorlopige versie is alleen om de voornaamste aanwijzingen en richtlijnen op een rijtje te zetten. Alles in dit document is voorlopig en kan nog wijzigen, met name de coderingen.
Inleiding
De aanlevering aan het NKR wordt vormgegeven met FHIR QuestionnaireResponse bestanden. Een QuestionnaireResponse bevat een hiërarchische, gegroepeerde verzameling - meestal klinische - bevindingen. Deze structuur sluit goed aan bij gegevensaanlevering aan een registratie zoals de NKR: de aangeleverde gegevens zijn immers de verzameling gegevens uit het primaire zorgproces, die relevant is voor de NKR. In een QuestionnaireResponse kan dus een vrij willekeurige verzameling (klinische) gegevens uitgewisseld worden. Bij een QuestionnaireResponse hoort een Questionnaire: daarin wordt vastgelegd welke gegevens precies worden uitgevraagd. Bij iedere transactie naar de IKNL, zoals de “MDO verslag diagnose en primaire behandeling” hoort dus een Questionnaire. Ieder daadwerkelijk aangeleverd verslag is een QuestionnaireResponse.
Transacties
De volgende transacties voor inzenden MDO verslagen worden onderscheiden
MDOverslag diagnose en primaire behandeling | ART-DECOR | Logical Model | Questionnaire |
MDOverslag post-operatief | ART-DECOR | Logical Model | Questionnaire |
MDOverslag recidief | ART-DECOR | Logical Model | Questionnaire |
MDOverslag post-neoadjuvant en pre-operatief | ART-DECOR | Logical Model | Questionnaire |
MDOverslag post-operatief en post-neoadjuvant | ART-DECOR | Logical Model | Questionnaire |
Inhoud van het MDO verslag
QuestionnaireResponse
XML voorbeeld:
<QuestionnaireResponse xmlns="http://hl7.org/fhir">
<id value="testzh-3141"/>
<language value="nl-NL"/>
Het rapport begint met identificaties en versies, en de gebruikte taal:
- Een uniek id (uniek binnen het verzonden FHIR bericht). Deze begint met een prefix die per ziekenhuis wordt afgesproken met IKNL, zodat de id's uniek zijn binnen de NKR.
- Taal (altijd Nederlands)
Berichten worden door een ziekenhuis verzonden naar de NKR met een [| FHIR update]. Daarbij maakt de inzender een id aan, wat door de NRK server gebruikt wordt als uniek id voor het bericht. Met een FHIR update wordt een resource (de QuestionnaireResponse) aangemaakt als er nog geen resource met id='testzh-3141' bestaat, en wordt de oudere overschreven als deze wel bestaat. Wanneer de connectie verbroken wordt voordat de zender een HTTP response heeft gekregen, kan de resource gewoon opnieuw ingezonden worden. Dit moet herhaald worden totdat de zender een response met '200 OK' of '201 Created' gekregen heeft, wat aangeeft dat de resource is aangemaakt. Zie ook Identifier en document versionering.
text
Iedere FHIR resource bevat een tekstuele weergave van de inhoud. Dat moet HTML zijn, bijvoorbeeld een table of list, maar mag ook een pre element met geformatteerde tekst zijn.
XML voorbeeld:
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<table>
<tr>
<td>Patient</td>
<td>123456</td>
</tr>
<tr>
<td>Zijdigheid inzending</td>
<td>Links</td>
</tr>
<tr>
<td>Lokalisatie tumor</td>
<td>Binnenste bovenkwadrant van de borst</td>
</tr>
....
</table>
</div>
</text>
Dit kan ook:
<text>
<status value="generated"/>
<pre xmlns="http://www.w3.org/1999/xhtml">
Patient : 123456
Zijdigheid inzending : Links
Lokalisatie tumor : Binnenste bovenkwadrant van de borst
</pre>
</text>
Voor de uitwisseling van MDO verslagen is het optioneel, de NKR heeft het niet nodig.
contained
Na text komen een aantal contained resources. Dit zijn onafhankelijke elementen, waarnaar vanuit de QuestionnaireResponse gerefereerd wordt (zie verderop). FHIR is gebaseerd op ‘resources’: losse componenten, die naar elkaar verwijzen. In dit geval worden alle resources opgenomen in dit FHIR bestand zelf. Het voordeel van deze aanpak is dat dezelfde componenten in een andere context ook gebruikt kunnen worden.
Patient
Patiëntgegevens, waaronder een lokaal patiëntennummer of BSN, geslacht en geboortedatum. Het id veld is een FHIR id voor gebruik binnen het FHIR document, niet het patiënt id.
Voor patiënt volgen we de nl-core-patient uit de NL-BasicComponents
De naam wordt gevuld met de gegevens die bekend zijn. Dat kan een eenvoudige weergave zijn zoals hieronder, of een volledige opsplitsing met partner-naam et cetera als beschreven in de NL-BasicComponents.
XML voorbeeld:
<Patient>
<id value="nl-core-patient-example-1" />
<identifier>
<use value="official" />
<system value="http://fhir.nl/fhir/NamingSystem/bsn" />
<value value="123456782" />
</identifier>
<active value="true" />
<name>
<use value="official" />
<family value="Jongeneel-de Haas"/>
<given value="Irma"/>
</name>
<gender value="female" />
<birthDate value="1970-03-04" />
</Patient>
Van een patiënt is meegeven van een identificatie (zoals BSN) verplicht. Meesturen van naam, geslacht en geboortedatum wordt aanbevolen. Andere gegevens zoals adres zijn geen deel van de MDO aanlevering.
Organisatie
Gegevens van het aanleverende ziekenhuis.
Voor organisatie volgen we de nl-core-organization uit de NL-BasicComponents
XML voorbeeld:
<contained>
<Organization>
<id value="organization1"/>
<identifier>
<system value="http://fhir.nl/fhir/NamingSystem/agb-z"/>
<value value="12341234"/>
</identifier>
<active value="true" />
<name value="Ziekenhuis Gooi en Overvecht" />
</Organization>
</contained>
Een identifier is verplicht, daarvoor wordt de AGB-code gebruikt, de naam van het ziekenhuis is wenselijk.
In een FHIR QuestionnaireResponse wordt naar de Organization verwezen in een Device (het EPD) dat het MDO verslag aanlevert.
XML voorbeeld:
<contained>
<Device>
<owner>
<reference value="#organization1"/>
</owner>
</Device>
</contained>
status
De status moet altijd "completed" zijn. XML voorbeeld:
<status value="completed"/>
identifier en document versionering
Iedere QuestionnaireResponse krijgt een identificatie. Dit is een logische identificatie: dus de identificatie van een MDO-verslag, betreffende een bepaalde patiënt en op een bepaald moment gehouden door een groep zorgverleners.
XML voorbeeld:
<identifier>
<system value="http://www.testziekenhuis.nl/mdoverslag-identificaties"/>
<value value="123"/>
</identifier>
In system staat een waarde die bepaald wordt door de inzender. Een vereiste is dat dit een unieke waarde is, die de nummering van de MDO verslagen bij de inzender aanduidt, en die onder controle staat van de inzender (dus niemand anders kan - legaal - dezelfde waarde gebruiken). Dat kan zijn:
- een URL die onder controle staat van de inzender, b.v.: http://www.testziekenhuis.nl/mdoverslag-identificaties
- een OID die onder controle staat van de inzender, b.v.: urn:oid:1.2.3.4.5.6.7 (bij OID's wordt een URI met urn:oid: gebruikt, geen 'losse' OID)
Deze identificatie wijzigt niet als er een nieuwe versie van het verslag komt, bijvoorbeeld omdat gegevens zijn aangevuld of gecorrigeerd. Dat betreft een nieuwe versie van hetzelfde verslag. Een andere identifier duidt er dus op dat het een ander MDO overleg betreft.
Zoals boven aangeven, heeft iedere FHIR resource ook een id. Dat id moet uniek zijn voor alle MDO-verslagen. Dat gebeurt door een unieke prefix per ziekenhuis (af te spreken met IKNL) te nemen met een unieke identificatie erachter, dus b.v. 'umcu-123' of 'amphia-fh12'. Wat achter de prefix staat, mag het MDO-verslagnummer zijn, maar het is in principe vrij. (Let op: FHIR id's staan maar een beperkte set tekens toe.)
Voor de communicatie wordt een FHIR update gebruikt. Dat is een HTTP PUT, met als content de QuestionnaireResponse, waarbij de id wordt aangemaakt door de inzender. (Id's aangemaakt door de inzender zijn eenvoudiger wanneer het EPD wil communiceren via een message queue op een communicatieserver: dan heeft het EPD het id al direct beschikbaar, en hoeft dit niet teruggecommuniceerd te worden.) Communicatie over Internet kan mislukken. Daarom moet de inzender als de connectie verbroken wordt, de FHIR update blijven herhalen tot er een succes status is ontvangen (HTTP status 200 of 201). Een PUT is idempotent: dat wil zeggen dat deze bij herhaald uitvoeren dezelfde toestand van de server oplevert. Concreet: ook al wordt (door verbroken connecties) een MDO verslag tweemaal ingezonden, dan nog zal er maar één aangemaakt worden op de server. Als er later (door wijzigingen in het MDO verslag zelf) een gecorrigeerde versie van het verslag wordt opgestuurd, houdt deze hetzelfde id en identifier. Dat betekent wel dat het ziekenhuis moet borgen dat de laatste versie ook als laatste wordt ingezonden. Wat dus niet mag is deze volgorde: 1. versie 1 van verslag X ingezonden met PUT, connectie verbroken 1. versie 2 van verslag X met wijzigignen ingezonden met PUT, respons '201 Created' 1. tweede poging versie 1 van verslag X in te zenden met PUT, respons '200 OK' In dit geval moet de tweede poging van versie 1 gedaan worden vóór inzenden van versie 2, of helemaal achterwege blijven.
Een voorbeeld van de betekenis van een aantal verschillende waarden ten opzichte van de eerste rij:
id | identifier.system | identifier.value | Betekenis |
---|---|---|---|
tstzh-99 | http://www.testziekenhuis.nl/mdoverslag-identificaties | 123 | Vergelijk de volgende rijen met deze waarden |
tstzh-77 | http://www.testziekenhuis.nl/mdoverslag-identificaties | 234 | Een verslag van een ander MDO overleg uit hetzelfde ziekenhuis |
tstinst-99 | http://www.eeninstelling.nl/ids | 123 | Een verslag van een MDO overleg uit een ander ziekenhuis |
tstzh-99 | http://www.testziekenhuis.nl/mdoverslag-identificaties | 123 | Dezelfde versie van hetzelfde verslag |
tstzh-99 | http://www.testziekenhuis.nl/mdoverslag-identificaties | 345 | Illegaal: een id mag niet hergebruikt worden voor een ander MDO verslag |
Questionnaire
De aanlevering aan de NKR is vormgegeven als een FHIR QuestionnaireResponse. In iedere QuestionnaireResponse zit eerst een verwijzing naar de bijbehorende Questionnaire: dat zijn de definities van de “vragen” die beantwoord worden in de QuestionnaireResponse.
XML voorbeeld:
<questionnaire>
<reference value="http://www.iknl.nl/fhir/Questionnaire/Q_mdoverslag_recidief"/>
</questionnaire>
subject en author
Vervolgens wordt verwezen naar de patiënt en de auteur (Device). Dit zijn interne referenties naar de patiënt en de auteur die opgenomen zijn in de QuestionnaireResponse (zie hierboven bij "contained").
XML voorbeeld:
<subject>
<reference value="#patient1"/>
</subject>
<author>
<reference value="#device1"/>
</author>
items
De daadwerkelijke gegevens beginnen in items. In de Questionnaire is ieder item gedefinieerd:
XML voorbeeld:
<item>
<linkId value="onco-dataelementv1-12001"/>
<definition value="http://www.iknl.nl/fhir/DataElement/onco-dataelementv1-12001"/>
<text value="Multidisciplinair overleg"/>
<type value="group"/>
<required value="false"/>
<repeats value="false"/>
Daarbij wordt aangegeven:
- Het linkId, de formele identificatie van dit gegeven. Een linkId moet uniek zijn binnen de Questionnaire.
- De definition, een link naar een formele specificatie van het gegevensitem. Via het overzicht in transacties zijn deze te bekijken.De definition is tevens een unieke identificatie van het gegevens-item.
- De text, een leesbaar gegeven betreffende het item.
- Een type, wat 'group' of een datatype kan zijn (zie verderop).
- required, wat aangeeft of het verplicht voor moet komen in de QuestionnaireResponse
- repeats, wat aangeeft of het mag herhalen binnen de QuestionnaireResponse.
In een QuestionnaireResponse worden de items als volgt weergegeven:
XML voorbeeld:
<item>
<linkId value="onco-dataelementv1-12001"/>
<definition value="http://www.iknl.nl/fhir/DataElement/onco-dataelementv1-12001"/>
<text value="Multidisciplinair overleg"/>
Ieder item heeft een linkId, een definition en een text attribuut. Het linkId is de relatie naar de definitie van het gegeven in de Questionnaire. Het text attribuut is optioneel in FHIR, maar hier verplicht: het geeft een leesbare aanwijzing waarover het gaat, wat bruikbaar is bij debugging en afhandeling van uitval. Er zijn twee soorten items: group en question.
Items (group)
Group items dienen alleen om de informatie hiërarchisch te organiseren en om herhalende groepen mogelijk te maken. In zowel Questionnaire als een QuestionnaireResponse zijn de group items eenvoudig items die andere items bevatten. Hier de weergave uit de QuestionnaireResponse:
XML voorbeeld:
<item>
<item>
<linkId value="onco-dataelementv1-12001"/>
<definition value="http://www.iknl.nl/fhir/DataElement/onco-dataelementv1-12001"/>
<text value="Multidisciplinair overleg"/>
<item>
<linkId value="onco-dataelementv1-13265"/>
<definition value="http://www.iknl.nl/fhir/DataElement/onco-dataelementv1-13265"/>
<text value="Datum MDO-verslag akkoord"/>
Items (questions and answers)
De feitelijke gegevens zijn in een Questionnaire als question opgenomen, en in de QuestionnaireResponse als corresponderend answer. In een Questionnaire kan dat bijvoorbeeld zo zijn:
XML voorbeeld:
<item>
<linkId value="item-13219"/>
<definition value="http://decor.nictiz.nl/fhir/DataElement/2.16.840.1.113883.2.4.3.11.60.107.2.1.13219--20150617114434"/>
<text value="Geboortedatum"/>
<type value="dateTime"/>
<required value="true"/>
<repeats value="false"/>
</item>
We zien weer de algemene gegevens van een item (linkId en text), en daarnaast:
- een concept, met de codering van de betekenis van het gevraagde gegeven. Dit zullen uiteindelijk meestal Snomed coderingen zijn. Nu zijn het veelal nog ART-DECOR coderingen.
- een type, met daarin het datatype van het gevraagde gegeven.
Een bijbehorend QuestionnaireResponse item ziet er als volgt uit:
XML voorbeeld:
<item>
<linkId value="onco-dataelementv1-13249"/>
<definition value="http://www.iknl.nl/fhir/DataElement/onco-dataelementv1-13249"/>
<text value="Vraagstelling"/>
<answer>
<valueString value="Recidief?"/>
</answer>
</item>
Een gecodeerd item ziet er als volgt uit in de Questionnaire:
XML voorbeeld:
<item>
<linkId value="onco-dataelementv1-12002"/>
<definition value="http://www.iknl.nl/fhir/DataElement/onco-dataelementv1-12002"/>
<text value="Aanwezigheid: specialismen"/>
<type value="choice"/>
<required value="false"/>
<repeats value="true"/>
<option>
<valueCoding>
<code value="304292004"/>
<display value="Chirurg"/>
</valueCoding>
</option>
<option>
<valueCoding>
<code value="8724009"/>
<display value="Plastisch chirurg"/>
</valueCoding>
</option>
<option>
<valueCoding>
...
Na de overige gegevens volgt een lijst met codes waaruit gekozen kan worden. (Noot: het is waarschijnlijk dat in de uiteindelijke specificatie de letterlijk opgenomen lijsten vervangen worden door links naar valueSets op decor.nictiz.nl)
Het bijbehorende antwoord in een QuestionnaireResponse ziet er als volgt uit:
XML voorbeeld:
<item>
<linkId value="onco-dataelementv1-12002"/>
<definition value="http://www.iknl.nl/fhir/DataElement/onco-dataelementv1-12002"/>
<text value="Aanwezigheid: specialismen"/>
<answer>
<valueCoding>
<system value="http://snomed.info/sct"/>
<code value="304292004"/>
<display value="Chirurg"/>
</valueCoding>
</answer>
</item>
Datatypes
De volgende datatypes en bijbehorende elementen in de QuestionnaireResponse worden gebruikt.
Datatype | QuestionnaireResponse | Voorbeeld | Opmerkingen |
---|---|---|---|
boolean | valueBoolean | true, false | |
decimal | valueDecimal | 3.14 | Geen voorloopnullen |
integer | valueInteger | 1999 | Geen voorloopnullen |
date | valueDate | 1961-03-06 | |
dateTime | valueDateTime | 2017-02-06T13:09 | |
time | valueTime | 13:09 | |
string | valueString | Marc de Graauw | |
Coding | valueCoding |
<valueCoding>
<system value="urn:oid:2.16.840.1.113883.5.1"/>
<code value="M"/>
<display value="Male"/>
</valueCoding>
|
|
Quantity | valueQuantity |
<valueQuantity>
<value value="25" />
<unit value="sec" />
<system value="http://unitsofmeasure.org" />
<code value="s" />
</valueQuantity>
|