Versions Compared

Old Version 4

changes.mady.by.user Erik Nielsen

Saved on

compared with

New Version Current

changes.mady.by.user John Schneider

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In the following, the focus is on server-side caching applied to search operations and how a client can influence it.

Table of Contents

Interactions with the Terminology Service

Determining the proper code, system and unit for Quantity

Given an observation codeand corresponding system from the ValueSet ehealth-observation-codes, how does one then determine how to specify an observed quantity or reference range? The following describes how to obtain values to set inQuantity.code, .system and .unit.

To get values forQuantity.codeandQuantity.system use the ConceptMap conceptmap-obs-code-to-ucum as follows:

  1. Call $translate on the given code and system:

    1. GET <base-url>/fhir/ConceptMap/$translate?system=<system>&code=<code>

  2. On match found, the values to use in Quantity.codeandQuantity.systemare the matching concept’s code and system, respectively, where the source ConceptMap is “http://ehealth.sundhed.dk/ConceptMap/conceptmap-obs-code-to-ucum” (see example response below):

Info

Example request and response on $translate on conceptmap-obs-code-to-ucum

Request:

GET <base-url>/fhir/ConceptMap/$translate?system=urn:oid:1.2.208.176.2.1&code=NPU03804

Response:

{     "resourceType": "Parameters",     "parameter": [         {             "name": "result",             "valueBoolean": true         },         {             "name": "message",             "valueString": "Matches found!"         },         {             "name": "match",             "part": [                 {                     "name": "equivalence",                     "valueCode": "specializes"                 },                 {                     "name": "concept",                     "valueCoding": {                         "system": "http://unitsofmeasure.org",                         "code": "kg",                         "display": "kilogram"                     }                 },                 {                     "name": "source",                     "valueUri": "http://ehealth.sundhed.dk/ConceptMap/conceptmap-obs-code-to-ucum"                 }             ]         }     ] }

To get the corresponding and printable value for Quantity.unit, use the ConceptMap conceptmap-ucum-to-printsymbol as follows:

  1. Call $translate on the given system and code determined in the response above:

    1. GET <base-url>/fhir/ConceptMap/$translate?target=http://ehealth.sundhed.dk/vs/ehealth-ucum-printsymbol-supplement&code=<code>&system=<system>

  2. On match found, extract the matching concept (see example response below).

  3. Call $lookupon the matching (CodeSystem) system and code:

    1. GET <base-url>/fhir/CodeSystem/$lookup?system=http://ehealth.sundhed.dk/cs/ehealth-ucum-printsymbol-supplement&code=<code>

  4. On match found, the value to use in Quantity.unitis the matching concept’s designation.valuewhere the designation.language=da(see example response below). If there is no such designation, the printable value in Quantity.unit shall be left empty.

Note

The $lookup does not return designation on eHealth Infrastructure Release 4 and other releases prior to Release 5.

Info

Example request and response on $translate on conceptmap-ucum-to-printsymbol

Request (Note that URL-encoding of percent as code is used):

GET <base-url>/fhir/ConceptMap/$translate?target=http://ehealth.sundhed.dk/vs/ehealth-ucum-printsymbol-supplement&code=%25&system=http://unitsofmeasure.org

Response:

{     "resourceType": "Parameters",     "parameter": [         {             "name": "result",             "valueBoolean": true         },         {             "name": "message",             "valueString": "Matches found!"         },         {             "name": "match",             "part": [                 {                     "name": "equivalence",                     "valueCode": "specializes"                 },                 {                     "name": "concept",                     "valueCoding": {                         "system": "http://ehealth.sundhed.dk/cs/ehealth-ucum-printsymbol-supplement",                         "code": "%",                         "display": "percent"                     }                 },                 {                     "name": "source",                     "valueUri": "http://ehealth.sundhed.dk/ConceptMap/conceptmap-ucum-to-printsymbol"                 }             ]         }     ] }

...

Example request and response on $lookup on ehealth-ucum-printsymbol-supplement

Request (Note that URL-encoding of percent as code is used):

GET <base-url>/fhir/CodeSystem/$lookup?system=http://ehealth.sundhed.dk/cs/ehealth-ucum-printsymbol-supplement&code=%25

Response:

...

Caching of Search results

Caching in Telemedicine Solutions

Telemedicine Solutions caching of information is, as caching in general, a mechanism for achieving better performance although it must be applied with caution, especially when used with clinical content.

Note

As described in Telemedicine Solutions caching of information from the infrastructure, caching of information from services in the Clinical Domain should be used with care, with the Patient service being an exception.

Use of events for cache invalidation, as described in Telemedicine Solutions caching of information from the infrastructure , might not be immediately available to a client.

Telemedicine Solutions caching of information from the more stable Administrative Domain must be considered.

Caching in eHealth Services

It can generally be assumed that the caching is based on the principles described in https://hapifhir.io/hapi-fhir/docs/server_jpa/configuration.html#search-result-caching . When interacting with custom operations, caching is specific to the operation itself.

Patient Service

  • Services cache search results for 1 minute

    • Services use the cache when identical searches (same search parameters) are performed

    • This means search results can be up to 1 minute stale!

  • Search results for a particular bundle ID are cached in the database for 1 hour

    • This cache is used when paging through the result bundle of a particular search

  • The max value for the max-results header is 1000

    • Cache-Control: nostore, max-results=1000

  • The default page size is 20

  • Maximum page size is 200

    • Telemedicine solutions can request a particular page size by setting the _count parameter

  • 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 look for the information

        • The result of this request is not cached or persisted

Info

Sticky sessions are not required as the cache is stored in the database.

Disabling Server-side Caching on Searching

Telemedicine Solutions can selectively disable caching for an individual request using the Cache-Control header:

...

In a HAPI FHIR-based client, opt-out can be achieved like this:

...

Filtering on Searching with Included Resources

Info

This functionality is available from eHealth Infrastructure Release 6.1 when including referenced ClinicalImpression in a Task search. It may later be extended to other resource types.

For the primary resource, it is possible to verify search parameters against the security token before performing the actual search against the database. This ensures that the user is allowed access to all resources found by the search.

When a search operation includes reference resources, however, this cannot be determined upfront. 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 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 contain the following:

  • OperationOutcome.issue.severity: warning

  • OperationOutcome.issue.code: suppressed

  • OperationOutcome.issue.diagnostics: Some included resources were filtered due to access constraints for the user