qa:Template TO

For an overview of all current documentation see <IS> main page

An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the default structure and contents of a TO. Change the document title to: Technical Design <IS name> <IS version> The template uses the following annotation: Goal: What the goal of the section is and what information it should include. Default text: Sentences to include in the TO. 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>.

1 Introduction

Goal: The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers. Boundaries should define how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links.

Default text: This is the technical design (TO) for the information standard (IS) <IS name>. This TO must be used together with the IS functional design [[<link>| functional design <IS><version>]]. The data exchange format used in this version is: <HL7 CDA | FHIR STU3 | FHIR R4>.

Example: BgZ-MSZ 2.0 FHIR STU3 [expand/collapse]

This is the technical design (TO) for the information standard (IS) BgZ-MSZ. This TO must be used together with the IS functional design, see functional design BgZ-MSZ 2.0.0-beta.2. The data exchange format used in this version is: HL7 FHIR STU3.

1.1 Support

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

1.2 Boundaries

Default text: This information standard may overlap with other standards related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication. For more information, see <link to FO accompanying this TO>.

Dit moet ook in het FO template gezet worden!

1.3 Known issues

Default text: The IS is actively maintained and continuously improved. However, issues may be discovered, which are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

Dit moet ook in het FO template gezet worden!

1.4 Prerequisite knowledge

Default text: The following background information is required for understanding this TO:

• The [[<link>| functional design <IS><version>]] accompanying this TO.
• The data exchange format <your data exchange format here, e.g., FHIR STU3>, which you can find here: [[<link>| <link name>]]
• The data exchange pattern <your pattern here>, which can be found here: [[<link>| <link name>]]

Example: BgZ-MSZ 2.0 [expand/collapse]

This TO assumes that the reader is familiar with the following:

• The functional design BgZ-MSZ 2.0.0-beta.2 accompanying this TO.
• This information standard uses the data exchange formats HL7 FHIR STU3, which you can find here:
  • general FHIR STU3 Implementation Guide, (e.g. how to handle empty reponses etc.).
  • use case overarching principles
  • FHIR packages.
• This information standard uses the data exchange pattern Technical Agreement - Notified Pull (TA-NP), which you can find here: <link>

2 Components

