Randvoorwaarden

Uit eerder onderzoek is gebleken dat deelnemers zelf de mogelijkheid willen hebben om aan te geven dat de informatie die wordt opgestuurd is gecontroleerd/gevalideerd. Om goed te kunnen monitoren moet de data tijdig worden verstuurd (en kan dus niet wachten op een controle). Daarom zal er aan elke QuestionnaireRespone (QR) een item worden opgenomen die aangeeft of de informatie is gecontroleerd. Het gevolg van deze opzet is dat we onderscheid kunnen maken tussen gevalideerde en ongevalideerde informatie:

Gevalideerd: De data is door de deelnemer gevalideerd volgens de normale NICE regels. Deze data zal vervolgens worden gebruikt voor alle output van de NICE: data-in-beeld, jaarrapportages, nice analyse tool, etc.
Ongevalideerd: De data is door de deelnemer (nog niet geheel) gevalideerd en kan dus later nog worden gecorrigeerd. Te denken aan opname informatie zoals ic-opname datum en -tijd, apache IV diagnose etc.

Ondersteuning meerdere versies

In elk bericht moet duidelijk zijn volgens welke definitie deze is opgesteld zodat deze op een juiste manier kan worden verwerkt. Een registratie ontwikkelt zich steeds verder en verandert in de tijd naar aanleiding van onderzoek of bijvoorbeeld samenwerking met andere registraties of projecten. Een EPD leverancier heeft tijd nodig om aanpassingen te kunnen maken en een deelnemer heeft tijd nodig om de aanpassingen te testen en door te voeren. In de Questionnaire zal een voorlopige en definitieve datum worden opgenomen indien duidelijk is dat de Questionnaire moet worden uitgefaseerd. De voorlopige datum zal dan als waarschuwing doen afgaan, een definitieve datum zal worden gebruikt om de berichten te weigeren.

Door het ondersteunen van meerdere versies is het ook mogelijk om snel een eenvoudige, dat wil zeggen een definitie zonder (veel) rekening te houden met ZIB’s, eerste versie op te stellen. Een volgende versie zou dan wel meer rekening kunnen houden met ZIB’s.

Meer over versies

Opnames verwijderen

Het moet mogelijk zijn om opnames te verwijderen. In tegenstelling tot de Microsoft Access bestanden waarmee het niet mogelijk was om reeds opgestuurde records te verwijderen, moet het met FHIR wel mogelijk zijn om opnames te verwijderen die bijv dubbel zijn of niet hebben plaatsgevonden. De NICE server zal wel een versie bewaren binnen de meta-data.

Opnames compleet versturen

Om de processen zo eenvoudig mogelijk te houden, willen we de patient-gerelateerde informatie altijd compleet (tot op dat moment) ontvangen. De maandelijkse datasets hebben de regel: “Het MDS record, met alle gerelateerde informatie van de andere modules zoals de kiic, sofa, etc.” Voor de eerste versie van de berichten willen we deze regel intact houden, wel met in achtneming van het moment van opsturen. Dit betekent bijv dat bij opname alleen de patient info, apache diagnose, ic opname etc is, maar bijv op het moment van ic ontslag pas alle kiic-glucoseregulatie metingen. We zullen de Data Dictionary (DD) updaten met informatie over wanneer welke gegevens worden verwacht.

Voldoen aan FHIR standaard

De aanlevering met FHIR moet voldoen aan de FHIR standaard (versie R4). Daar waar de standaard advies geeft m.b.t. technische werking van de NICE-FHIR server, zal NICE zoveel mogelijk opvolging aan geven.