I’m currently working with Better on developing a candidate approach for creating openEHR packages, drawing inspiration from the FHIR npm Package Manager.
In this process, I’ve been exploring the FHIR architecture and its methodology—some aspects are worth reusing, while others present opportunities for improvement, particularly where the FHIR approach has its limitations (in my opinion).
I’m reaching out to the community to ask: Is anyone else in the UK currently exploring this area? I’d also love to hear your thoughts on the pros and cons of the FHIR npm package management system. Whether you’ve had experience with it or have strong opinions, your insights would be invaluable.
@SevKohler I do hope so - I wanted to test out some of the ideas locally first. The intent is to create something useful for the whole openEHR community.
This has actually been on the SEC worklist for a while,
To my knowledge there is already a fair bit of local package mgt use, certainly DIPS use NuGET.
I do like NPM, especially as it is in use by FHIR community and the package mgt problem really transcends just openEHR artefacts to include mappings, IG, valuesets, GDLs etc. It is certainly something that the FHIR community would be interested to work on with us.
We should add that the need for package mgt was anticipated and is somewhat specified in openEHR and supported in CKM but I think there is broad recognition that we would get more value from a more industry-wide solution.
… the need for package mgt was anticipated and is somewhat specified in openEHR
Thanks, I wasn’t aware of that I will take a look.
My explorations go beyond just what is in the package but how to create one and the lifecycle management around them. This includes both the registry and discovery aspects of the Package Management process.
One of the challenges we might have is that each archetype is versioned independently .i.e. it is essentially its own package, and is version-labelled ‘inside’ the artefact and not externally.
AFACCT NPM is still mostly used in FHIR just for IG dependency mgt, to hook up with libraries like FHIR releases.
It’s likely quite similar to FHIR, where all definitional resources have their versions defined internally, much like Archetypes.
In FHIR, the concept of a package emerged because users wanted to version a collection of artefacts separately from the individual artefacts themselves.
For instance, if you have an openEHR CarePlan solution that utilises Archetypes, Templates, Terminology, AQL, etc., each of these would have its own version. However, the entire collection (or package) would also be defined and versioned as a whole.
In CKM, we can create Release Sets to pull templates and archetypes (+additional artefacts) together and ensure that they are all consistent.
Apart from being exported as a whole, they have a manifest as well , etc. and we could certainly change this to a more common format or add to it.
If at one stage we see value in providing a v1 release of approved international archetypes, this can be done this way - much like fhir publishes their versions of resources etc in coordinated releases.
@Sebastian clarified for me that although we quite clearly recall Release Sets being discussed as part of openEHR, this never matured into the actual specs.
The decision to use Semver for versioning was definitely predicated on the value of aligning with wider industry practice.