Quality Assurance - Template - Technisch Ontwerp

Uit informatiestandaarden
Versie door Ashwin Djorai (overleg | bijdragen) op 26 jun 2025 om 11:36 (→‎Boundaries & relationships)
Ga naar: navigatie, zoeken
Under construction icon-blue.png This article or section is in the middle of an expansion or major restructuring and is not yet ready for use.


Processen: | Verkennen | Ontwikkelen & Testen | Publiceren | Beheren | Kwalificeren

Back to Top

Hoofdproces


Proceskaart Ontwikkelen Proceskaart Testen


1 Introduction

An Information Standard (IS) has both a functional and a technical specification, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.
The template is annotated by the following:

  • Goal: What the goal of the section is and what information it should include.
  • Standard text: Standard sentences to include if appropriate.
  • Examples: These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
  • Placeholders: "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.


Goal: The Guidance chapter is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

Standard text: This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>.

Example BgZ-MSZ 2.0 FHIR STU3:
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: see BgZ main page.

In addition, the guidelines as specified in general FHIR STU3 Implementation Guide apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the use case overarching principles and the use of FHIR packages.

1.1 Support

Standard text: For questions, feedback, or change requests, please contact our support team at Nictiz Servicemanagement.

1.2 Known issues

Standard text: The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [Link-to-FO | FO (in Dutch)].

2 Boundaries & relationships

Goal: In this chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

3 Workflows & transactions

Goal: To show the reader which special workflows they should implement. Most of the information regarding workflows should be available in the FO. The only information relevant here are regarding special implementations of these workflows such as the Notified Pull. This should also include a diagram of the workflow for specific actors.

Long example eOverdracht, FHIR STU3 (click to expand):

3.1 Workflow and message structure

3.1.1 Overview

