The best practices and design guidelines are elaborated below.
Best practices
Take advantage of the opportunity for paging in the Infrastructure
The eHealth services provides support for paging of results.
That is, eHealth API users only need to request to amount of data that is actually needed, and the limiting of the results can be done at the server or database level.
API users can define a _offset parameter in the request which means that when combined with _count the paging is done on the database level.
(The eHealth infrastructure has a default page size (i.e. default _count if not given) and maximum page size (i.e. maximum value for the _count parameter).
Example URL to invoke this method for the first page (assuming page size of 10):
http://fhir.example.com/Patient?identifier=urn:foo|123&_count=10&_offset=0
Example URL to invoke this method for the second page:
http://fhir.example.com/Patient?identifier=urn:foo|123&_count=10&_offset=10
Limit the scope of context changes to what is necessary
Under construction.
Apply filtering to searches (a smaller and more accurate result)
Under construction.
Use the search APIs' counting options (Limiting results (_count))
eHealth infrastructure services supports count, to keep the load on clients, servers and the network minimized.
Count may be used to limit the number of resources fetched from the database or server.
Example URL to invoke this method:
http://fhir.example.com/Patient?identifier=urn:foo|123&_count=10
See also: Search - FHIR v4.0.1 (hl7.org)
Use time constraints in searches (a smaller and more accurate result)
Under construction
Optimize call pattern (call in parallel and do not retrieve data one row at a time)
Under construction
Retrieve data on-demand where possible
Under construction
Careful using chained resource references
The eHealth services has limited support for chained resource references.
FHIR has the concept of chained resource references. That is, references may also support a "chained" value. For example, you might want to search for DiagnosticReport resources by subject, but use the subject's last name instead of their resource ID. In this example, you are chaining "family" (the last name) to "subject" (the patient).
The net result in the query string would look like:
http://fhir.example.com/DiagnosticReport?subject.family=SMITH
What this query says is "fetch me all of the DiagnosticReport resources where the subject (Patient) of the report has the family (name) of 'SMITH'".
Due to the nature of eHealth microservices resources are split into separate services, and therefore limited support for chained resource references, and therefore be careful using these.
Design guidelines
Take advantage of the opportunity for caching
Caching - eHealth Infrastructure Wiki - Confluence (atlassian.net)
Make the most of context choices (mainly the careteam context)
Under construction
Avoid unnecessary pre-fetching of data
Under construction
Make the task overview task / message-centric rather than a patient-centric
Under construction
Target the operation (and scope) of the user interfaces to the workflows
Under construction
Avoid unnecessary auto-updates of the user interface
Under construction
Take advantage of Infrastructure events (mq)
Take advantage of Infrastructure events (mq) for listening to resource changes and perform cache invalidation.
See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1177911316/Caching#Cache-invalidation-using-events for events.
Minimize the amount of data that the backend-for-frontend (BFF) has to calculate on
Under construction