Excerpt |
---|
A list of best practices and anti-patterns in regards to regarding performance considerations and issues in application design. |
...
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:
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 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/ig/CapabilityStatement-plan.json.html
Include and reverse include is are only available for local resources onlyin the same service.