Profiling guidelines

Introduction

In this page we present the initial conventions for creating FHIR profiles and associated conformance resources conserning the technical integration of patient generated data to EHR systems. These guidelines are at the moment aimed at FHIR R4 version.

Language

Unless stated otherwise, the FHIR conformance materials will be created in English in order to encourage adoption and re-use.

Use open profiling model

An "open" model means that the profile can accommodate the elements specified by the functional model it represents, but doesn't impose further restrictions to the exchanged data. This Implemantation guide aims to describe a conceptual model for any wellness application for transferring patient generated data to EHR systems, therefore it's natural choice to use open modelling since in many aspects the concrete future use cases for this specification are not yet known. If and when restrictions are necessary for a specific use case, it will be added to the information standard specific profiles.

as a general guideline we only want to profile elements, cardinalities and bindings that require profiling. Other elements, cardinalities and bindings are left as-is.

Information standards used

The profiles and examples are presented with the assumption that in any real life use case the implemantation will need to derive implementation specific profiles to further enhance and adapt the profiles to the specific use case. For example the Task resource included here as an example is derived from Omaolo symptom assessment use case. As a result there are not yet any code-system specific guidelines, but the overall guidelline would be to use coded code-systems from THL Koodistopalvelin whenever applicable. Also at the moment there are no Finnish Core profiles for most commonly used resources (Patient, Organization etc.) The overall guideline at the moment is to follow Kela's FinnishPHR profiling when possible, and adapt to Finnish core profiles if such profiles emerge in the future.

Notifications

It is expected that the sending system (wellness app) will need to notify the receiving system (EHR side) when a new Task is created or when an existing Task is updated (see scenario 1 for details). Although the notification mechanism is out of scope for this implementation guide, it is assumed that the notification does not need to contain a Task or other resource id. Rather, it signals that the receiving system should perform a search at the sending system to look for additions or changes in the Task resources.

A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request on a pre-determined endpoint at the party that should be notified. This could be arranged using the FHIR subscriptions mechanism, but the endpoints could also be arranged by other means.