...
| Note |
|---|
Use of events for cache invalidation, as described in Client-side caching , might not be immediately available to a client. As described in Client-side caching, caching of information from services in the Clinical Domain is not recommended, with the Patient service being an exception. |
Client-side caching of information from the more stable Administrative Domain must be considered.
In the following, the focus is on server-side caching applied upon to search operations and how a client can influence it.
...
Search results will be reused for 1 minute
This cache is used when identical searches are performed (same search parameters)
This means search results can be up to 1 minute stale!
Search results for a particular bundle ID is cached in the database for 1 hour
This cache is used when paging through the result bundle of a particular search
Max The max value for
max-resultsheader is1000Cache-Control: nostore, max-results=1000
Default The default page size is 20
Maximum page size is 200
Clients can request a particular page size by setting the
_countparameter
Person$match does not employ any caching
internally, it first searches for a Patient with the provided CRN in the local database (does not use the search result cache, for technical reasons)
If a patient exists, the information from that patient is returned
If a patient does not exist, a request is sent to the CPR registry to lookup look for the information
The result of this request is not cached or persisted
...
If your use case requires that search results are not cached you have the opportunity to opt out of this using httpHTTP-headers on your client request:
...
When a search operation includes references reference resources, however, this cannot be determined up frontupfront. In that case, access is checked for each included resource just before a page of search results is returned to the client. Previously, an error would be returned to the client in case of inadvertent security violations. This behavior behaviour has now been changed to a filtering mechanism instead. Any included resources that the user is not allowed to access are removed from the search result and returned to the client.
When resources have been removed due to access control, an OperationOutcome is included in the search result, where particular elements contains contain the following:
OperationOutcome.issue.severity:
warningOperationOutcome.issue.code:
suppressedOperationOutcome.issue.diagnostics:
Some included resources were filtered due to access constraints for the user