FHIR Chat · OMAkanta UI · finnish PHR

Stream: finnish PHR

Topic: OMAkanta UI


view this post on Zulip Juha Vuorinen (Dec 22 2017 at 12:47):

We specify FHIR resources for OMAKANTA so that end customers can see their well being data collected from various apps. How the User Interface of OMAKANTA is specified? Can there be various IUs for each app? Who implements these UI?

view this post on Zulip Juha Vuorinen (Dec 22 2017 at 14:24):

I searched again little bit this area. It seems to be that OMAKANTA is just a storage for 'patient' data based on FHIR profiles. It's up to applications how they show the data to 'patient' or end user.

view this post on Zulip Juha Vuorinen (Dec 28 2017 at 12:22):

This leads me to next scenario: let assume that there is a profile A in OMAKANTA (or Kanta PHR), which is used by two applications B and C. There is a citizen D, who uses application B to store/read his/her health data as specified by profile A. Naturally the citizen D has to have given his/her consent for this. Now, there is this application C, who also use profile A to store / read citizens' data. Can application C read the citizen D's data? If not, how this is controlled?

view this post on Zulip Eeva Turkka (Jan 02 2018 at 07:52):

Application C can read the data if it has the access privileges to that data type. See the Authorization guide on this page for more details: http://www.kanta.fi/en/web/ammattilaisille/tarkeaa-tietoa-kehittajille

view this post on Zulip Juha Vuorinen (Jan 02 2018 at 09:49):

Thank you Eeva. I think I got it . Applications' access privileges to patient data (or resources) are stored in the authentication/access control server and sent to application's client, when application request access to PHR. Access privileges are determined in the registration phase of an application. Access right token includes the user id (or social security id, if strong identification is required), which identifies the patient in PHR and the resources which are available for the application.

view this post on Zulip Eeva Turkka (Jan 02 2018 at 10:06):

Yes, that's the general idea! Happy to help :)

view this post on Zulip Juha Vuorinen (Jan 10 2018 at 12:11):

Just one issue still, Eeva. Even I read these documents, I don't yet fully understand does the consent given by the patient concerns the application or the resource itself? In other words, if patient given access rights to his/her data (stored as resources of specific profile(s)), it is possible that any application can read this data? Or is it so that patient also give consent to certain applications only?

view this post on Zulip Eeva Turkka (Jan 10 2018 at 13:07):

@Anna Korpela can fill in more about consent, but there are two differect concepts here.

1) Authorization and permissions to a resource for an application: this works for all resource instances of the given object type (== for example Observation) and can be given to read and to write separately. The application needs to have these registered and then need to request the permissions. Each application needs to be authorized separately and each will have the permissions the user authorizes it to have. It is possible to have Application A to read Observations and Questionnaires, write and read QuestionnaireResponses and Application B to read and write Observations. They'd have access to all resource instances of those types (Observation, Questionnaire, QuestionnaireResponse)

2) Consent as a concept is permission by the user to let healthcare professionals access their data and it doesn't directly link to the access of an application.

view this post on Zulip Juha Vuorinen (Jan 10 2018 at 17:06):

Thank you, Eeva!


Last updated: Apr 12 2022 at 19:14 UTC