Skip to main content

Zorginzage V6 hackathon spec

This document is in DRAFT

Purpose

The purpose of the hackathon is to demonstrate a simple implementation of Nuts Zorginzage in Nuts V6. The present Nuts Zorginzage 2022 spec uses Nuts V5, but has several limitations, which is why the intention is to make use of Nuts V6 in the future. This hackathon is the stepping stone towards creating V6 Zorginzage usecases in the future.

Scope

  • add Martijn's draft of the scope with some clarifications what is out of scope and what is optional. To be enriched with more specific plans of participating vendors.

Functional design

Discovery Service (adressbook & use-case whitelist)

The Discovery Service serves the function of an adressbook for the organizations that are compliant and available for this specific usecase. Organizations can periodically publish themselves by presenting a set of Verifiable Credentials to the DS. Which credentials should be presented is part of the governance of the use-case. To automatically select these credentials from the organization wallet a query must be agreed upon and ran on each node. The syntax of this query must follow the Presentation Defenition of the PEX specification

For more info about how the DS works see the following presentation of a Nuts Tech session

Presentation definition

PD VCs

The PDs credibility is determined by the combined assurance level of the required credentials (VC). During the hackathon, only one verifiable credential, NutsUraCredential will be used. This is very similar to the Nuts Organization Credential (RFC012), but the primary difference is that it is no longer issuer by the vendor, but rather issued by a trusted authority. Also it uses the URA number instead of the KVK number as primary identifier.

The contents of the new 2024 version of the NutsUraCredential will be discussed in this Github Issue #3324.

Credential issuer:

There will be one trusted party that issues these VCs to the server-side-wallets of the other vendors in this usecase. We can use the following open-source implementation to issue the credentials:

The authority that will spin it up and issue the credentials for the hackathon can be anyone.

  • Decide who spins it up

PD logistical information

Alongside the VCs in the presentation definition, there following logistical information must also be presented

  • Usecase ID:

  • Max validity: 60 minutes

  • Server endpoint

  • ?

  • What else?

Localization

By localization we mean “finding out where a patient is in treatment”. That will not be in scope for this hackathon. Instead, we will request directly to the other organizations in the discovery service without checking/finding out if there is a patient file there.

Data-access policies

Wheter or not a requestor gets access to the data they are requesting depends on whether they pass the access-polices of the source (bronhouder). To ensure interoperability, a uniform standard for the data-acces policies is described for each usecase. The intention for the hackaton is to define this in the Open Policy Agent (OPA) scripting languagen.

Practitioner identification & authentication

The practitioner that initiates the request must be identifiable so that it can be verified at a later moment, who initiated what action (in line with NEN7513). Just having the identification information present has been deemed insufficient because that lacks the proof that a human performed an action (as opposed to a machine). To ensure the action is preformed by a human, an Employee Identity Credential is a required and checked in the data-access policy.

  • Expand and describe how

Authorization policy (checking legal base)

It is the responsibility of the bronhouder to check whether the requestor has a legal-base for accessing the data. For this Hackaton it is not strictly required to perform this check, nor does it have to be standardized. In current Nuts V5 implementations, the authorization is always explicit-consent based, which is why that will be the focus of V6.

  • Decide if and how we define authorization policy.

However, it is important that we standardize the error-responses to be used and what they indicate.

  • Decide error-responses for authorization

More policies? Run-time?

  • Add if relevant

Access token specification

The eventual access-token will look like this....

  • to-do

Resources

The aim is to validate that a simple data-request can be succesful. Therefore the set of resources is deliberately limited.

Data-exchange

  • Patient resource (link to Stu3 profile)

Authorization validation (optional)

Technical design

  • Todo: sequence diagrams
  • Todo: architecture map
  • Todo: specifying VC schemas
Back to top