Tipps

Please include code system into queries

If you use queries that restrict by code please provide the code system in your query.

Including the code system will prevent (future) problems when a code also exists in a different code system
Queries including code system are more performant than queries by code only.

Good: [GET] /fhir/Observation?code=http://loinc.org|72098-7

Bad: [GET] /fhir/Observation?code=72098-7

Restrict by patient where possible

A query will target all readable records if it is not restricted by patient. Be careful not to work with data belonging to the wrong person.

If your application deals with data from multiple persons:

Whereever you know the id of the person you want records about include the “patient” search parameter in your search requests.

Good: Use “patient” restriction where possible [GET] /fhir/Observation?code=http://loinc.org|72098-7&patient=a5ce8145214

The id of the app owner is returned by the authorization call.

If you the the SMART ON FHIR OAUTH authorization the id is in the “patient” field of the oauth response. If you use the MIDATA authorization. The id is in the “owner” field of the ‘/v1/auth’ response.

If your application only deals with data from the application owner

You should include the restriction into your applications Access Filter. You find the Access Filter on the (developer) portal page where you registered your app. This will automatically restrict all your queries to the data of the application owner.

Restrict by “app” if your application should not use data from other applications

If your application only uses data from the application itself and not work with data from other sources you should restrict access to the application data only.

This restriction does not deal with the person who generates the data, only with the application.

For example a “Fitbit Import” plugin should only see Body Weight Observation records from itself. A Body weight record entered using another application should not be considered. A Weight-monitoring App in contradiction should use all available data sources.

In order to restrict your application to data from itself add “app” : [””] to the Access Query on the application registration page.

Avoid similar parallel queries

If you need to do multiple queries on the same user account it will be faster to run one query after another than to execute all queries in parallel.

References with identifier

If you store or update resources that need to reference another Patient or Practitioner and you only know the email address of the target person but not the id you can use an identifier for reference:

The server will lookup the corresponding account and replace the identifier with a normal reference. The no matching account is found a 400 error is thrown.

Reference using identifier:

{ "identifier" : 
    { 
        "system" : "http://midata.coop/identifier/patient-login",
        "value" : "email@address.ch"
    }
}

will be replaced with

Resolved Reference:

{ 
    "reference" : "Patient/abc12345",
    "display" : "Hugo Müller"
}

Currently these “system” values for identifier are supported:

System	Description
http://midata.coop/identifier/patient-login	Account Holder is looked up by provided email address. Resolves to “Patient” reference
http://midata.coop/identifier/practitioner-login	Healthcare Provider is lookup up by email address. Resolves to “Practitioner” reference.