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. The Discovery Service has its own use-case specific schema: Presentation Definition (PD). All the vendors in the us ecase prove their compliance with the PD by periodically publishing their PD to the discovery service.

*For more info in DS see: https://docs.google.com/presentation/d/1LRnY5JfMAcMwwqEonX3n_uEDT1geQ3Kj_IKxS-ZeeVA/edit#slide=id*.g1f525990acb_0_159

Presentation defintiondefinition

PD VCs

The PDs credibility is determined by the verifiability of the required credentials (VC). Only one verifiable credential will be used for the hackathon. This is very similar to the Nuts Organization Credential in V5, but the primary difference is that it is no longer self-issued, but rather issued by a governing authority

Credential contents:
  • URA (logical identifier)
  • Adress
  • ?
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

  • Use caseUsecase 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