Stream: finnish PHR
Topic: Finnish PHR R4 profiles
Anna Korpela (Sep 18 2019 at 10:47):
We've created the first drafts of Kanta PHR R4 profiles. You can find them at https://simplifier.net/finnishphrr4.
Please, take a look at them and send us any feedback you want to give us on the profiles.
We especially want your feedback on the following questions, nonetheless all kind of feedback is very welcome!
1. We have previously received feedback that the chosen "closed" profiling for Kanta PHR is not preferable. How would you change the profiling to make it more suitable for you (that still allows us to do proper validation for incoming data)? Maybe you can even provide us with a concrete example by creating a preferable version of one of the draft R4 profiles.
2. In R4, references have a 'type'. We've decided to constrain its use by setting the cardinality 0..0. Do you have a use case where the type may be useful in the context of Kanta PHR? Or is this an example of too strict profiling (see the previous question)?
3. In STU3 profiles, we profiled meta.security to be used for presenting a citizen's denial that that particular data is not allowed to be shared with social and health care professionals. According to the latest information, the functionality for sharing data with health and social care professionals will not include denials, only a consent for chosen information to be shared. Do you have other ideas how meta.security could be used in Kanta PHR? Would it be a nuisance for you if we constrained the use of meta.security on Kanta PHR profiles?
You can give your feedback and comments here on Zulip, or send it by email to kantakehitys@kanta.fi.
EDIT: All the comments will be presented/discussed in the next HL7 Finland PH SIG Kanta PHR support meeting in October, as well.
Mikael Rinnetmäki (Sep 18 2019 at 11:32):
1. From an app developer’s perspective, it would be ideal that an app could work with as many FHIR servers as possible, without major modifications.
Currently the biggest obstacle for this is that the Finnish PHR rejects entries that contain data it does not accept. I’d much rather see behaviour where the server would accept the data if it contains all mandatory fields, and then just discards all the data it does not want to store. I’d be OK with adding profile information to the entries, in order to show that I acknowledge there are limitations in a certain environment and I can live with those. But in my Implementation I would then add the profiles for both Finnish PHR and US Argonaut, and build the entries so that I can send them to both the Finnish PHR and an Argonaut server, containing all the mandatory data for both. Each of the servers would then accept and store the data it has support for.
In this regard it would be nice if the profiles were more permissive, and take in and store all the data, but another option would be to just modify the server behaviour so that it discards values it does not understand or does not want to store, while still accepting the data if all the mandatory fields are present.
Mikael Rinnetmäki (Sep 18 2019 at 11:32):
2. I’d say that is an example of too strict profiling. For blood glucose observations, I may, in a generic implementation, want to store the performer. Most of the time it’s the Patient, but on some occasions it may be a Practitioner (a nurse) or and Organization (a lab). In my app, I then have a functionality where I can search for results performed by an Organisation, so I can present those separately. This is why I’d like to store the type of the Observation.performer reference. Then, even if all the results I ever store to and retrieve from the Finnish PHR always have type Patient, I can still use the same code when my app retrieves data from other data sources too. If the Finnish PHR does not support storing the type of the performer reference, I need to build special code just to work around this limitation.
Mikael Rinnetmäki (Sep 18 2019 at 11:32):
3. Again, it would be nice to be able to store the information when we have it available, instead of having to explicitly stripping it out from the data. Our use cases are mostly related to the origin of the data. We may want to tag whether the data is imported from another IT system (for instance, a cloud service of a glucose meter vendor) or entered manually by the Patient. For some resources, we’d be interested in setting a flag when a healthcare professional has asserted them.
Anna Korpela (Oct 17 2019 at 07:27):
The comments/feedback was discussed yesterday in the HL7 Finland PH SIG Kanta PHR support meeting, and we agreed to loosen the Finnish PHR profiling guidelines/method to better suit the needs of applications (e.g. allow the use of subelements, allow the use of additional codes next to the mandatory ones required in Kanta PHR etc.).
Last updated: Apr 12 2022 at 19:14 UTC
