Developer Guide MO VZVZ

Introduction

Purpose

The purpose of this document is to support the implementation of the Healthcare Application Medicatieoverdracht on the AORTA-LSP infrastructure.

Scope

This document gives a technical overview of the Healthcare Application with references to other documents with further information. It is intended as a landing page that refers to other locations with further information.

This document contains

• the system architecture to indicate how this Healthcare Application relates to other products

• information on the available APIs

• relevant policies and governance that must be adhered to to be able to use this Healthcare Application

• information regarding the configuration of the Healthcare Application, such as connection details for the test and acceptance environments

• an overview of common and known issues

• contact information

Intended audience

This document is intended for developers, product owners and architects of XIS-system development and integration.

Glossary

System Definitions

Building Block Definitions

Feature Definitions

Data Definitions

Actoren Definities

Product Overview

Requirements (Programma van eisen)

The list of requirements for the healthcare application addressed in this Developer Guide can be found here:

See Programma van Eisen

Use cases (functional use cases)

The use cases were refined in cooperation with Nictiz.
For the Healthcare Application.Medicatieoverdracht the following use cases are relevant as well as the usecases in the Nictiz Functional Design.

See Medicatieprocessen

See

Related documents

See Documentatieoverzicht.

Business Architecture

Context

Vision

The Medication Transfer program works on good, complete electronic transfer of medication data. For an up-to-date and complete medication overview for every healthcare provider and every patient. A basic set of medication data has been agreed in the Guideline for Transfer of Medication Data in the Chain. These basic data must be available to every healthcare provider who prescribes, provides or administers. Three information standards enable the registration and exchange of this basic set. These are the information standards Medication Process, Lab values ​​for medication and CiO (Contraindications and hypersensitivities). The healthcare-wide implementation of the guideline and the associated information standards takes place within the Medication Transfer program. New agreements and procedures make network and chain care possible; the information standards included in software packages make digital data exchange possible.

Objectives

The Medication process program aims first to take away existing obstacles in the medication process, while taking into account current legislation and the possibility of obtaining tangible results in the foreseeable future.

Architecture:

The Healthcare Application Medicatieoverdracht consists of various parts:

• business layer architecture by Nictiz

  • Information standards

    • functional requirements

    • information models

• application layer architecture by VZVZ

  • application requirements

  • information models for data exchange on AORTA-LSP infrastructure

  • infrastructure integration specifications with centralized application services

This application layer architecture is related to the higher business layer architecture as formulated in Bedrijfsarchitectuur.

Terminology

Context diagram

See Bedrijfsarchitectuur

This architecture is performed within a larger framework. See Nictiz page on Interoperabiliteit. This application mainly addresses Application and IT-infrastructure.

Business Processes

Business Processes MP9

The main business processes withn MP9 are typically triggered by patient encounters and/or receival of medication data.

The identified processes are:

• Prescribe

  • Medication verification by prescriber

• Dispense

  • Medication verification by pharmacist

• Administer

  • Administration list

  • Administration Registration

• Use

  • Medication Use Registration

• PGO (persoonlijke gezondheidsomgeving personal digital health environment)

  • MedMij gegevensdiensten

    • Verzamelen Medicatiegegevens 9.versie 3.0.0

At the start or during a business process relevant data may be received are retrieved.

At the middle of a business process, an external Healthprofessional may be contacted with proposals.

At the end of such a business process, data is exchanged. Data can be sent or be made available.

Relevant Business Processes per Information System category

The prescriber and the pharmacist as well as other administrators and patients (optional) all make use of an information system, respectively,

• an electronic prescribing system (‘elektronisch voorschrijfsysteem’ - EVS),

• an electronic client file (‘elektronisch cliëntendossier’ - ECD),

• a pharmacist information system (‘apothekersinformatiesysteem’ - AIS),

• a hospital pharmacist information system (‘ziekenhuisapotheekinformatiesysteem’ - ZAIS),

• an administration registration system (‘toedieningsregistratiesysteem’ - TRS),

• a thrombosis service information system (‘trombosedienstinformatiesysteem’ - TrIS)

• and a personal health environment (‘persoonlijke gezondheidsomgeving’ - PGO).

These information systems each have different system roles which enable the exchange of data between these information systems as part of the administration process. The information systems may have a function in compiling an administration list, and in the registration, the exchange and the delivering of an MTD.

Prescriber (EVS user)

