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 i 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:
Task lists
EpisodeOfCare list, showing a list of EoCs that a CareTeam is responsible for
CarePlan list, showing a list of CarePlans that a CareTeam is responsible for
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) or 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 a 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 of across parent/child resources. In the eHealth Infrastructure, examples include:
PlanDefinition (parent) → ActivityDefinition (child)
PlanDefinition (parent) → DocumentReference (child)
PlanDefinition (parent) → PlanDefinition (child) (subplan)
EpisodeOfCare (parent) → CarePlan (child)
CarePlan (parent) → ServiceRequest (child)
CarePlan (parent) → CarePlan (child) (subplan)
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:
https://plan.{{domain}}/fhir/PlanDefinition/?_include=PlanDefinition:action-definition
To get a single PlanDefinition with every all child resources resolved, this can be done in a single API call:
https://plan.{{domain}}/fhir/PlanDefinition/?_id=1507&_include=*
Capability statement
For more information about the capabilities of each service, refer to the FHIR Capability Statements.
Plan service Capability Statement example:
https://docs.ehealth.sundhed.dk/latest-released/ig/CapabilityStatement-plan.json.html
Include and reverse include is available for local resources only.