Goal: This chapter should clarify how the data exchange format is used to accommodate the Dutch Clinical Information Models (Dutch abbreviation: zibs) and/or other building blocks used in the IS. The content of this chapter depends on the chosen data exchange format. Currently this template only supports HL7 FHIR. HL7v3 (including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet. The artifacts section should describe the link between zib and FHIR resources. The table should follow the structure of the FO and refer to the FO (bijv. zie FO).

Default text: <the data exchange format used e.g. HL7 FHIR, TA Notified Pull, XDS, XCA, CDA> is used to accommodate the Dutch Clinical Information Models (zibs) used in the IS.

2.1 HL7 FHIR <version>

Default text:

<IS> uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages: [<link to package 1>] [<link to package 2>] [<link to package 3>] Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

Example: eOverdracht 4.0.5 STU3 [expand/collapse]

eOverdracht uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages: nictiz.fhir.nl.stu3.eoverdracht, version nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible nictiz.fhir.nl.stu3.zib2020-preadopt, version Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

2.1.1 Artifacts

Default text: The artifacts of the information standard are presented in the following table:

zib	FHIR resource	FHIR profile
<zib 1>	<FHIR resource 1>	{{Simplifier|<canonical 1>|(package)(|pkgVersion=<package version 1>)(|title=<Simplifier page title 1>)}}
<zib 2>	<FHIR resource 2>	{{Simplifier|<canonical 2>|(package)(|pkgVersion=<package version 2>)(|title=<Simplifier page title 2>)}}

Example: BgZ-MSZ 2.0 FHIR STU3 [expand/collapse]

zib	FHIR resource	FHIR profile
Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient
MaritalStatus		Patient.maritalStatus
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
LaboratoryTestResult	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation
	Specimen	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen
Procedure	Procedure	http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure
Encounter	Encounter	http://nictiz.nl/fhir/StructureDefinition/zib-Encounter

2.1.2 Examples of FHIR instances

Default text: You can find examples of FHIR-instances (filled-in FHIR profiles) in the Nictiz GitHub repository: [[<link to generated FHIR instances in the IS's Nictiz-testscripts GitHub folder> | <IS> Testscripts repository]].

Example: You can find examples of FHIR-instances (filled-in FHIR profiles) in the Nictiz GitHub repository: BgZ-MSZ 2.0 Testscripts repository

3 Transactions

Goal: In this chapter, the transaction groups of the functional design are supplemented with invocations, such as FHIR queries and search parameters. The stakeholders of a transaction are called Actors. They can be persons or systems in different roles, such as the sending or receiving role. To give an overview of the actors relevant in this IS, a table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

3.1 <Use case 1>

3.1.1 Involved actors

Default text:

Abbreviations: SRC = system role code, FCSN = FHIR CapabilityStatement Name.

Transaction group	Transaction	Actor	System role code	FHIR CapabilityStatement
<Transaction group name>	<Transaction 1>	<Actor 1>	<SRC 1>	<FCSN link 1>
	<Transaction 2>	<Actor 2>	<SRC 2>	<FCSN link 2>

Example: MedMij LaboratoryResults 2.0.42 FHIR STU3 [expand/collapse]:

Abbreviations: MP-MGS = Medicatieproces - medicatiegegevens sturend systeem, MP-MGO = Medicatieproces - medicatiegegevens ontvangend systeem.

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Medication data (PUSH)	Sending medication data	Client	MP-MGS	Send/receive medication data
	Receiving medication data	Server	MP-MGO

3.1.2 Search parameters

Goal: Search parameters are used in the FHIR query URL to filter the results. Clients are obliged to use FHIR search parameters, but are not limited to these parameters. Provide a table listing all search parameters that SHALL be supported for processing by servers and SHALL be supported by clients. Include the corresponding IS FHIR search parameter, a description of this parameter, relevant FHIR resources, and examples of its use. If your IS uses custom search parameters, they may be defined for transactions.

Default text:

Use this caption for extra notes, abbreviations, etc.

FHIR Search Parameter	Description	FHIR Resource	Example
<Functional building block 1>
<FHIR Search Parameter 1>	<Description of FHIR Search Parameter 1>	<FHIR Resource 1>	<HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>
<Functional building block 2>
<FHIR Search Parameter 2>	<Description of FHIR Search Parameter 2>	<FHIR Resource 2>	<HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>
<Functional building block 3>
<FHIR Search Parameter 3>	<Description of FHIR Search Parameter 3>	<FHIR Resource 3>	<HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>

WARNING: The following examples are outdated.

Example: BgZ-MSZ 2.0 STU3 [expand/collapse]

3.1.2.1 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.

Example: MP9 R4 3.0.0-rc.1 [expand/collapse]

MP9 search parameter	Description	FHIR search parameter	FHIR resource	Example
PatientIdentificationNumber	Search on patient.	patient.identifier subject:Patient.identifier	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves all MedicationRequest resources of a patient with a fake BSN of 11122233. GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333
Identification	Search on identifier.	identifier	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves a MedicationRequest resource with a specific identifier. GET [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448
Identification	Search on the pharmaceutical treatment identifier. Note: retrieval of all medication resources belonging to one pharmaceutical treatment requires to search on all medication resource types.	pharmaceutical-treatment-identifier	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier. GET [base]/MedicationRequest?pharmaceutical-treatment-identifier=http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment|1247848
Type	Search on type of medication building block.	category	MedicationRequest	Retrieves all MedicationRequest resources that represent the building block MedicationAgreement. GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005 Retrieves all MedicationRequest resources that represent the building block DispenseRequest. GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108 Retrieves all MedicationRequest resources that represent the building block VariableDosingRegimen. GET [base]/MedicationRequest?category=http://snomed.info/sct|395067002
			MedicationDispense	Retrieves all MedicationDispense resources that represent the building block MedicationDispense. GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005 Retrieves all MedicationDispense resources that represent the building block AdministrationAgreement. GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009
			MedicationStatement	Retrieves all MedicationStatement resources that represent the building block MedicationUse2. GET [base]/MedicationStatement?category=http://snomed.info/sct|422979000
			MedicationAdministration	Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2. GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005
MedicationCode	Search on medication code.	medication.code	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and have Carbasalaatcalcium Sandoz 600 30 as medication. GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554
PeriodOfUse	Search on the MedicationAgreement, VariableDosingRegimen, AdministrationAgreement and MedicationUse2 building blocks that are related to medication that was used, is used or will be used during the indicated period. Whenever a search is done on the MedicationAgreement, VariableDosingRegimen or AdministrationAgreement building blocks it is required to also include the latest stopped building blocks of that kind within each pharmaceutical treatment, even if these have a period of use outside the PeriodOfUse that is being searched on.	period-of-use	MedicationRequest, MedicationDispense, MedicationStatement	Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and were in effect from 01-01-2010. GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&period-of-use=ge2010-01-01
DispensePeriod	Returns all medication dispenses within the specified time period.	whenhandedover	MedicationDispense	Retrieves all MedicationDispense resources that represent the building block MedicationDispense and were handed over within a 2 year period. GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005&whenhandedover=ge2010-01-01&whenhandedover=le2011-12-31
AdministrationPeriod	Returns all medication administrations within the specified time period.	effective-time	MedicationAdministration	Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2 and where administration happened on a specific day. GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005&effective-time=eq2022-01-01
-	The client may request that the server returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources. Supporting the include of the Patient and Medication resources referenced by building blocks is required. Others (Organization, Location, PractitionerRole, Practitioner, RelatedPerson, Observation) are optional when non-FHIR systems are not involved. However: all resources referenced per literal reference SHALL be resolvable per the Nictiz IG. In the case of retrieving and serving data with non-FHIR systems and where transforming data is involved, it is required to include additional resources to ensure that the bundles get transformed to valid HL7v3 (CDA) messages. This requires additional includes in the request and the usage of the modifier iterate which is explained in ‘Additional search parameters and includes’.	_include=[type]:patient _include=[type]:medication	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves all MedicationRequest resources that have Carbasalaatcalcium Sandoz 600 30 as medication and includes the Medication resource in the search results. GET [base]/MedicationRequest?medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554&_include=MedicationRequest:medication

3.2 <Use case 2>

3.2.1 Involved actors

Default text:

Transaction group	Transaction	Actor	System role code	FHIR CapabilityStatement
<Transaction group name>	<Transaction 1>	<Actor 1>	<System role code 1>	<FHIR CapabilityStatement 1>
	<Transaction 2>	<Actor 2>	<System role code 2>	<FHIR CapabilityStatement 2>

3.2.2 Search parameters

Default text:

FHIR Search Parameter	Description	FHIR Resource	Example
<Functional building block 1>
<FHIR Search Parameter 1>	<Description of FHIR Search Parameter 1>	<FHIR Resource 1>	<HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>
<Functional building block 2>
<FHIR Search Parameter 2>	<Description of FHIR Search Parameter 2>	<FHIR Resource 2>	<HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>
<Functional building block 3>
<FHIR Search Parameter 3>	<Description of FHIR Search Parameter 3>	<FHIR Resource 3>	<HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters>

4 Optional elements (not part of template)

Goal: The contents of these chapters are dependent on the needs of your IS; fill them in at your own discretion.

4.1 Workflow

If absolutely necessary (e.g., your IS uses a workflow with a unique technical implementation), an additional chapter called "Workflow" may be added after the Introduction.

Example: eOverdracht Workflow chapter

4.2 Relationships

You may want to illustrate the relationships between the various data elements in your IS using a diagram. If so, add an additional chapter called "Relationships" after the Introduction (or Workflow, if used).

Example: Geboortezorg Relationships chapter

4.3 Footnotes

If absolutely necessary, an additional chapter called "Footnotes" may be added as the final chapter. In there, a footnote may be added using <ref> and ‎<references /> tags.

Example: Medication Process Footnotes chapter

Footnotes from examples in this template: ‎

5 Template wiki code (not part of template)

Goal: This chapter is here to have an empty template (without annotations and examples but including default text) to copy and reuse.

<!-- LINK BACK to the information standard's main page (landingspagina) -->
<big>For an overview of all current documentation [[Landingspagina_IS| see <IS> main page]]</big>
<!-- END LINK BACK -->

<!-- TABLE OF CONTENTS showing only 1st en 2nd level headers -->
__NUMBEREDHEADINGS__
__TOC__
<!-- END TABLE OF CONTENTS -->

<!-- STOP INDEXING this page: makes this page invisible to search engines -->
__NOINDEX__
<!-- END DON'T INDEX -->

<!-- BACK TO TOP BUTTON -->
<span id="BackToTop"></span>
<div class="noprint" style="position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[Bestand:BackToTopNictizOrange.svg|64px|64px|link=#BackToTop|Back to Top]]
</div>
<!-- END BACK TO TOP BUTTON -->

== Introduction ==
This is the technical design (TO) for the information standard (IS) <IS name>. This TO must be used together with the IS functional design [[<link>| functional design <IS><version>]]. The data exchange format used in this version is: <HL7 CDA | FHIR STU3 | FHIR R4>.

=== Support ===
For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Boundaries ===
This information standard may overlap with other standards related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication. For more information, see <link to FO accompanying this TO>.

=== Known issues ===
The IS is actively maintained and continuously improved. However, issues may be discovered, which are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Prerequisite knowledge ===
The following background information is required for understanding this TO:
* The [[<link>| functional design <IS><version>]] accompanying this TO.
* The data exchange format <your data exchange format here, e.g., FHIR STU3>, which you can find here: [[<link>| <link name>]]
* The data exchange pattern <your pattern here>, which can be found here: [[<link>| <link name>]]


== Components ==
<The data exchange format used, e.g., HL7 FHIR, TA Notified Pull, XDS, XCA, CDA> is used to accommodate the zibs used in the IS. 

=== HL7 FHIR <version> ===

==== Artifacts ====
The artifacts of the information standard are presented in the following table:

{| style="text-align: left;" cellpadding=5px;

|- style="color: white; background-color: #e7844b;"
! zib !! Target !! Profile

|-  style="background-color: #fcf0e9;"
| <zib 1> || <FHIR resource 1> || {{Simplifier|<canonical 1>|(package)(|pkgVersion=<package version 1>)(|title=<Simplifier page title 1>)}}

|-  style="background-color: #fcf0e9;"
| <zib 2> || <FHIR resource 2> || {{Simplifier|<canonical 2>|(package)(|pkgVersion=<package version 2>)(|title=<Simplifier page title 2>)}}
|}


==== Examples of FHIR instances ====
You can find examples of FHIR instances (filled-in FHIR profiles) in the Nictiz GitHub repository: [[<link to generated FHIR instances in the IS'sdefault Nictiz-testscripts GitHub folder> | <IS> Testscripts repository]]. 


== Transactions ==
=== <Use case 1> ===
==== Involved actors ====
{| style="text-align: left;" cellpadding=5px;

|- style="color: white; background-color: #e7844b;"
! Transaction group || Transaction || Actor || System role code || FHIR CapabilityStatement

|- style="background-color: #fcf0e9;"
| rowspan="2" | <Transaction group name>
| <Transaction 1> || <Actor 1> || <SRC 1> || <FCSN link 1>

|- style="background-color: #fcf0e9;"
| <Transaction 2> || <Actor 2> || <SRC 2> || <FCSN link 2>

|+ style="align: bottom; caption-side: bottom; text-align: left;" | ''Abbreviations: SRC = system role code, FCSN = FHIR CapabilityStatement Name.''
|}


<div style="background-color:aliceblue;padding:5px;">
'''Example:''' MedMij LaboratoryResults 2.0.42 FHIR STU3 [<span style="color:navy" class="mw-customtoggle-involvedActorsExample">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-involvedActorsExample">
{| style="text-align: left;  background-color: white;" cellpadding=5px;

|- style="color: white; background-color: #e7844b;"
! Transaction group !! Transaction !! Actor !! System role !! FHIR CapabilityStatement

|- style="background-color: #fcf0e9;"
| rowspan="2" | [https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.139-2022-06-30T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.375_20220630000000 Medication data (PUSH)] 
| [https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.376-2022-06-30T000000.html Sending medication data]
| Client 
| MP-MGS
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationData.SendReceive|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}|title=Send/receive medication data}}

|- style="background-color: #fcf0e9;"
| Receiving medication data
| Server
| MP-MGO

|+ style="align: bottom; caption-side: bottom; text-align: left;" | ''Abbreviations: MP-MGS = Medicatieproces - medicatiegegevens sturend systeem, MP-MGO = Medicatieproces - medicatiegegevens ontvangend systeem.''
|}</div></div>

==== Search parameters ====
{| style="text-align: left;" cellpadding=5px; 
|- style="color: white; background-color: #e7844b;"
! FHIR Search Parameter !! Description !! FHIR Resource !! Example

|- style="color: white; background-color: #eda778;"
! colspan="4"  | <Functional building block 1>

|- style="background-color: #fcf0e9;"
| <FHIR Search Parameter 1> || <Description of FHIR Search Parameter 1> || <FHIR Resource 1> || <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>

|- style="color: white; background-color: #eda778;"
! colspan="4" | <Functional building block 2>

|- style="background-color: #fcf0e9;"
| <FHIR Search Parameter 2> || <Description of FHIR Search Parameter 2> || <FHIR Resource 2> || <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>

|- style="color: white; background-color: #eda778;"
! colspan="4" | <Functional building block 3>

|- style="background-color: #fcf0e9;"
| <FHIR Search Parameter 3> || <Description of FHIR Search Parameter 3> || <FHIR Resource 3> || <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>

|+ style="align: bottom; caption-side: bottom; text-align: left;" | ''Use this caption for extra notes, abbreviations, etc.''
|}


=== <Use case 2> ===
==== Involved actors ====
{| style="text-align: left;" cellpadding=5px;
|- style="color: white; background-color: #e7844b;"
! Transaction group !! Transaction !! Actor !! System role code !! FHIR CapabilityStatement

|- style="background-color: #fcf0e9;"
| rowspan="2" | <Transaction group name>
| <Transaction 1> || <Actor 1> || <System role code 1> || <FHIR CapabilityStatement 1>

|- style="background-color: #fcf0e9;"
| <Transaction 2> || <Actor 2> || <System role code 2> || <FHIR CapabilityStatement 2>
|}

==== Search parameters ====
{| style="text-align: left;" cellpadding=5px; 
|- style="color: white; background-color: #e7844b;"
! FHIR Search Parameter || Description || FHIR Resource || Example

|- style="color: white; background-color: #eda778;"
! colspan="4"  | <Functional building block 1>

|- style="background-color: #fcf0e9;"
| <FHIR Search Parameter 1> || <Description of FHIR Search Parameter 1> || <FHIR Resource 1> || <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>

|- style="color: white; background-color: #eda778;"
! colspan="4" | <Functional building block 2>

|- style="background-color: #fcf0e9;"
| <FHIR Search Parameter 2> || <Description of FHIR Search Parameter 2> || <FHIR Resource 2> || <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>

|- style="color: white; background-color: #eda778;"
! colspan="4" | <Functional building block 3>

|- style="background-color: #fcf0e9;"
| <FHIR Search Parameter 3> || <Description of FHIR Search Parameter 3> || <FHIR Resource 3> || <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
|}

6 Release notes (not part of template)

Goal: Release notes are not a part of the TO template because this information about the IS 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
1.0.0	16-07-2025	Finished first version