These codes are excerpted from ISO Standard, TS 21089-2017 - Health Informatics - Trusted End-to-End Information Flows, Copyright by ISO International. Copies of this standard are available through the ISO Web Site at www.iso.org.
This is an example set based on ASTM Standard, E1762-95 (2013) HL7 RoleClass OID 2.16.840.1.113883.5.110, HL7 Role Code 2.16.840.1.113883.5.111, HL7 ParticipationType OID: 2.16.840.1.113883.5.90, HL7 ParticipationFunction codes at OID: 2.16.840.1.113883.5.88, and HL7 Security and Privacy Domain Analysis Model roles classes.
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
Code of Federal Regulation 21CFR§1271.290(c) ( src
)
Koppeltaal 2.0 Implementation Guide (Full Documentation) - Local Development build (v0.16.2) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions ( src
)
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 represents a Dutch name according to the zib NameInformation (v1.1, 2020)
(except for the GivenName concept). A Dutch name is represented in FHIR as an ordinary international name, but is augmented using extensions to specify how the last name is built up according to the Dutch rules. See the guidance on .family
and on .extension:nameUsage
for more information. Systems that need to work in a Dutch context MUST
support these extensions as specified here. In addition, systems MUST
use the core elements according to the FHIR specifications to provide compatibility outside Dutch contexts. It is encouraged to provide a representation of the full name in the .text
element.
The codes SHALL be taken from Unless not suitable, these codes SHALL be taken from BurgerlijkeStaatCodelijsthttp://hl7.org/fhir/ValueSet/marital-status|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.7.9.1--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.
The codes SHALL be taken from TelecomTypeCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.6.1--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 zib HealthProfessional is mapped for all but one concept (HealthProfessionalRole) to this Practitioner profile and a profile on PractitionerRole ( http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
). 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 GeslachtCodelijst
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.8--20200901000000
)
The codes SHALL be taken from The codes SHOULD be taken from RolCodelijsthttp://hl7.org/fhir/ValueSet/relatedperson-relationshiptype|4.0.1
( 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 The codes SHOULD be taken from RelatieCodelijsthttp://hl7.org/fhir/ValueSet/relatedperson-relationshiptype|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.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
)
Role Binding: RolCodelijst (required): The nature of the relationship between a patient and the related person. Constraints: kt2-role-display-validation
Deze pagina beschrijft de autorisatieregels voor een Patient rol binnen het KoppelMij/Koppeltaal geharmoniseerde model, zoals beschreven in Optie 3
van de Koppeltaal Domeinen documentatie.
Deze pagina beschrijft de autorisatieregels voor een Practitioner (behandelaar) rol binnen het KoppelMij/Koppeltaal geharmoniseerde model, zoals beschreven in Optie 3
van de Koppeltaal Domeinen documentatie.
Deze pagina beschrijft de autorisatieregels voor RelatedPersons binnen het KoppelMij/Koppeltaal geharmoniseerde model, zoals beschreven in Optie 3
van de Koppeltaal Domeinen documentatie.
Deze pagina beschrijft het transitieproces van de autorisatiemodellen van Koppeltaal en KoppelMij naar een geharmoniseerd model, zoals beschreven in Optie 3
van de Koppeltaal Domeinen documentatie.
Deze sectie beschrijft de autorisatieregels voor het geharmoniseerde KoppelMij/Koppeltaal model zoals uitgewerkt in Optie 3
van de Koppeltaal Domeinen documentatie.
Deze pagina beschrijft de rol van het CareTeam als zorgcontext
binnen het KoppelMij/Koppeltaal geharmoniseerde model, zoals beschreven in Optie 3
van de Koppeltaal Domeinen documentatie.
Als mijn begrip juist is, mag wat mij betreft het diagram toegevoegd aan de spec. Ik denk dat de twee huidige sequence diagrammen op deze paginaonjuist of in elk geval onduidelijk
zijn."
In dit patroon — gebaseerd op de TA Notified Pull v1.0.1
— neemt de module het initiatief door het EPD actief te notificeren via een Notification Task. De Notification Task bevat verwijzingen naar de op te halen FHIR resources; het EPD haalt op eigen initiatief en tempo de data op bij de bron.
In Koppeltaal wordt op de Task een custom extensie instantiates
gebruikt om te verwijzen naar de ActivityDefinition. Deze extensie is destijds geïntroduceerd omdat het standaard FHIR-element Task.instantiatesCanonical
niet bruikbaar bleek als zoekcriterium. Er is een bijbehorende SearchParameter
gedefinieerd die zoeken op deze extensie mogelijk maakt.
In Koppeltaal wordt op de Task een custom extensie instantiates
gebruikt om te verwijzen naar de ActivityDefinition. Deze extensie is destijds geïntroduceerd omdat het standaard FHIR-element Task.instantiatesCanonical
niet bruikbaar bleek als zoekcriterium. Er is een bijbehorende SearchParameter
gedefinieerd die zoeken op deze extensie mogelijk maakt.
Opmerking
: dit vereist een nieuwe SearchParameter voor de instantiates
extensie op ServiceRequest, analoog aan de bestaande task-instantiates
SearchParameter.
Deze functionaliteit is een uitbreiding op de bestaande Identity Provisioning
configuratie. Waar voorheen per combinatie van domein, applicatie-instantie en gebruikerstype maximaal één IdP geconfigureerd kon worden (0..1), wordt dit uitgebreid naar meerdere IdPs (0..*).
Een tussenvariant is dat zelf-inloggende applicaties wél direct de meta-extension bijwerken (zoals nu), maar daarnaast verplicht een corresponderend AuditEvent moeten schrijven voor audit-completeness. De Koppeltaalvoorziening zou dat dan ofwel kunnen valideren (afdwingen) ofwel als best practice kunnen vastleggen. Deze keuze valt buiten de scope van het huidige voorstel maar is een logisch volgend discussiepunt, met name in relatie tot TOP-KT-011 - Logging en tracing
.
DELETED geschrapt als tag (kan na $purge
niet meer bestaan); Actief en DELETED expliciet als conceptuele eindstaten benoemd; Patient.meta.tag = DELETED
-stap uit overzicht- en interactiediagram verwijderd ( #58
)
Het ECD heeft op grond van de WGBO
een eigen wettelijke bewaartermijn van maximaal 20 jaar voor medische gegevens en is verantwoordelijk voor het tijdig veiligstellen van relevante data uit de Koppeltaalvoorziening.
