Developer Guide MO VZVZ

Changelog

Version 0.0.1

First draft

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

Disclaimer:

The scope of this developer guide is consistent with the information standard. However, it may differ from the scope outlined in the implementation contract between the MO program and the Information System vendor.

This documentation aims to comprehensively cover all aspects of the information standard and the Healthcare Application as supported by the AORTA-LSP.

Note: In case of discrepancies, the Nictiz scope takes precedence.

Intended audience

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

Glossary

Developer Guide - Glossary

Product Overview

Requirements (Programma van eisen)

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

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 and can be found on the Nictiz website or in the PSA which is developed internally.

• Medicatieprocessen

• Functioneel Ontwerp Medicatieproces 9 versie 3.0.0-beta.4 - informatiestandaarden

• Functional Design Medication Process 9 version 3.0.0-beta.4 English version - informatiestandaarden

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:

AORTA 8 - Subscribe and notify

The terms; subscribe and notify need to be used instead of the legacy terms; signal, event and register.

In the AORTA v3 architecture the legacy terms are still present.

Context diagram

Zie Bedrijfsarchitectuur

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

Business Processes using AORTA-LSP

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

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-beta.4 - informatiestandaarden

Trigger

• Notification of new medication data availability

• Patient encounter

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-beta.4 - 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 Transaction specific Dataset constraints

The dataset needs to adhere to the constraints set by the transaction

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 under: Dataset: mp- DECOR-samenvatting (Data Elements, Codes, OID's en Rules) in the ZorgView column!

Business Data

Zie Raadpleging en Abonnement - Contexten

Zie ook Bedrijfsarchitectuur

Application Architecture

Application Interfaces

HL7v3

FHIR

Application Components

Transactions

Query Parameters

Nictiz

Transactie Raadplegen medicatiegegevens MP9 3.0.0-beta.4

Dataset (voor transactie) 2.16.840.1.113883.2.4.3.11.60.20.77.4.373 - Raadplegen medicatiegegevens

AORTA-LSP AoF

Interfaces Resource Broker ZA-in

Syntax

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

VZVZ AORTA HL7v3/CDA

Transactie Generieke query

Template 2.16.840.1.113883.2.4.3.111.3.3.10.9048 - generiekeGeparameteriseerdeQueryZorggegevens

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

Query parameters

APIs

Security

voor de onderstaande onderdelen een acceptable means of compliance beschrijven.

Verwijs naar de tokens, VGU, etc.

Identification and Authorization Management

• ref naar IAM eisen in PvE, embedded

• verklaring op de eisen en een howto--> uitvragen: op welke manier wil een developer dit

See requirements in Programma van Eisen.

Encryption

• ref naar encryptie eisen in PvE, in embedded

• verklaring op de eisen en een howto --> uitvragen: op welke manier wil een developer dit

See requirements in Programma van Eisen.

Authentication

• ref naar authentication eisen in PvE, embedded

• verklaring op de eisen en een howto--> uitvragen: op welke manier wil een developer dit

• Ref naar authenticatie flow, embedded

Zie Autorisatierichtlijn Medicatieveiligheid | AORTA-LSP.

See requirements in Programma van Eisen.

See Bedrijfsarchitectuur; Actors

Configuration

Benodigde configurations, waarbij elke bullet point bij voorkeur embedded wordt opgenomen:

• Aansluiten op testomgevingen (referentie aansluitformulier)

• Endpoints (test)omgevingen POC - PTO2 - XTO1 (meer?)

• Autorisatie omgevingen (UZI middelen)

• Testdata

• Certificaten x.509

Voeg hier ook informatie m.b.t. de validatietools toe. Zie ook MEDVEILIG-177 voor links

Common Issues/Known Issues

Known issues is een overzicht waarin de issues zijn opgenomen van veel voorkomende problemen in de praktijk, met daarbij een advies hoe hier mee om te gaan.

Externe inline link naar common- / known issues (bijvoorbeeld in supportal)

Contact information

Contactgegevens

• Single point of contact (bijvoorbeeld: Product Manager), die verwijst bijvoorbeeld door naar:

  • VZVZ Testteam (vragen over: aansluiting, omgevingsproblemen, acceptatie, testscript)

  • Architectuurteam (vragen over: PvE)

Vul hier een link in naar bijv. een service desk of een andere manier om in contact te komen met iemand die geraadpleegd kan worden.

Vermijd namen, email adressen en telefoonnummers omdat een Developer Guide publiekelijk beschikbaar komt op het internet. Voeg alleen links toe naar een omgeving waarop eerst ingelogd moet worden voordat de vragen gesteld kunnen worden. Anders kun je wachten op spam-registraties.

Update 2024-11-12: er is nog geen generieke servicedesk applicatie beschikbaar, dus we ontkomen niet aan email adressen. Misschien moet er dan besloten worden dat alle vragen via het testteam gaan en dat zij ze intern routeren naar de juiste persoon.