...
Target user interface design to microservices (see above Design Guide)
Avoid prefetch of data for e.g. details view in a master-detail pattern
Prefer calling eHealth services directly, only use BFF pattern if really needed
Only do caching in vendor application if really needed
…
Avoid
...
pre-fetching of data
If you are lucky, you may know enough about what your users will do to next, and thereby be able to prefetch the data they need before it's needed.
...
Prefetching data may result in the prefetch data is stale, and prefetching too many items increases the load on the eHealth Infrastructure.
...
Design for concurrency
Design for and recognize other clients may have updated the resources
Automatic updates of the user interface can be used to avoid users looking on at and updating old data.
However, automatic updates of the user interface with updated information on the eHealth Infrastructure should be limited.
...
Only do auto update of the user interface if really needed.And if, preferable use the eHealth domain events, rather than polling for updates.
A ‘better’ option is to recognize other clients may have updated the resources.
A combination of the ETag and If-Match header can prevent one clients update the same resource, and the second overwrites the updates of the first
If the client wishes to request a version aware update, it submits the request with an If-Match header that quotes the ETag from the server:
| Code Block |
|---|
PUT /Patient/347
HTTP/1.1 If-Match: W/"23" |
If the version id given in the If-Match header does not match, the server returns a 412 Precondition Failed status code instead of updating the resource.
Take advantage of the opportunity for caching
...
See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1034354702/Technical+Interactions+with+Services#Caching-on-Searching on caching provided by the infrastructure.
See Caching - eHealth Infrastructure Wiki - Confluence (atlassian.net) Client-side caching for recommendations on caching in the Vendor applications.
...
Infrastructure events can be used in Vendor Applications to trigger business functionality.
The eHealth Infrastructure publish simple events at a CRUD resource level e.g.
...
The events can be used in Vendor Applications to
...
trigger business functionality in case of events.
...
Update user interfaces with updated data
e.g. update cached information
...
Make effective use of the user selected contexts
Make effective use of the end user selected context and thereby the results returned by the eHealth services
Use information in context (patient, episode-of-care, careteam ..) as parameter in querying the FHIR services to limit the results.
If e.g., the user has set context (patient, episode-of-care, careteam ..) the context can be used to:
Provide as parameter in querying the FHIR services to limit the results, the eHealth services will then filter and limit the results returned to the client.
E.g., only episode of care relevant to selected care-team
•EE.g., only tasks relevant to selected care-team
Reduce response times from eHealth services
Minimize data and thereby work in Vendor Applications
Reduce the risk of UTH (adverse events, Danish: utilsigtet hændelse)
The context can be considered as three levels of context for Attribute Based Access Control:
Use the care team for searching across resources (avoid Patient and Episode-Of-Care)
Use the patient context for more specific results
The episode-of-care limits the results further. The EOC is often required for updates.
Best practices
| Info |
|---|
NOTICE, example URLs in the following are just examples. Please look at the capability statement in the Implementation Guide for the actual capabilities. Furthermore, the infrastructure develops and capabilities may change. |
...
Take advantage of the opportunity for paging in the Infrastructure
The Some of the eHealth services provides support for paging of results.
...
Searching for resources is fundamental to the mechanics of FHIR. Generally FHIR use “AND” between the parameters in searching.
FHIR Search _filter _filter is a parameter that can be used with some of the search operations, and provides a powerful language to express filtering restrictions to narrow down the results of a broad query.
It uses the same set of standard parameters defined for the resources, and provides a syntax for expressing a set of query expressions on the underlying resourcesSome searches allows for search on multiple ids, instead of multiple gets on each id.
See also:
...
This search finds any Appointments changed since 1- February 2022.
...
Limited support for chained resource references
FHIR allows reference parameters may be "chained"
...
To save a client from performing a series of search operations, FHIR allows reference parameters may be "chained" by appending them with a period (.). Example:
| Code Block |
|---|
GET [base]/CarePlan?subject.name=peter |
Return all the careplans that have a subject whose name includes "peter“.
...