Stream: finnish PHR
Topic: thoughts on profiling
Jens Villadsen (Sep 24 2018 at 14:01):
Hello northern friends - I've seen some of your profiles on https://simplifier.net/finnishphr and it seems you guys are pretty eager in removing elements on your profiles. While I understand that there are elements that you have chosen to not be of significance in your clinical finnish setting, I can't seem to ignore that your profiles are going to be extremely tight bound and potentially conflict with other standardization framework profiles. Does it not make it harder for you guys to open up your systems down the line (just a thought)?
Mikael Rinnetmäki (Sep 30 2018 at 09:28):
Hi @Jens Villadsen , thanks for input into this discussion! From an app-developer perspective I fully support your view. Overly strict profiling makes it a lot harder for us to create apps that are interoperable across different FHIR implementations, and also requires a lot of unnecessary work when adapting apps developed elsewhere to the Finnish PHR.
I once thought this would be about saving storage space, which in my view seems absurd. The other comment I have heard supporting strict profiling is that through it, we can have better certainty in that each app in the ecosystem is really interoperable with each other to the last bit, as every last bit needs to be discussed in detail before it's allowed in the profiles.
Personally, I'd favour an approach that's closer to what I've understood the FHIR spirit is: support faster initial development of proposals and use cases - and just indicate in, for instance, maturity level how "standardized" we think the elements are, and aim for more complete harmonisation along the line, as more use cases emerge.
I'd be really happy to see any of the apps developed in the larger FHIR ecosystem to just plug into the Finnish PHR with no extra effort. Language translations are big enough of a hassle. :) And I would aim for profiling to occur on larger groups of participants - for instance all the Nordics, or an European profile. For me, that would be a much more exciting and lucrative approach.
Anna Korpela (Oct 09 2018 at 12:13):
The choice to use closed modelling in profiling was a conscious solution. The benefits achieved by this choice were
- We get smaller and straightforward models, and there is no need to support all elements -> solutions are faster to implement
- More specific profiles -> validation of data is easier against specific profiles, our Finnish PHR (Kanta PHR) solution is national, and our responsibility is to ensure that data stored in Finnish PHR is valid!
- We get more implementer feedback (as Mikael wrote: “as every last bit needs to be discussed in detail before it's allowed in the profiles”)
We have discussed a lot of this approach. At first it was questioned, do we need profiling at all. But it is obvious that base resources are not implementable without profiling, there is too much optionality (for example the strength of valueset bindings are “example”). There are solutions which tell that they are using only base resources, but that is not the whole truth. Solutions are quite limited, for example there is only possibility to retrieve resource instances, not store instances. And in these solutions, there is also done “profiling”, but it is done in textual format in implementation guides.
The scope of the Finnish PHR profiles is national PHR solution, so the profiles could be seen almost implementation specific. The scope is not ”clinical finnish setting”. In Finland we started to utilize FHIR in PHR context and we don’t have national finnish profiles. Our Finnish PHR profiles are based on FHIR vital signs profiles (we couldn’t use those as a base for structure definitions because of tooling problems). The profiles are strict but the resource instances that are valid against our Finnish PHR profiles are also valid against FHIR Vital Signs profile (or more specific FHIR profiles in vital signs scope). Therefore our Finnish PHR resource instances are compatible against solutions which are using FHIR vital signs profiles. The downside of the strict profiles is, as Mikael pointed, the need of adaption of the solutions developed elsewhere to the Finnish PHR (solutions must delete data not found in Finnish PHR profiles). We don’t believe that it is possible to develop profiles which can be used everywhere in same way/in all solutions (plug-and-play) , even the Nordic scope could be hard. Of course the Nordic profiles or national clinical setting profiles could be base for more specific profiles and it would be great to have that kind of base profiles.
Other option, to the strict profiling and removing elements from our profiles, would have been to define the elements that solutions must support. This has been the choice for example in FHIR International Patient Summary (IG). And this is maybe the best choice for the national base profiles or the Nordic profiles. This must be also discussed again in Finnish PHR scope, if we want that the profiles are more flexible, especially when moving to the FHIR R4. But the discussion still has to be done which elements are mandatory and which elements must be supported. And of course if we don’t remove elements that we don’t need/support, we have to discuss how to handle data in other than must-support elements (just take the data in, and return as it was stored?). And as we wrote above, in Finnish PHR we have responsibility to ensure that data stored in Finnish PHR is valid, so it is not a simple discussion.
Jens Villadsen (Oct 09 2018 at 14:42):
I fully understand and this is not a simple discussion. I just came across https://simplifier.net/guide/profilingacademy/Best-practices - and to some extend I fully understand your decisions.
Mikael Rinnetmäki (Nov 26 2018 at 21:09):
There's interesting discussion on https://chat.fhir.org/#narrow/stream/105-Sweden-on.20FHIR/subject/Patient/near/210159 as well. It seems in Sweden they're going more towards open profiles.
Last updated: Apr 12 2022 at 19:14 UTC
