|
Type
|
Reference
|
Content
|
|
web
|
docs.plugin.healthcare
|
|
|
web
|
github.com
|
Project (per resource)
|
|
web
|
github.com
|
Alle issues
|
|
web
|
github.com
|
Zorgviewer-IG RIVO Noord
|
|
web
|
fhir.github.io
|
SQL-on-FHIR
|
|
web
|
pathling.csiro.au
|
Pathling
|
|
web
|
github.com
|
hdc-sql-on-fhir
|
|
web
|
fshschool.org
|
FSHSchool - Deep Dive with FSH
|
|
web
|
informatiestandaarden.nictiz.nl
|
Informatiestandaard Geboortezorg
|
|
web
|
github.com
|
GitHub
|
|
web
|
plugin.healthcare
|
IG © 2024+ PLUGIN
. Package default#0.0.2-ci based on FHIR 4.0.1
. Generated 2025-05-30
Links: Table of Contents |
QA Report
|
|
web
|
en.wikipedia.org
|
Both Bundle.link and Bundle.entry.link are defined to support providing additional context when Bundles are used (e.g. HATEOAS
).
|
|
web
|
nictiz.nl
|
In addition to a coding from this ValueSet, the corresponding coding from the FHIR base ValueSet SHALL be communicated. The ConceptMap http://nictiz.nl/fhir/ConceptMap/VerificatieStatusCodelijst-to-ConditionVerificationStatus
can be used to relate these two ValueSets.
|
|
web
|
github.com
|
Condition as used within PLUGIN. Maturity Level: 0 Draft. Open issues see Github
.
|
|
web
|
nictiz.nl
|
Code defined by a terminology system
Binding:
VerificatieStatusCodelijst
(
required
)
:
In addition to a coding from this ValueSet, the corresponding coding from the FHIR base ValueSet SHALL be communicated. The ConceptMap
http://nictiz.nl/fhir/ConceptMap/VerificatieStatusCodelijst-to-ConditionVerificationStatus
can be used to relate these two ValueSets.
ele-1:
All FHIR elements must have a @value or children
|
|
web
|
nictiz.nl
|
Code defined by a terminology system
Binding:
VerificatieStatusCodelijst
(
required
)
:
In addition to a coding from this ValueSet, the corresponding coding from the FHIR base ValueSet SHALL be communicated. The ConceptMap
http://nictiz.nl/fhir/ConceptMap/VerificatieStatusCodelijst-to-ConditionVerificationStatus
can be used to relate these two ValueSets.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
github.com
|
Contactmoment tussen patiënt en zorgverlener. Maturity Level: 0 Draft. Open issues see Github
.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
zibs.nl
|
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.
|
|
web
|
nictiz.nl
|
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
.
|
|
web
|
nictiz.nl
|
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
.
|
|
web
|
zibs.nl
|
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.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
github.com
|
DiagnosticReport as used within PLUGIN for Pathology. Maturity Level: 0 Draft. Open issues see Github
.
|
|
web
|
zibs.nl
|
This .name
element represents the Dutch given name ("roepnaam") according to the zib NameInformation v1.1 (2020)
.
|
|
web
|
nictiz.nl
|
The RelatedPerson resource is used to capture information about any person that is related to the patient, using the profile http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson
.
|
|
web
|
nictiz.nl
|
Reference to an nl-core-ContactPerson
instance containing the full details for the current contact.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
github.com
|
Describes the Patient resource as used by the Dutch PLUGIN project. Inherits from nl-core-Patient
. Maturity Level: 0 Draft. Open issues see Github
.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
github.com
|
Describes the PractitionerRole resource as used by the Dutch PLUGIN project. Maturity Level: 0 Draft. Open issues see Github
.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
nictiz.nl
|
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.
|
|
web
|
github.com
|
Procedure as used within PLUGIN. Inherits from
nl-core-Procedure-event
. Maturity Level: 0 Draft. Open issues see Github
.
|
|
web
|
snomed.info
|
~
ConceptMap-dxt2snomed.html
|
|
web
|
plugin.healthcare
|
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:
|
|
web
|
github.com
|
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
.
|
|
web
|
github.com
|
Continuous integration build. Follows the main branch
on GitHub.
|
|
web
|
github.com
|
Intended to point to the current (stable) release of the IG. At least, when the first version is released. Follows the version/latest
tag on GitHub.
|
|
web
|
www.atr-regeldruk.nl
|
Om de zorg betaalbaar, toegankelijk en van goede kwaliteit te houden, zijn inzichten uit klinische data essentieel. Het verkrijgen van zulke inzichten is een grote uitdaging door IT-systeemheterogeniteit, patiëntendossierorganisatie en ongestructureerde informatie, zoals verslagen en brieven. Uitwisseling en hergebruik van data is daardoor voor ziekenhuizen complex en arbeidsintensief. Landelijke registraties spelen hierin een belangrijke rol: een Nederlands ziekenhuis participeert gemiddeld in
60
registraties. Automatisering verlicht deze druk natuurlijk, maar ook geautomatiseerde processen vergen onderhoud.
|
|
web
|
en.wikipedia.org
|
Via deze federatieve aanpak is het ook mogelijk om statistische analyses uit te voeren of om modellen te trainen middels Machine Learning
. Technieken uit de Kunstmatige Intelligentie (AI) bieden zelfs de mogelijkheid om van gegevens uit ongestructureerde bronnen te leren, zoals medische verslaglegging of radiologiebeelden.
|
|
web
|
www.health-ri.nl
|
De infrastructuur past binnen de kaders van Health-RI
.
|
|
web
|
www.cumuluz.org
|
CumuluZ
|
|
web
|
health.ec.europa.eu
|
de EHDS
.
|
|
web
|
en.wikipedia.org
|
Daarom is besloten om een AI-model te ontwikkelen dat automatisch dagopnamen kan voorzien van een ICD-10 codering. Het NLP
-model (AI) is ontwikkeld op ongestructureerde data (ontslabrieven, polibrieven, OK-verslagen en PA-verslagen). Het model is momenteel (okt 2023) in staat om 70% van de dagopnamen te voorzien van een automatische codering.
|
|
web
|
radboudumc.nl
|
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.
|
|
web
|
terminologie.nictiz.nl
|
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.
|
|
web
|
iknl.nl
|
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.
|
|
web
|
spcare.bmj.com
|
Op basis van Boddaert et al.
worden de volgende indicatoren opgenomen:
|