Electronic prescribing system (‘elektronisch voorschrijfsysteem’ - EVS)

a thrombosis service information system (‘trombosedienstinformatiesysteem’ - TrIS)

The role of prescriber may be performed by anyone with a prescribing authorisation.

Dispenser (AIS user)

a pharmacist information system (‘apothekersinformatiesysteem’ - AIS)

a hospital pharmacist information system (‘ziekenhuisapotheekinformatiesysteem’ - ZAIS)

Administrator (eTRS user)

an administration registration system (‘toedieningsregistratiesysteem’ - TRS)

Business Process Medication data (PULL)

Context

Functioneel Ontwerp Medicatieproces 9 versie 3.0.0-rc.2 - informatiestandaarden

Trigger

• Notification of new medication data availability

• Patient encounter

• ‘Verzamelen Medicatiegegevens’ via PGO

Steps

• consulting information system pulls the Medication data

• LSP-AORTA

  • acts as an end-point for request from HealthProfessionals and/or Patients

  • allows for HL7v3/CDA and/or FHIR based requests

  • handles the generic query request

  • splits the generic query into specific queries towards the source information systems

  • transforms request where needed for compatibility

  • routes requests towards the relevant source information systems

• consulted information system makes medication data available

• LSP-AORTA

  • transforms response where needed for compatibility

  • aggregates responses into a single response bundle

  • responds to the consulting information system

Postcondition

• Consulted medication data and/or errors is available in the consulting information system

Business Process Medication data (PUSH)

Context

Functioneel Ontwerp Medicatieproces 9 versie 3.0.0-rc.2 - informatiestandaarden

Trigger

• New data, requests, proposals and/or replies have been created and are being made available

• MP9 Process step: ‘Send and/or make available’

Steps

• source information system sends the data, request, proposal or reply

• LSP-AORTA

  • acts as an end-point for send-request from HealthProfessionals and/or Patients

  • allows for HL7v3/CDA and/or FHIR based requests

  • handles the send request

  • transforms send request where needed for compatibility

  • routes the send request towards the relevant receiving information system

• receiving information system handles the receival with acknowledgment

• LSP-AORTA

  • transforms response where needed for compatibility

  • responds to the sending information system

Postcondition

• Send medication data and/or errors is received in the receiving information system

Business Integration between information systems and Patient-based exchange

The MedMij Afsprakenstelsel provides integration between person (Care-User) and the Care-Provider.

See

• Coördinatie, regie en uitwisseling | MedMij Afsprakenstelsels

• Verantwoordelijkheden, Zorg | MedMij Afsprakenstelsels

• Zorg | MedMij Afsprakenstelsels

In the context of MP9 this is done via;

The relevant exchange is done via Gegevensdienst #68 Verzamelen Medicatiegegevens 9.versie 3.0.0 which specializes Verzamelen.

See Actuele gegevensdiensten | MedMij Catalogus en Gegevensdiensten

Business Transaction specific Dataset constraints

Per transaction in the data model in ART DECOR, in the Condition column, refinements are found on attributes. The implementation needs to adhere to these.
These refinements are often the same for all transactions, but sometimes they differ per transaction.
For example, when sending a prescription, there are some fields that are not needed in the prescription and therefore we do not expect them in the prescription. However, when you request and provide medication data, those fields would be included. There are small discrepancies between what is transmitted in one transaction and another.

The advice is to build the building blocks in such a way that you can hide or include attributes in that building block depending on the interaction.
This is also future-proof if you need to move to a newer version of FHIR or other transport protocols.

As implementor, the differences will become apparent, when you Compare transactions side by side.
On big difference is between prescription and medication agreement.

• The phone number is mandatory when sending a prescription, but it must not be included when making a medication agreement available (important - we also qualify on this).

• The VV relationship to MA (1-) on (0-) depends on the migration.

The information per transaction can be found in the ZorgView column under:

Business Data

See Raadpleging en Abonnement - Contexten

See Bedrijfsarchitectuur

Application Architecture

FO Transactions as Systemroles and Profiles

The FO transactions are implemented as application system roles, which in turn are based on the platform profiles defined within the AORTA‑LSP AoF infrastructure.

The requirements for each application‑specific system role are described in the corresponding PvEs.

Each application‑specific system role is derived from, or composed of, one or more underlying AoF infrastructure GBx systemrole profiles.