Although the eOverdracht is currently limited to the transfer of the nursing handoff, the ultimate vision is to have a workflow which may include the negotiation of the transfer of the patient. For this reason, a Task resource is used as the entry point for all data exchanges (see #Use of the Composition resource).

3.1.2 Task

3.1.2.1 Task requirements

The requirements for the Task resource in the eOverdracht context are specified using the eOverdracht-Task profile. This profile SHALL be used for the eOverdracht workflow.

The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.

Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task (see #Notifications), but the receiving XIS could use a polling mechanism as well.

For each combination of sending and receiving XIS, a dedicated instance of the Task resource SHALL be used for each transfer situation.

3.1.2.2 Task invocations

The receiving XIS can query the Task at the sending XIS by using the Task.id which is communicated in the notification: 

 GET base/Task/[Task.id]

Note: It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.

The receiving XIS can update a Task hosted by the sending XIS using a PUT operation: 

 PUT base/Task/[Task.id]

The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with a HTTP 422 status code and an OperationOutcome detailing the problem.

3.1.2.3 Notifications

It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the Task.id to the receiving XIS.

A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request combined with an authorization header on a pre-determined endpoint at the party that should be notified, with the Task.id appended as path component: 

 POST [base]/[Task.id]

The notified party is expected to respond with HTTP status code 202 Accepted to inform the notifying party that the notification was successfully received.

3.1.3 Use of the Composition resource

The nursing handoff (Overdrachtsbericht) is mainly built up of individual FHIR resources, selected by the sending organization to form a coherent set of information relevant to the receiving organization. The bulk of these resources are not referenced directly from the Task. Instead, the Task references a Composition resource which in turn assembles the references to all individual FHIR resources. For this purpose, the Composition profiles described in #FHIR profiles SHALL be used.

3.1.3.1 Composition invocations

The receiving XIS MAY use either of the following mechanism for retrieving the individual FHIR resources referenced in the Compostion resource.

As a Document
The receiving XIS uses the $document operation to retrieve both the Composition and all referenced resources as a single document Bundle.
GET [base]/Composition/[Composition.id]/$document
Note: the Compositions list just the resources that act as the entry point for the various concepts in the eOverdracht transactions, but each of these referenced resources may further refer other resources not listed there. The sending system SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.
Individual requests
The receiving XIS first retrieves the Composition resource
GET [base]/Compositon/[Composition.id]
Then the necessary other resources referenced can be fetched using a GET interaction.

The sending XIS SHALL support both mechanisms.

3.1.3.2 Exchanging data as unstructured text

The information standard requires that all information described is exchanged in a structured way, according to the FHIR profiles described on this page. However, some systems are not able to support the full extent of the standard yet and may need to send part of the data as formatted text. The following implementation advice provides guidance on how systems with such a need may accomplish this exchange.

  • All unstructured (textual data) is collected in one single PDF/A document.
  • This document is added to the Composition resource representing the nursing handoff, in the following way:
    • An additional Composition.section is created, with .section.code set to SNOMED CT/703852005 (Narrative comment section).
    • In this section, there is a single .section.entry, and it refers to a DocumentReference resource.
    • This DocumentReference resource references the PDF/A document containing the unstructured text.

The use of the DocumentReference resource allows the sender to specify additional metadata about the document, if needed. It also prevents that the PDF/A is directly included when the Composition is requested using the $document operation, which could lead to unexpected large data volumes.

3.1.4 Using Task to manage the workflow

The Task is the main entry point for the eOverdracht transactions. The eOverdracht workflow starts with the retrieval of a new Task instance by the receiving XIS, and all subsequent steps in the workflow are mediated by updates to this Task instance.

The eOverdracht transactions are mapped to FHIR in the following way:

eOverdracht transaction Task
Confirm transfer
  • sending XIS updates Task:
    • Task.status = in-progress
  • (sending XIS sends notification to receiving XIS)
Send nursing handoff
  • Sending XIS creates nursing handoff Composition
  • Sending XIS updates Task:
    • Task.input:nursingHandoff contains reference to the nursing handoff Composition resource
  • (sending XIS sends notification to receiving XIS)
Send confirmation of nursing handoff
  • Recieving XIS updates Task:
    • Task.status = completed

The following sequence diagrams illustrate the relevant exchanges and state transitions:

Normal flow
2024-04-12-eOverdracht-TransferPhase.svg

The initial eOverdracht 4.0 version has to be carried out without the negotiation phase, the sending XIS will create the Task instance with Task.status already set to in-progress and Task.input:nursingHandoff populated. The full eOverdracht Task workflow will be supported but is out of scope for the 4.0 version.

3.1.4.1 Brokers

The use of a broker to find an available healthcare provider for the patient transfer fall outside the scope of the eOverdracht information standard. However, it is possible to start the workflow without knowing the receiving organization, which allows for the use of a broker. In this situation, for the sending XIS the broker acts as a receiving XIS, and for the receiving XIS the broker acts as a sending XIS.

When Task.input:nursingHandoff is populated with the nursing handoff Composition, Task.owner MUST be populated with the receiving organization.

4 Actors involved

Goal: To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

Standard text:

Actors Systems FHIR Capability Statements
Name Description Name Description Name Description

Example LaboratoryResults 2.0.42:

Persons Systems FHIR Capability Statements
Name Description Name Description Name Description
Patient The user of a personal healthcare environment. PHR Personal health record Verwijzing.png CapabilityStatement: Client LaboratoryResults process client requirements
Healthcare professional The user of a XIS XIS Healthcare information system Verwijzing.png CapabilityStatement: Server LaboratoryResults server requirements

5 Use cases

Goal: In this chapter, the use cases of an IS are elaborated through transactions. A transaction is a full data exchange message (applicable to multiple use cases). A use case should include information about the (earlier specified) involved actors. It should also include information regarding the specific transaction and the available invocations (e.g., FHIR queries).

5.1 <Use case 1>

5.1.1 Involved actors

Standard text:

Transaction group Transaction Actor Role


5.1.2 Invocations

Goal: To give an overview of the invocations used to query FHIR servers in the use case.

Standard text:

Query Description
<sorting variable 1 (e.g., FHIR resource or FO chapter)>
<HCIM 1> 
 <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>
<Description of queried data>
<HCIM 2> 
 see Patient.maritalStatus
<Description of queried data>
<sorting variable 2 (e.g., FHIR resource or FO chapter)>
<HCIM 3> 
 <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>
<Description of queried data>

Example BgZ-MSZ 2.0 STU3: (click to expand):

6 FHIR Query Specification

The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

Query Description
1 Demographics and identification
1.1 Patient 
GET [base]/Patient?
_include=Patient:general-practitioner

The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.

  • The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
  • If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
  • Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
1.2 Marital status 
see Patient.maritalStatus

Marital status data are exchanged via the patient resource (see 1.1).

2 Financial information
2.1 Payer 
GET [base]/Coverage?
_include=Coverage:payor

The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.

  • The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
3 Treatment restrictions
3.1 Treatment instructions 
GET [base]/Consent?
category=http://snomed.info/sct|11291000146105

All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.

  • The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
3.2 Advance directive 
GET [base]/Consent?
category=http://snomed.info/sct|11341000146107

All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.

  • The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
  • the document is only exchanged via a pdf.
4 Contact persons
4.1 Contact 
Patient.contact

Primary partner/contact data are exchanged via the patient resource (see 1.1).

5 Functional/mental status
5.1 Functional or mental status 
GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006

All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.

  • Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
  • Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
  • please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
  • The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
6 Complaints and diagnoses
6.1 Problem 
GET [base]/Condition

All problems available in the source system are returned as zib-Problem instances.

  • The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
  • Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
  • Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
7 Social history
7.1 Living Situation 
GET [base]/Observation?
code=http://snomed.info/sct|365508006

All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.

  • The Observation.category is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
  • The HouseType cardinality is 1..1R and must be exchanged accordingly.
7.2 Drug Use 
GET [base]/Observation?
code=http://snomed.info/sct|228366006

All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.

  • The Observation.category is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
  • The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
7.3 Alcohol Use 
GET [base]/Observation?
code=http://snomed.info/sct|228273003

All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.

  • The Observation.category is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
7.4 Tobacco Use 
GET [base]/Observation?
code=http://snomed.info/sct|365980008

All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.

  • The Observation.category is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
7.5 Nutrition Advice 
GET [base]/NutritionOrder

All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.

  • The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
8 Alerts
8.1 Alert 
GET [base]/Flag

All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.

9 Allergies
9.1 Allergy Intolerance 
GET [base]/AllergyIntolerance

All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.

  • According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
"manifestation":{
   "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
      "valueCode": "unknown"
    }]
  },
