Onco:V1.0Implementatiegids-MDO-verslagen

Uit informatiestandaarden
Versie door Marc (overleg | bijdragen) op 6 mrt 2017 om 10:54
Naar navigatie springen Naar zoeken springen

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="3141"/>
    <meta>
        <profile value="http://www.iknl.fhir/mdo_verslag_diagnose_20161112"/>
    </meta>
    <language value="nl-NL"/>

Het rapport begint met identificaties en versies, en de gebruikte taal:

  • Een uniek id (uniek binnen het verzonden FHIR bericht)
  • Versie Oncologie standaard voor deze transactie
  • Taal (altijd Nederlands)

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/ura" />
            <value value="12341234" />
        </identifier>
        <active value="true" />
        <name value="Ziekenhuis Gooi en Overvecht" />
    </Organization>
</contained>

Een identifier is verplicht, de naam van het ziekenhuis is wenselijk.

status

De status moet altijd "completed" zijn. XML voorbeeld: 

<status value="completed"/>

Document versionering en identifier

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:

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.

Wanneer er een nieuwe versie van hetzelfde verslag komt, blijft de identifier hetzelfde, maar het id wijzigt: iedere aangemaakte (en verstuurde) QuestionnaireResponse krijgt een eigen, uniek id, ongeacht of er al een ander verslag van hetzelfde MDO overleg is verzonden. Meta.lastUpdated is een gegevens waarmee de volgordelijkheid van versies van MDO verslagen aangegeven kan worden. Deze moet altijd hoger zijn voor latere versies. Dat betekent niet per se dat deze in oplopende waarden binnenkomen. Bij berichtenverkeer over Internet valt niet te garanderen dat de volgorde van binnenkomende HTTP calls dezelfde is bij zender en ontvanger. De ontvanger moet dus altijd kijken naar de waarden die in meta.lastUpdated staan, niet naar de volgorde van binnenkomst om te bepalen wat de laatste versie van een MDO verslag is. Een inzender mag een verslag meerdere malen insturen, bijvoorbeeld wanneer de HTTP connectie verbroken werd en de inzender dus niet weet of het verslag is aangekomen. In dat geval wordt hetzelfde id, dezelfde meta.lastUpdated en dezelde identifier.value gebruikt: het betreft immers dezelfde versie van hetzelfde verslag.

Een voorbeeld van de betekenis van een aantal verschillende waarden ten opzichte van de eerste rij:

id meta.lastUpdated identifier.system identifier.value Betekenis
99 2017-03-06T13:12:11+01:00 http://www.testziekenhuis.nl/mdoverslag-identificaties 123 Vergelijk de volgende rijen met deze waarden
1100 2017-03-03T10:11:12+01:00 http://www.testziekenhuis.nl/mdoverslag-identificaties 123 Een eerdere versie van het verslag
55 2017-03-06T15:16:17+01:00 http://www.testziekenhuis.nl/mdoverslag-identificaties 123 Een latere versie van het verslag
77 2017-03-06T13:12:11+01:00 http://www.testziekenhuis.nl/mdoverslag-identificaties 234 Een verslag van een ander MDO overleg uit hetzelfde ziekenhuis
99 2017-03-06T13:12:11+01:00 http://www.eeninstelling.nl/ids 123 Een verslag van een MDO overleg uit een ander ziekenhuis
99 2017-03-06T13:12:11+01:00 http://www.testziekenhuis.nl/mdoverslag-identificaties 123 Dezelfde versie van hetzelfde verslag
99 2017-03-03T11:12:13+01:00 http://www.testziekenhuis.nl/mdoverslag-identificaties 123 Illegaal: hetzelfde id met een andere Meta.lastUpdated kan niet

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="../Questionnaire/2.16.840.1.113883.2.4.3.11.60.107.4.22--20151022132049.xml"/>
</questionnaire>

subject en author

Vervolgens wordt verwezen naar de patiënt en de auteur (TODO: is de auteur een organisatie of zijn het een of meer personen?). 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="#organization1"/>
</author>

items

De daadwerkelijke gegevens beginnen in items. In de Questionnaire is ieder item gedefinieerd:

XML voorbeeld: 

<item>
    <linkId value="item-1000"/>
    <definition value="http://decor.nictiz.nl/fhir/DataElement/2.16.840.1.113883.2.4.3.11.60.107.2.1.1000--20150409000000"/>
    <text value="Demografische gegevens"/>
    <type value="group"/>
    <required value="true"/>
    <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="item-1000"/>
    <definition value="http://decor.nictiz.nl/fhir/DataElement/2.16.840.1.113883.2.4.3.11.60.107.2.1.1000--20150409000000"/>\
    <text value="demografische_gegevens"/>

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>
    <linkId value="item-1000"/>
    <text value="demografische_gegevens"/>
    <item>
        <linkId value="item-13187"/>
        <text value="patient"/>

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="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"/>
    <answer>
        <valueString value="1986-12-06T12:00:00"/>
    </answer>
</item>

Een gecodeerd item ziet er als volgt uit in de Questionnaire:

XML voorbeeld: 

<item>
    <linkId value="item-13220"/>
    <definition value="http://decor.nictiz.nl/fhir/DataElement/2.16.840.1.113883.2.4.3.11.60.107.2.1.13220--20150617114434"/>
    <text value="Geslacht"/>
    <type value="choice"/>
    <required value="true"/>
    <repeats value="false"/>
    <option>
        <valueCoding>
            <code value="UN"/>
            <display value="Undifferentiated"/>
        </valueCoding>
    </option>
    <option>
        <valueCoding>
            <code value="M"/>
            <display value="Male"/>
        </valueCoding>
    </option>
    <option>
        <valueCoding>
            <code value="F"/>
            <display value="Female"/>
        </valueCoding>
    </option>
</item>

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="item-13220"/>
    <definition value="http://decor.nictiz.nl/fhir/DataElement/2.16.840.1.113883.2.4.3.11.60.107.2.1.13220--20150617114434"/>
    <text value="geslacht"/>
    <answer>
        <valueCoding>
            <system value="urn:oid:2.16.840.1.113883.5.1"/>
            <code value="M"/>
            <display value="Male"/>
        </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 1, 999 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>

Triggers

Document identificatie

Wijzigingen en beheer

Overgenomen van "https://informatiestandaarden.test-nictiz.nl/index.php?title=Onco:V1.0Implementatiegids-MDO-verslagen&oldid=9710"