Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt

A list of best practices and anti-patterns regarding performance considerations and issues in application design.

Table of Contents
maxLevel7
minLevel1

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

...

Below, a list of best practices and anti-patterns are described to mitigate common issues i 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) or the Communication list(who is the Communication regarding) etc.


For this, the Patient demographic search using multiple Ids 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) → PlanDefinition (child) (subplansub-plan)

EpisodeOfCare (parent) → CarePlan (child)

...

CarePlan (parent) → CarePlan (child) (subplansub-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:

Code Block
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:

Code Block
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/igfhir/CapabilityStatement-plan.json.html

Include and reverse include is are only available for local resources onlyin the same service.