| Excerpt |
|---|
Description Catalogue of design guides and best practices for developing Telemetric solutions using the eHealth infrastructure. |
...
Avoid designing a single monolithic User Interface that collects data from many of the eHealth microservices into one table or view.
A better option , is to separate different user interfaces and workflows in such a way that there is no need to combine large amounts of data in e.g. the same table view.
Target user interface and workflows to only require data from one (or a few) microservices.
Target the workflows and so that data is only retrieved when they are to be used.
A suggested approach is the use the same microservices strategy to the user interface itself by e.g. introduce introducing micro-apps or micro frontend patternpatterns.
Use of ”Backend for frontend” or API Gateway patterns
...
The “API Gateway” pattern can be a useful pattern for the eHealth architectures where there are a small number of backend services.
BFF is a variation of the API Gateway pattern and defines a separate API gateway optimized for each kind of client.
...
Isolate the clients from how the application is partitioned into microservices
Isolated the clients from the problem of determining the locations of service instances
Simplifies the client by moving logic for calling multiple services from the client to the API gateway
Reduces the number of requests/roundtrips. For example,
The API gateway enables clients to retrieve data from multiple services with a single round-trip. Fewer requests also means mean less overhead and improves improve the user experience.
Translates from a “standard” public web-friendly API protocol to whatever protocols are used internally
…
...
Minimize the amount of data that the backend-for-frontend (BFF) has to calculate on
If the a telemedicine solution or application requires a BFF try to minimize the amount of data that the backend-for-frontend (BFF) has to calculate on
Fetching too much and unnecessary data put puts an extra load on the BFF, and complicates the BFF.
Minimize the amount of data can by be done by:
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 telemedicine solutions or applications 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.
Applications (or BFFs) can prefetch the results of a query and placed place them into the cache
Consider if prefetching is really needed, is the BFF response time better than eHealth services?
Prefetching data may result in the prefetch data is being stale, and prefetching too many items increases the load on the eHealth Infrastructure.
...
Auto updates can be done from the client, by periodically requesting the same information from the eHealth Infrastructure, leading to
Automatic updates may require unnecessary processing and polling of data.
Automatic updates may put an extra load on the eHealth infrastructure.
Only do an auto-update of the user interface if really needed.
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 client from updating 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 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
Caching are both is provided by the eHealth Infrastructure that performs server-side caching , but can also be done in solutions or applications.
...
See Client-side caching for recommendations on caching in the telemedicine solutions and applications.
...
The events can be used in applications to 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 the information in context (patient, episode-of-care, careteam care team..) as a parameter in querying the FHIR services to limit the results.
If e.g., the user has set the context (patient, episode-of-care, careteam care team ..) 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 episodes of care relevant to the selected care - team
E.g., only tasks relevant to the selected care - team
Reduce response times from eHealth services
Minimize data and thereby work in telemedicine solutions or 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. |
...
The eHealth infrastructure effectively support supports parallel requests. If an Application or BFF needs to request data from different services, prefer parallel calls instead of sequential calls if possible.
However, when calling with many concurrent threads from BFFs, it is may be problematic for the infrastructure (similar to DDoS attacks).
...
That is, first request data when needed.
Avoid prefetch of data for e.g. details view in a Master-Detail pattern
...
Changing context comes with a penalty. Selecting or changing context results in the user idID, access token etc. is being refreshed for the specific security context.
...
The eHealth infrastructure services supports support count, to keep the load on clients, servers and the network minimized.
Count Counts are used to limit limiting the number of resources fetched from the database or server.
...
Some of the eHealth services provides provide support for paging of results.
...
Searching for resources is fundamental to the mechanics of FHIR. Generally, FHIR use uses “AND” between the parameters in searching.
Some searches allows allow for search on multiple idsIDs, instead of multiple gets on each idID.
See also:
...
FHIR allows for multiple parameters with the same key , and interprets these as being an AND set. So, for example, a range of &date=gt2022-01-01&date=lt2022-02-01 can be interpreted as any date within January 2022.
...
FHIR allows reference parameters may be "chained"
The eHealth services has have limited support for chained resource references.
...
| Code Block |
|---|
GET [base]/CarePlan?subject.name=peter |
Return all the careplans care plans that have a subject whose name includes "peter“Peter “.
However, due to the eHealth microservice architecture and resources are being handled by individual microservices, the chained parameters is are only possible with the same service. That is, limited to resources handled by the same service.