The eHealth Infrastructure consists of a large set of APIs that are designed to support common workflows in applications for the telemedicine domain.

To ensure proper use of the shared resources, it is important to consider the performance of the client applications and the way they access data in the Infrastructure.

This improves the end-user experience as well as the utilization of the common hardware resources.

Below, a list of best practices and anti-patterns are described to mitigate common issues in application design.

Don’t request Patient Context tokens pr. row in a list.

The Patient Context is for focusing on a specific Patient. It ensures that all clinical information retrieved from is related to that Patient only. This helps the client app to avoid mixing clinical data from multiple Patients.
For cross-patient related lists such as:

1. Task lists

2. EpisodeOfCare list, showing a list of EoCs that a CareTeam is responsible for

3. CarePlan list, showing a list of CarePlans that a CareTeam is responsible for

4. A list of Communication resources, for showing an “inbox” for a CareTeam or a Practitioner

It might be necessary to display related Patient demographic information along with the Task list (who is the subject of the Task), the EpisodeOfCare list (who is the subject of the EoC) the Communication list(who is the Communication regarding) etc.

For this, the Patient demographic search using multiple IDs is designed to retrieve all the related Patient information in a single API call. In the BFF, the view model is then constructed based on both datasets to support the User Interface.

Use Include and reverse include when searching multiple levels of resources

When creating lists spanning both parent and child resources many use cases are supported using the include and reverse include functionality specified by FHIR:
https://hl7.org/fhir/search.html#revinclude

With include you can get a performance-friendly search across parent/child resources. In the eHealth Infrastructure, examples include:

PlanDefinition (parent) → ActivityDefinition (child)

PlanDefinition (parent) → DocumentReference (child)

PlanDefinition (parent) → PlanDefinition (child) (sub-plan)

EpisodeOfCare (parent) → CarePlan (child)

CarePlan (parent) → ServiceRequest (child)

CarePlan (parent) → CarePlan (child) (sub-plan)

API Examples

To get all PlanDefinition resources with a specific type of child resource (ActivityDefinition resources), this can be done in a single API call:

To get a single PlanDefinition with all child resources resolved, this can be done in a single API call:

Capability statement

For more information about the capabilities of each service, refer to the FHIR Capability Statements.
Plan service Capability Statement example:
https://ehealth.sundhed.dk/fhir/CapabilityStatement-plan.json.html

Include and reverse include are only available for resources in the same service.