Architecture

Important note

This document is work-in-progress, but made public to make the development process as transparent as possible. Changes not only can, but will occur as we learn more about the domain and the needs of the sector.

Questions can be asked in the DHG Slack channel (reach out to product owner Asefeh Johnsen via email to be invited to our open Slack channel).

Intro

The goal of DHG (Digitalt helsekort for gravide) is to avoid that pregnant women need to carry a physical document with them (in reality - a whole folder of documents) throughout their pregnancy. A pregnancy usually involves consultations with a lot of different health care professionals, using different EPJ-systems (elektronisk pasient-journal), resulting in important health-data regarding the pregnancy being spread a cross a lot of different systems. To solve this, we are building a national solution so that pregnancy related data can be sent to NHN via. APIs, stored nationally, and then fetched and updated by other systems when needed.

On a high level, the idea is this:

In reality it's not quite this simple, since many different "types" of health data is involved when following up on a pregnancy, many of which are already distributed via other national APIs, like prescriptions (e-reseipt/PLL/legemiddel-API), test results (pasientens prøvesvar), critical information (API) and so on. As a general rule, we do not want to duplicate data from one service into another service (in this case DHG), as this can lead to data becoming stale and out of sync, which worst case could lead to errors when treating patients. Therefore, the DHG-API will not include data from other NHN services. It can, however, include references (IDs) to data stored in another service, more on this under the referencing section.

What this means is that when creating the UI for DHG in an EPJ-system, one might have to fetch data from other services as well, to create the best possible user experience for health care professionals. This is however not a requirement, so only integrating with the DHG-API is also possible.

Creation of a DHG

When a women comes in for a pregnancy consultation, the DGH-API should be called to see if a DHG exists. We will provide a status-endpoint for this, that can be used with a HelseID machine-token. If no DHG exists, a DHG should be created, and basic information about mother, co-parent, the pregnancy etc. should be added.

It's also possible the DHG can be created from Helsenorge, with the woman filling out the initial data themselves.

Versioning / Syncing data from/to NHN

All changes in a DHG will be stored as separate "events", essentially creating a new version of the DHG each time an update happens. This lets us keep track of all changes, when they happened, and who made them, creating a versioned history of the document(s).

We will also be exposing a "status" endpoint, where an EPJ can check when the DHG was last updated. This way there is no need to check the DHG itself to see whether anything has changed; simply store a "last sync" date each time DHG is read from NHN, and compare the date from the status endpoint. This way you only need to fetch data when something has actually changed.

Referencing

Like previously noted, we do not want to duplicate data from other services into DHG, but there might be cases where we would like to reference data in other services, and possibly include some subset of the data. An example of this is test results. The paper "helsekort" has a section for this, as shown below.

"Hepatitt B (HBsAg)" is a recommended test for all pregnant women, and is done via a blood test. When this test is completed, a copy of the result is sent to the NHN service "pasientens prøvesvar" (given that the laboratory has an integration), where the results can be looked up by healthcare professionals. One possibility is then that we don't store any data about these test results in DHG, and an integration with "pasientens prøvesvar" is required to get this information. This would mean having to go through all of the pasients test results to check what tests have been done, and what the tests showed to figure out if they are "Hepatitt B" positive. So in this case, we will probably make it possible to reference the ID of the test result in "pasientens prøvesvar" from DHG, so it can be easily linked, and also include the interpretation of the test (whether it was positive or negative). This might look something like this (very simplified example):

"testResults": {
    "Hepatitt-B-HBsAg": {
        "registrateredAt": "dateTime",
        "result": "negative",
        "refIdPPS": "cb8070ba-cc10-45fc-9e0d-65f9238ca1c3"
    },
    "Hepatitt-B-Anti-HBc": {
        "registrateredAt": "dateTime",
        "result": "negative",
        "refIdPPS": "cb8070ba-cc10-45fc-9e0d-65f9238ca1c3"
    },
    "HIV": {
        "registrateredAt": "dateTime",
        "result": "negative",
        "refIdPPS": "cb8070ba-cc10-45fc-9e0d-65f9238ca1c3"
    },
    "Syfilis": {
        "registrateredAt": "dateTime",
        "result": "negative",
        "refIdPPS": "cb8070ba-cc10-45fc-9e0d-65f9238ca1c3"
    }
}