PLUGIN - Local Development build (v0.7.0-public-consultation-1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions ( src
)
There are examples where a medication request may include the option of an oral dose or an Intravenous or Intramuscular dose. For example, "Ondansetron 8mg orally or IV twice a day as needed for nausea" or "Compazine® (prochlorperazine) 5-10mg PO or 25mg PR bid prn nausea or vomiting". In these cases, two medication requests would be created that could be grouped together. The decision on which dose and route of administration to use is based on the patient's condition at the time the dose is needed. ( src
)
The codes SHALL be taken from For codes, see VerificatieStatusCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.4--20200901000000
)
The codes SHALL be taken from Unless not suitable, these codes SHALL be taken from ProbleemTypeCodelijsthttp://hl7.org/fhir/ValueSet/condition-category|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.1--20200901000000
)
The codes SHALL be taken from For example codes, see ProbleemNaamCodelijsthttp://hl7.org/fhir/ValueSet/condition-code|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.3--20200901000000
)
The codes SHALL be taken from For example codes, see LocatieCodelijstenhttp://hl7.org/fhir/ValueSet/body-site|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.11--20200901000000
)
The codes SHALL be taken from VerificatieStatusCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.4--20200901000000
)
The codes SHALL be taken from ProbleemTypeCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.1--20200901000000
)
The codes SHALL be taken from ProbleemNaamCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.3--20200901000000
)
The codes SHALL be taken from LocatieCodelijsten
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.11--20200901000000
)
Profile for documents, such as clinical letters and (surgery) reports,
as used within PLUGIN. Copied from the ZorgViewer IG
(referencing was not technically possible since this IG uses R4).
Unless not suitable, these codes SHALL be taken from ZorgverlenerRolCodelijsthttp://hl7.org/fhir/ValueSet/encounter-participant-type|4.0.1
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.5--20200901000000
)
Each occurrence of the zib HealthProfessional is normally represented by two
FHIR resources: a PractitionerRole resource (instance of nl-core-HealthProfessional-PractitionerRole
) and a Practitioner resource (instance of nl-core-HealthProfessional-Practitioner
). The Practitioner resource is referenced from the PractitionerRole instance. For this reason, sending systems should fill the reference to the PractitionerRole instance here, and not the Practitioner resource. Receiving systems can then retrieve the reference to the Practitioner resource from that PractitionerRole instance.
Each occurrence of the zib HealthProfessional is normally represented by two
FHIR resources: a PractitionerRole resource (instance of nl-core-HealthProfessional-PractitionerRole
) and a Practitioner resource (instance of nl-core-HealthProfessional-Practitioner
). The Practitioner resource is referenced from the PractitionerRole instance. For this reason, sending systems should fill the reference to the PractitionerRole instance here, and not the Practitioner resource. Receiving systems can then retrieve the reference to the Practitioner resource from that PractitionerRole instance.
Unless not suitable, these codes SHALL be taken from The codes SHOULD be taken from HerkomstCodelijsthttp://hl7.org/fhir/ValueSet/encounter-admit-source|4.0.1
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.15.1.2--20200901000000
)
Unless not suitable, these codes SHALL be taken from For example codes, see BestemmingCodelijsthttp://hl7.org/fhir/ValueSet/encounter-discharge-disposition|4.0.1
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.15.1.3--20200901000000
)
Unless not suitable, these codes SHALL be taken from ZorgverlenerRolCodelijst
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.5--20200901000000
)
Unless not suitable, these codes SHALL be taken from HerkomstCodelijst
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.15.1.2--20200901000000
)
Unless not suitable, these codes SHALL be taken from BestemmingCodelijst
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.15.1.3--20200901000000
)
The zib HealthcareProvider is mapped to this Organization profile and a profile on Location ( http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
). The Location profile acts as the focal resource of the HealthcareProvider because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. Often there's no clear distinction between an organizational structure and a physical location. As a rule of thumb, locations are always used for recording where a service occurs, and hence where encounters and observations take place.
The codes SHALL be taken from For example codes, see AfdelingSpecialismeCodelijsthttp://hl7.org/fhir/ValueSet/organization-type|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.4--20200901000000
)
The codes SHALL be taken from For example codes, see OrganisatieTypeCodelijsthttp://hl7.org/fhir/ValueSet/organization-type|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.3--20200901000000
)
This datatype defines a common basis for expressing all addresses around the world, but adds extensions to express Dutch addresses specifically, according to the zib AddressInformation v1.1 (2020)
. A Dutch Address still is a proper FHIR Address, which means that systems that cannot interpret the extensions will still be able to render and work with this datatype.
The second addition is that the zib defines its own ValueSet for address types, which can only be partially expressed using the FHIR Address datatype and requires a mapping to multiple elements. The table below explains how the zib concepts are mapped to the various FHIR elements (see the ConceptMaps http://nictiz.nl/fhir/ConceptMap/AdresSoortCodelijst-to-AddressUse
and http://nictiz.nl/fhir/ConceptMap/AdresSoortCodelijst-to-AddressType
as well). The code from the zib should also be included using the extension on Address.extension:addressType
.
The second addition is that the zib defines its own ValueSet for address types, which can only be partially expressed using the FHIR Address datatype and requires a mapping to multiple elements. The table below explains how the zib concepts are mapped to the various FHIR elements (see the ConceptMaps http://nictiz.nl/fhir/ConceptMap/AdresSoortCodelijst-to-AddressUse
and http://nictiz.nl/fhir/ConceptMap/AdresSoortCodelijst-to-AddressType
as well). The code from the zib should also be included using the extension on Address.extension:addressType
.
The codes SHALL be taken from AfdelingSpecialismeCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.4--20200901000000
)
The codes SHALL be taken from OrganisatieTypeCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.3--20200901000000
)
This .name
element accomodates the official parts of a Dutch name according to common international usage and optionally to the zib NameInformation v1.1 (2020)
. An official Dutch name is represented in FHIR as an ordinary international name, optionally augmented using extensions to specify how the last name is built up according to the Dutch rules if conformance to the zib is required. See the guidance on .family
and on .extension:nameUsage
for more information.
Zib TextResult is mapped to this DiagnosticReport profile and a profile on Media ( http://nictiz.nl/fhir/StructureDefinition/nl-core-TextResult.VisualResult
). This DiagnosticReport profile acts as the focal resource of zib TextResult. This profile references the Media resouce through .media.link
that holds the VisualResult information.
Please note that on a functional level, zib TextResult references zib Procedure, but in FHIR this direction is reversed. Therefore, the concept Procedure (NL-CM:13.2.5) is mapped on Procedure.report
in profile nl-core-Procedure-event
instead of in this profile.
Unless not suitable, these codes SHALL be taken from The codes SHOULD be taken from TekstUitslagTypeCodelijsthttp://hl7.org/fhir/ValueSet/report-codes|4.0.1
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.13.2.1--20200901000000
)
Unless not suitable, these codes SHALL be taken from TekstStatusCodelijst
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.13.2.2--20200901000000
)
Unless not suitable, these codes SHALL be taken from TekstUitslagTypeCodelijst
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.13.2.1--20200901000000
)
Unless not suitable, these codes SHALL be taken from For codes, see NationaliteitCodelijst
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.7.6.3--20200901000000
)
Unless not suitable, these codes SHALL be taken from NationaliteitCodelijst
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.7.6.3--20200901000000
)
The codes SHALL be taken from GeslachtCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.0.1.1--20200901000000
)
The codes SHALL be taken from LandCodelijsten
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.10--20200901000000
)
The codes SHALL be taken from BurgerlijkeStaatCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.7.9.1--20200901000000
)
The codes SHALL be taken from RolCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.2--20200901000000
)
The codes SHALL be taken from RelatieCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.1--20200901000000
)
This element can and should not completely capture the AddressInformation concept from zib ContactPerson; it should just be used for the information that is needed for contacting the person in relation to care of the patient. The full address information should instead be captured using an instance of nl-core-ContactPerson
, which can then be referenced from this resource. See the comment on Patient.contact
for more information.
The codes SHALL be taken from CommunicatieTaalCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.7.12.2--20200901000000
)
The zib HealthProfessional is mapped for all but one concept (HealthProfessionalRole) to a profile on Practitioner ( http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
) and this PractitionerRole profile. The PractitionerRole resource covers the recording of the location and types of services that HealthProfessionals are able to provide for a HealthcareProvider. The zib concepts Specialty and HealthcareProvider are therefore mapped onto PractitionerRole.
The codes SHALL be taken from The codes SHOULD be taken from SpecialismeCodelijstenhttp://hl7.org/fhir/ValueSet/c80-practice-codes|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.22--20200901000000
)
The codes SHALL be taken from SpecialismeCodelijsten
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.22--20200901000000
)
The zib Procedure is mapped both to this Procedure profile and a profile on ServiceRequest ( http://nictiz.nl/fhir/StructureDefinition/nl-core-Procedure-request
) to align with the intention of FHIR. All past procedures are covered using this Procedure resource, while all future procedures, including the advised procedures, are covered in the ServiceRequest resource. Both resources contain the zib mappings, with the exception of the Requester concept; this is not relevant for past procedures and has only been mapped to the ServiceRequest profile.
The codes SHALL be taken from For example codes, see VerrichtingTypeCodelijstenhttp://hl7.org/fhir/ValueSet/procedure-code|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.19--20200901000000
)
The codes SHALL be taken from VerrichtingTypeCodelijsten
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.19--20200901000000
)
Please note that the zib concept Location::HealthcareProvider of zib MedicalDevice (NL-CM:10.1.8) is mapped onto this element, but it is also directly represented using a custom extension in the focal profile for that zib ( nl-core-MedicalDevice
). The reason for this is that the Location concept from zib MedicalDevice aligns with the Location concept from zib Procedure, but only for the situation that the Procedure is about placing an implant which is described using the instance of zib MedicalDevice. In this situation, the extension in the nl-core-MedicalDevice profile is redundant and it is advised to only use the current element to represent the Location concept.
De IG en bijbehorende packages worden gepubliceerd op https://plugin.healthcare/fhir
. Hierbij verwijst https://plugin.healthcare/fhir
naar de laatste (minor versie van de laatste) major release. Daaronder zijn de volgende subdirectories te vinden:
De broncode van deze IG wordt gepubliceerd op GitHub
. Ontwikkeling vindt plaats in de main
branch. Na iedere push wordt de code (via GitHub Actions) geautomatiseerd gecompileerd en gepubliceerd op /ci-build
.
Op dit moment richt de Implementatiegids zich op punten 1 t/m 3 uit de opsomming hierboven. Er wordt vooralsnog géén uitspraak gedaan over opslag van gegevens of mechanisme van benaderen. Voor toepassing binnen een datastation dient ook over punt 4 helderheid te worden verschaft. Dit is een onderwerp dat momenteel wordt uitgewerkt door Health-RI
en zal t.z.t. ook in deze IG worgen beschreven.
Ziekenhuizen zijn een belangrijke bron van klinische gegevens. Binnen ziekenhuizen is het elektronische patiëntendossier (epd) hét systeem waarin veel gegevens samenkomen. Deze Implementatiegids werkt daarom een "Common Data Model" (CDM) uit dat een brug slaat tussen de gegevens zoals deze in het epd zijn vastgelegd en de wereld van secundair gebruik ( Figuur 1
). Dit doen we door per FHIR Resource/zib/concept aan te geven welke attributen minimaal noodzakelijk
zijn om breed, secundair gebruik mogelijk te maken. De informatiestroom die hiervoor nodig is, staat schematisch weergegeven in onderstaand figuur. Hierbij wordt eerder werk, zoals de zorginformatiebouwstenen
en de Nederlandse nl-core
FHIR Profielen, zoveel mogelijk hergebruikt.
Vanuit dit FHIR Common Data Model is het vervolgens mogelijk om verschillende datasets samen te stellen, zoals de datasets die nodig zijn voor aanlevering aan de Nederlandse Kankerregistratie of voor het project AI-ondersteund coderen. Ook kunnen de data van hieruit worden omgezet naar andere common data modellen, zoals het OMOP CDM
.
Binnen de use-case "NKR Item" wordt uitgewerkt hoe de PLUGIN-infrastructuur gebruikt kan worden voor gegevensaanlevering. Dit gebeurt in samenwerking met het Radboudumc
in het kader van het project "Over de Muren van de NKR" dat gezamenlijk door IKNL en het Radboudumc wordt uitgevoerd.
Voor hoofd-halstumoren (HHT) wordt een beperkte set ICD-10 codes
gebruikt: C00 - C14
, C30 - C32
; de volledige (sub)set, inclusief sublokalisaties, is vastgelegd in de Valueset Head and Neck Cancer Conditions
. Het doorzoeken van de tabel met diagnoses in het EPD op deze codes, zou de juiste patiënten moeten identificeren.
Binnen het R(H)ONDA
-project, een samenwerking tussen IKNL en Performation, is ervoor gekozen om initieel uit te gaan van de datum van registratie van de diagnose in het EPD. Datamanagers van IKNL kunnen deze datum daarna aanscherpen tot een definitieve incidentiedatum.