10 Medication
10.1 Medication Agreement 
GET [base]/MedicationRequest?
category=http://snomed.info/sct|16076005&
_include=MedicationRequest:medication

All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.

  • The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
  • The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
10.2 Administration Agreement 
GET [base]/MedicationDispense?
category=http://snomed.info/sct|422037009&
_include=MedicationDispense:medication

All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.

  • The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
  • The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
10.3 Medication Use 
GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication

All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.

  • The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
  • The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
11 Medical devices
11.1 Medical device 
GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device

All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.

  • The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
12 Vaccinations
12.1 Vaccination 
GET [base]/Immunization?
status=completed

All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.

  • Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
13 vital signs and measurements
13.1 Blood pressure 
GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9

The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.

  • The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
  • The Observation.effectiveDateTime is used to determine the last known Observation.
13.2 Body weight 
GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7

The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.

  • The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
  • The Observation.effectiveDateTime is used to determine the last known Observation.
13.3 Body height 
GET [base]/Observation/$lastn?
code=http://loinc.org|8302-2, 
http://loinc.org|8306-3, 
http://loinc.org|8308-9

The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.

  • By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
  • If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
  • The Observation.effectiveDateTime is used to determine the last known Observation.
14 Results
14.1 Laboratory test result 
GET [base]/Observation/$lastn?
category=http://snomed.info/sct|49581000146104
&_include=Observation:related-target

All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.

  • Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
  • The optional ResultType is not used when selecting Laboratory results for exchange.
  • The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
15 Procedures
15.1 Procedure 
GET [base]/Procedure?
category=http://snomed.info/sct|387713003,
http://snomed.info/sct|258174001

All operative and image guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.

  • Surgical procedure are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
  • Image guided procedures are exchanged via an instance where the Procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).

Procedure instances with any other category that the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

16 Encounters
16.1 Encounter 
GET [base]/Encounter

All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.

17 Planned care activity
17.1 Procedure 
GET [base]/ProcedureRequest?status=active

All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.

18 Care Setting
18.1 Health professional 
GET [base]/CareTeam?status=active&_include=CareTeam:participant

All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.

  • Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
18.2 Healthcare provider 
see Procedure.performer
see Encounter.serviceProvider

Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.

Meta data
Meta data 
GET [base]/Provenance

All provenance data available in the source system for a specific BgZ summary is exchanged as FHIR provenance instances according to the BgZ-metadata profile.

Table 4. FHIR queries used to retrieve BgZ MSZ components.


6.1 <Use case 2>

6.1.1 Involved actors

6.1.2 Invocations

7 Data exchange standard

Goal: This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA) and HL7v2 are not supported yet.

7.1 HL7 FHIR

Goal: Every implementation of the standard will require the availability of the information presented here.

7.1.1 Artifacts

Goal: This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).
For example, the link to the BgZ-MSZ 2.0 FO would be: [2.0 Chapter 2.1.1] In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

  1. Chapter - The relevant chapter from the FO.
  2. HCIM - The name of the HCIM to be exchanged.
  3. Target - The FHIR resource or data element used to exchange the specified HCIM.
  4. Profile - The FHIR profile used in this information standard. Use Sjabloon Simplifier.


Example BgZ-MSZ 2.0 FHIR STU3:

Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
Chapter HCIM Target Profile
1 Patient Patient http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient
MaritalStatus Patient.maritalStatus
2 BloodPressure Observation http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure
BodyWeight Observation http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight
BodyHeight Observation http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight
3 LaboratoryTestResult Observation http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation
Specimen http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen
4 Procedure Procedure http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure
5 Encounter Encounter http://nictiz.nl/fhir/StructureDefinition/zib-Encounter

7.1.2 Examples of FHIR instances

A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included. BgZ-MSZ 2.0 example: Nictiz-testscripts (BgZ-MSZ 2.0)

8 Release notes (Not part of the template)

Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease. Moreover, release notes for technical implementation are already published in the | Nictiz Simplifier packages and | GitHub pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.

Versie Datum Release notes
Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=qa:Template_TO&oldid=273112"