For example:
The MP‑MGR transaction is implemented using the ‘MP Opvragend Systeem’ application system role. This role is composed of the ‘ZA Opvragend Systeem’ GBx systemrole profile, which itself is based on the ‘Client Systeem’ profile.

MedMij Systemroles and VZVZ components

For the legacy MP6.12 and MP-9.0.7 Information Standards, the MedMij Afsprakenstelsel supports the following Gegevensdiensten:

• Gegevensdienst #31 – Verzamelen Medicatiegegevens 9.0

• Gegevensdienst #35 – Verzamelen Medicatiegegevens 9.A

For the MP9v3 Information Standard, the MedMij Afsprakenstelsel supports the following Gegevensdienst:

• Gegevensdienst #68 – Verzamelen Medicatiegegevens 9 versie 3.0.0

Capabilities of LSP+ towards service (Gegevensdienst) #68:

• Access to legacy MP6.12 data sources, including AIS systems implementing the QURX Verstrekkingenlijst transaction. Data is exposed as MP9v3 Therapeutic Agreements (TAs) and Medication Dispense Events (MVEs). The required HL7v3-to-FHIR and MP6.12-to-MP9v3 transformations are performed by the BTD.

• Access to native MP9v3 FHIR data sources.

• Access to native MP9v3 HL7v3 data sources. The required HL7v3-to-FHIR transformations are performed by the BTD before the data is exposed through the service.

• LSP+ as as DVZA and LSP as broker implement the systemrole MP-MGB-3.0.0-FHIR for the service (Gegevensdienst) #68.

Limitations

Transactions

Context

Transactions as required within the context of AORTA-LSP.

Purpose

This section covers all available transactions as defined by Nictiz.

It details the mapping of those transactions to exchang format specific application layer transactions.

Those application layer transactions are exposed as AORTA-LSP using HL7v3 and/or FHIR interfaces.

This section also refines the application layer requirements by this Healthcare Application.

Scope

Which transactions should I support?

End goals

However, it is important to realize that the final scope of MP9 is significantly broader.
The compilation file is therefore not a definitive representation of what ultimately needs to be implemented. Additional testing will be conducted for a number of functionalities. Moreover, the standard is still under development and subject to changes that will need to be incorporated.

Please take this into account during further implementation.

The Healthcare Application Medicatieoverdracht is very large and covers all use cases for every type of EHR system that participates. The list below indicates which use cases should be supported by each type of system. This allows vendors to drill down to only support the relevant use cases.

The roles and use-cases are summarized by Nictiz and the Program in the Compilation File.

See Compilation File.

Medicatieprocessen contains additional business analysis by VZVZ.

Transactions per system role

Legenda of details per transaction

• Indicator of scope:

  • DR - digitaal receptenverkeer

  • MO - medicatieoverdracht

  • TL - toedienlijst

  • MM - MedMij

• Indicator of actor:

  • Voorschrijver

  • Verstrekker

  • Toediener

  • PGO/Patient

• Eigen Only: Whether only own of foreign (copy) building-blocks are allowed?

• Systeemrol: Nictiz FO Systeemrol

• AoF GBx-Systeemrol: Required role to communicate via the AoF-route.

• FHIR_Systeemrol: Required role to communicate via FHIR.

• VZVZ AORTA v3 Applicatie systeemrol: required role to be implemented to communicate via HL7v3/CDA.

• VZVZ AORTA v3 Webservice: Webservice to communicatie via HL7v3/CDA.

• SOAP Message: Message to communicatie via HL7v3/CDA.

• AoF_Interactie: Message to communicatie via AoF (mainly FHIR).

• AoF_Interface: Interface to communicatie via AoF.

• AoF_Feature: Required feature capability to communicatie via AoF.

• ContextCode: Code which makes the transaction more specific for its context.

This explanation supports the implementation of the requirements for each necessary role.

Voorschrijver

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Verstrekker

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Toediener

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Patient

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Individual use cases

MP-MGR MP-MGB proxy-facade

AORTA acts as proxy-facade towards the source systems. The calls from a MP-MGR are distributed towards MP-MGB servers and the responses are aggregated as bundled response.

We use a generic query (in FHIR, in the form of a $get-aorta-data operation) for requesting systems, which is translated by AORTA into FHIR searches (excluding BSN) towards source systems.

MP-MGR MP-MGB FHIR includes

AORTA ensures that all relevant data is requested in a minimum number of requests. This avoids unnecessary round-trips, and ensures sufficient data retrieval to allow for the BTD to transform data between exchange formats.

