during the openEHR Cross-Boards Steering Group last Thursday, we briefly discussed the prospect to provide a (FHIR) Terminology Service to complement the modeling activities in the international CKM. @joostholslag kindly asked me to raise this issue in our discourse.
In HiGHmed, we have explored this option and are now working routinely with this combination (CKM + CSIRO Ontoserver). You can find examples for templates that are referencing value sets in the server: Clinical Knowledge Manager
To explain a bit more: in an OPT (see GECCO_Diagnose in the link above), you will find expressions like these:
These are resolved by the CKM and the different tools we use in HiGHmed, including Better Platform and EHRbase. In the CKM this will be resolved to the following form preview:
All the values are loaded dynamically. In our experience made in HiGHmed (and the national COVID 19 platform) this greatly facilitates handling of complex value sets, helps align with national standards and FHIR.
It would be great to have a discussion with the Clinical Program and the Modeling community how this could be of benefit to openEHR and what can be steps to achieve such integration. Iām looking forward to discussions and sharing experiences on the use of terminologies for openEHR.
Iām totally in favor of doing this separation. The sooner we can manage value sets outside the archetype definitions, the better. And FHIR is the way to go as an interface specification.
I would differentiate three actions:
Define a URL to be used in references in the international archetypes in the CKM. Something like https://terminology.openehr.org/fhir. Then, all references in the archetypes should point to that URL.
Decide about the back-end implementation. A terminology server can be a very simple service or offer very complex services. I donāt think that, at this point, openEHR has to offer a fully fledged terminology server. We just need to publish those value sets through a FHIR API. The back-end could be something free and simple such as a HAPI FHIR server. It could even be the CKM itself, since it has some support to publish termsets, but Iām not sure if it is FHIR-compatible.
In the future, it could be studied to have a full product (probably it would be a commercial product), if openEHR is able to pay for it, in order to edit the contents of those value sets.
The most important is (1), since if the back-end implementation technology/solution changes in the future, it should not have an impact in the published archetypes.
From the modeling point of view, we would also need some rules for the identification and governance of those value sets.
I agree that a simple FHIR-based TS might suffice but we have had very positive discussions in the past with the CSIRO Ontoserver folks, in terms of us having access to a free instance, so should definitely re-open these discussions. We met them again in the UK last year and this remains on the table.
I think there is still a place for managing some valuesets in-line in archetypes but would like to see our internal representations much more closely aligned to FHIR VS and codesystems, so that this becomes an issue of ābest governanceā and not really about he technology choice.
Generally speaking, any TS that supports the FHIR API regarding value sets and code systems āshouldā work, but when implementing it there were some subtle differences in what exactly would be returned for some requests between HAPI and Ontoserver for example. Some of it may have changed, but performance and usability are also different. Therefore, if openEHR can get an Ontoserver that would be much preferred and I too have reason to believe that CSIRO would be open to picking up these discussions again.
If openEHR hosts an instance of Ontoserver, we can then easily link it to CKM to support the ideas from @birger.haarbrandt and @joostholslag.
Thanks to the HiGHmed group, who has pioneered this functionality with us at Ocean, this functionality is working pretty reliable already.
Currently, CKM is caching these external FHIR value sets from the TS, but is not governing them.
In theory, we could govern FHIR VS in CKM directly and reach out to a TS for expansions etc. but this does not exist as of now and would require a detailed discussion first.
Youāll find that the termsets in CKM have many attributes that are quite similar to what you have in FHIR Value Sets nowadays - even though (or maybe because) these predate FHIR value sets by quite a few years.
I agree with Ian that external value sets are not necessary a good replacement for all value sets currently defined directly in an archetype, but for some it is and then this approach is very valuable. Consider size, reusability, and stability of the VS as some indicators.
Iāve not had much experience with this problem. But hereās my first thought:
I definitely see the value to include FHIR valuesets in (localised) templates. But for artefacts outside a controlled environment, like CKM archetypes, Iām a little scared about creating a dependency on an external Valueset thatās not managed by CKM (editors).
I guess Iām ok with using FHIR as a technology to process those valuesets. Although it would be nice to have a list of dependencies for CKM. (The openEHR specs are an obvious one, but probably there are more. Like GitHub, CKM itself etc.). Mostly for being able to get notified of changes/(security) problems with those technologies.
Now if the openehr (CPB/CKA/editors) could control valuesets in an instance of a terminology server, that could be fine. Than itās mostly a matter of convenience wether thatās a separate tool or part of CKM.
These would still be part of the same ckm governance process. As you say it is a matter of judgement whether internal or external is more appropriate. External template level calyswrs much more likely at bational level