These includes result in explicitely broadend FHIR searches with _include and _include:iterate parameters towards MP-MGB.

Patient identifier not part of argument but part of context

Patient identifier is not intended to be mentioned in the query parameters. This would impose a security risk.

For security reasons, we do not include the BSN (citizen service number) in the URL of FHIR searches. It is part of the token that is sent along (which is therefore not only an authorization tool but also a data carrier).

The patient indentifier needs to be communicated via the access-token.

This design-pattern is used for incoming as well as outgoing traffic on AORTA-LSP.

AORTA-LSP does NOT support patient identification with the use of search parameters.

As mentioned in the FHIR Implementation Guide Medication Process 9 version 3.0.0 - informatiestandaarden.

Within AORTA, each transaction is performed in the context of a specific patient, whose context might has been established using the authentication mechanisms. Patient is part of the token exchange.

The BSN of the patient in question is included in the access_token

MP-VOS + LAB-LRS

Send a request for medication dispensing or for processing a change in a medication agreement.

VZVZ implements lab Observations as an open-world extension on top of profile mp-MedicationPrescription-Bundle.

Security

We have a security requirement, which makes it necessary to obtain an access token that is sent along to the source systems.
This does not change the FHIR search itself, but it does affect the HTTP call.

HTTP-Headers

In addition, there are several HTTP headers we use, such as:

• Content-Type (format of the FHIR content)

• AORTA-ID (for tracing/logging of interactions/chains)

• AORTA-Version (infrastructure version)

Examples include headers like request-id, initial-request-id, etc..

Provenance Resources in FHIR response bundles

Also see Bedrijfsarchitectuur for the functional description of Provenance.

During pull and push exchange, the AORTA-LSP as exchange system adds FHIR Provenance Resources into the bundles to indicate the source systems.

The application logic is described here:

Sequence diagrams

For Business Layer scenarios,
see DECOR informatie voor project: Medicatieproces (mp-).

For Application Layer scenarios,
see DECOR informatie voor project: Medicatieproces op LSP (mp-vzvz-)

For AORTA-on-FHIR platform integrations, see https://aorta-on-fhir.public.vzvz.nl/aorta-on-fhir-specificaties/latest/sequence-diagrammen .

For additional infrastructural usecases, see Use‑cases

Query Design

Supported message formats and interfaces

The generic query supports the Nictiz MP-MGR transaction through two message formats: HL7v3/CDA and FHIR.

Clients can access the generic query via AORTA-LSP using the interfaces:

• The AORTA-LSP HL7v3/CDA transaction – Generieke query naar LSP

• The AORTA-LSP AoF FHIR call – $get-aorta-data

For the MP standard, AORTA-LSP currently provides only the generic query to GBx resource clients. Building block–specific queries are not directly available to GBx resource clients; instead, these specific queries are used internally by AORTA-LSP and LSP+ in their function as information brokers.

Supported system roles

For FHIR-based GBx resource clients, the available functionality is intentionally limited to the generic query. This restriction is enforced through TKID management. FHIR-based GBx resource clients are assigned only the following system roles:

• Operation Initiërend Systeem (OIS) system role: $get-aorta-data.OIS.R4.1

• Search result Ontvangend Systeem (SOS) system roles, one for each supported building block

Access to building block–specific queries is disabled by not assigning the SIS Search Initiërend Systeem roles.

These SIS roles correspond to the building blocks that can be retrieved through specific queries.

Supported building blocks

These are the underlying building block which are retrieved via specific queries;

The contextcode which is used as argument in the generic query determines which building blocks are in scope.

The verstrekkingsverzoek is only queryable by the patient.

Supported filtering

The generic query supports filtering. Parameters can be used as filter arguments for the generic query. However, the naming of these parameters is not yet harmonized across the generic query, the building block–specific queries, the HL7v3 and FHIR message formats, and the Nictiz information standard.

Execution of Generic Queries via AORTA-LSP

The generic query is executed as a series of building block–specific queries directed at the GBx resource servers.
The resulting data is subsequently consolidated into a single, unified response.

Within the MP9 context, the generic query is composed of discrete queries for each MP9 building block. The AORTA-LSP is responsible for performing message format transformations between GBx resource clients and servers. Furthermore, it ensures compliance with the applicable authorization rules governing the end user of the query, whether this is a care professional or a patient.

Nictiz transaction

This is the conceptual Nictiz transaction that supports querying. It is used to query the building blocks for a specific patient.

AORTA-LSP HL7v3/CDA transaction

This is the AORTA-LSP HL7v3/CDA transaction that realizes the conceptual Nictiz transaction.

Scenario

Dataset and Template

VZVZ maps this to this dataset and corresponding template.

Data elements

This results in the following data structure for a parameter of the generic query.

hl7:GQZG_IN000001NL02
>hl7:ControlActProcess
>>hl7:queryByParameter
>>>hl7:parameter
>>>>hl7:value
>>>>hl7:semanticsText

AORTA-LSP AoF FHIR call

This is the AORTA-LSP AoF FHIR call that realizes the conceptual Nictiz transaction.

See Interfaces Resource Broker ZA-in

Call Syntax

GET [base]$get-aorta-data
?[context]
{&[destination]}
{&[effective-time]}
{&[therapy-identifier]}
{&[classifier]}
{&[instance-identifier]}

MP9v3 generic query parameters

Below is the mapping of parameter names between the HL7v3 and FHIR message formats, and the Nictiz information standard.

Column AoF corresponds to the parameters for the AORTA-LSP AoF FHIR call.

Column HL7v3 corresponds to the parameters in the AORTA HL7v3/CDA Dataset and Template.

Parameter naming in different contexts

• The Functional Design (FD) defines the Nictiz parameters.

• The Generic Query via the AoF route uses the FHIR operation $get-aorta-data, which relies on predefined (abstract) parameters.

• The Specific Query building blocks via the AoF route use FHIR search per resource, applying the corresponding FHIR search parameters.

• The Generic Query via the ZIM route uses HL7v3 parameters.
  

Idempotency

Summary

• In MP9v3, the MP‑..O transactions do not support duplicate detection at the application level because HL7v3 messages do not contain an Act Id.

• MP9v3 building‑block instances do have a unique GUID, but these are treated as patient documents and must always be processed, even if received multiple times.

• Duplicate detection at the application level is therefore not required or expected.

Platform requirements

Platform‑level requirements for reliable transport can be found under Betrouwbaar transport.

Application requirements

• Duplicate detection at the transport level: Required.

• Duplicate detection at the application level: Not expected.

Additional clarifications:

• Because MP9v3 HL7v3 messages lack an Act Id, application‑level duplicate detection is not technically possible on that basis.

• Although building blocks contain a GUID, a repeated instance must still be processed upon each receipt.

• A prescription may only be sent once (functionally and legally).

  • Therefore, an MP‑VOS receiver may implement optional duplicate detection if the same VV instance is received twice.

  • This is not defined as a formal requirement.

Avoid duplicate on notifications

APIs

Supported APIs

The Medication Process is supported by a variety of APIs and Medication Information Standards.

AORTA-LSP platform

The AORTA-LSP platform is built around two primary message-processing routes: the legacy ZIM route and its successor, the AoF route. The AoF route replaces the legacy architecture with a more granular, component-based infrastructure.

As a result, AORTA-LSP message exchange currently operates across a combination of infrastructure routes, incorporating both legacy system components and the newer AoF-based architecture.

The AORTA-LSP endpoints and their corresponding APIs support multiple message exchange formats.

The Healthcare Application Medicatieoverdracht operates in a hybrid environment in which messages may be exchanged using either HL7 v3/CDA or HL7 FHIR formats. To facilitate interoperability between these formats and the underlying Medication Information Standards, the AORTA-LSP infrastructure employs the Message Transformation Service (BTD, Berichten Transformatie Dienst).

To enable reliable transformation between HL7 FHIR and HL7 v3/CDA without loss of information, the following implementation constraints apply to FHIR-based message exchanges:

1. Always ensure that each resource instance contains a valid business identifier.

2. Do not use absolute FHIR references, as these cannot be mapped to HL7 v3 references during transformation.

3. Always include all referenced resources within the Bundle. The LSP gateway cannot retrieve additional resources, and Bundles containing unresolved references cannot be transformed successfully.

4. Ensure that all resources required for the target information standard are present and complete, allowing the transformation process to generate a fully compliant message.

MedMij DVZA

In addition to the AORTA-LSP platform, patients can access their own medical data through the MedMij Afsprakenstelsel. Within this framework, VZVZ provides a DVZA (Dienstverlener Zorgaanbieder) service called LSP+, which enables the secure exchange of medical data between healthcare providers and Personal Health Record (PGO) systems.

The LSP+ DVZA is connected to the AORTA-LSP platform and acts as a gateway between the MedMij ecosystem and healthcare information systems (XIS). To make data available through MedMij gegevensdiensten, XIS systems functioning as data sources can implement either the MP6.12 APIs or the more recent MP9v3 APIs.

For MP9v3, the MedMij Afsprakenstelsel offers Gegevensdienst #68: “Verzamelen Medicatiegegevens 9, versie 3.0.0.” To support this service, LSP+ functions as an intermediary broker, providing access to medication data originating from the following sources:

• MP9v3 FHIR

• MP9v3 HL7 v3

• MP6.12 HL7 v3 (Verstrekkingenlijst)

This brokering approach enables the service to expose and transform medication information originating from multiple source systems and message formats. As a result, both legacy and next-generation Medication Information Standards can be supported as source data providers, ensuring interoperability throughout the ongoing transition from HL7 v3-based implementations to FHIR-based solutions.

API support HL7v3/CDA exchange format

See DECOR informatie voor project: Medicatieproces op LSP (mp-vzvz-)

Medicatieproces op het LSP versie 1.6 en is gebaseerd op MP9 3.0.0-rc.1

This diagram depicts all the WSDL interfaces and WSDL contracts as application logic that enable the MP business logic.

API support for FHIR R4

See FHIR Implementation Guide Medication Process 9 version 3.0.0-rc.1 - informatiestandaarden for FHIR integration.

This diagram depicts all the FHIR interactions as application logic that enable the MP business logic.

Use of FHIR packages

V3 messages and packages

Backwards compatibility for MP 6.12 transactions on AORTA 8.4

The 6.12 messages can and will be exchanged via AORTA 8.4. This no longer goes through the AORTA 6 version of the infrastructure.

The PvEs for the AORTA 6 version of the infrastructure are no longer used and have been replaced by the PvEs based on the 8.4 version of the infrastructure.

The old version of MO is also 6.x. That is why these messages are called 6.12 messages. The 6.12 messages can and will be exchanged via AORTA 8.4.

Two parallel paths

Within AORTA-LSP, there are two parallel paths for processing messages: a legacy path and a replacement path.

The legacy path is also known as the ZIM route.

The replacement path is also known as the AoF route.

With the introduction of AoF, a new architecture has started with a new replacement path that will eventually replace the legacy path.

FHIR profiles and packages

The FHIR profiles used in this Healthcare Application can be found on Simplifier.

Examples

See: FHIR profiles and packages

API specification

Naming conventions

The various calls on the various API’s adhere to naming conventions by Nictiz and VZVZ.

These are the naming conventions in Dutch.

Nictiz - functional transactions

• Sturend

• Ontvangend

• Beschikbaarstellend

• Raadplegend

• Voorstel

• AntwoordVoorstel

VZVZ, AoF systemroles

• ZA Verzendend Systeem

• ZA Ontvangend Systeem

• ZA = ZorgAanbieder

VZVZ, AORTA v3

• Webservice

  • Versturen

  • Opvragen

• Transactierollen

  • xxZ - verzendendsysteem

  • xxD - ontvangendsysteem

  • Vxx - voorstel…

  • Axx - antwoord…

  • xxO - … opvragend systeem

  • xxV - …bronsysteem | …opleverend systeem

VZVZ, AoF zorgtoepassingsrollen

• SIS Search Initiërend Systeem

• SVS Search Verwerkend Systeem

• SOS Search result Ontvangend Systeem

• TIS Transaction Initiërend Systeem

• TVS Transaction Verwerkend Systeem

• CIS Create Initiërend Systeem

• CVS Create Verwerkend Systeem

• RIS Read Initiërend Systeem

• RVS Read Verwerkend Systeem

• UIS Update Initiërend Systeem

• UIS Update Verwerkend Systeem

• DIS Delete Initiërend Systeem

• DVS Delete Verwerkend Systeem

• OIS Operation Initiërend Systeem

• OVS Operation Verwerkend Systeem

Security

Identification and Authorization Management

See Programma van Eisen.

Encryption

See Programma van Eisen.

Authentication

See Autorisatierichtlijn Medicatieveiligheid | AORTA-LSP.

See Programma van Eisen.

See Bedrijfsarchitectuur; Actors