As well as CKM, quite a number of implementers/ modellers make their openEHR content available via GitHub. @erik.sundvall@vanessap@bna amongst others
However keeping track of where those repos live or whether they contain clinical models vs. other software artefactsm is quite challenging…
I have two proposals
Perhaps setup some sort of registry of GH accounts with public openEHR content repos.
Tag those repos which explicitly have archetypes or template with something like ‘openehr-content’, so that they can be clearly identified.GitHub Topics seems a good fit for this as it is readily searchable Topics on GitHub · GitHub
Part of my thinking was to make it easy by allowing people to publish their accounts on such an ‘awesome’ page but make that largely self-managing by ‘tagging’ any content-related repos.
You can then use the GitHub api / search box or their new GH CLI tool
ian@MacBook-Pro hse-docs % gh search repos --topic=openehr-content
Showing 2 of 2 repositories
NAME DESCRIPTION VISIBILITY UPDATED
freshehrteam/Salford_PROM public about 24 minutes ago
freshehr/nhs-pgx NHS Pharmacogenetics project private about 2 months ago
Sure, just tell us what tag to use and we’ll do our best to tag it (and we hope that somebody else will write that script for outputting links on a webpage).
So the Topic to add to any repository that contains openehr archetypes, templates or gdl is
openehr-content
@erik.sundvall -instead, or as well as outputting the links to a web-page, it might be worth considering a tool that would parse the contents of a repo and create a Markdown formatted list of contained archetypes and templates (along with their human concept names. That can be added to the repo README which I understand to be searchable in GitHub.
Besides tags, it might be good to standardize the repo structure too, e.g. archetypes, templates etc. Our own CKM follows a pre-defined structure to facilitate batch-import of these models.
I agree about a basic structure, which I think also needs to separate local content from remote non-owned archetypes. I’m not so bothered about separate folders for each archetype class
So ?
archetypes
local
com.freshehr
org.ucp.london
remote
org.openehr
uk.org,apperta
templates
local
com.freshehr
org.ucp.london
remote
org.openehr
uk.org,apperta
gdl
valuesets
mappings
Could everyone who is keen on the idea and already publishes openEHR content on Github, add openehr-content as a “Topic” to any repos and let me know so that I can test that we are picking them up in GH searches.
Isn’t openehr-content a bit generic if it is to be used only for archetypes and templates? Maybe something like openehr-models is more descriptive. And then we can also have openehr-tools for implementations, to say something.
But this is just a though, I don’t want to enter into defining full ontology of openEHR topics
I’m definitely up for other suggestions - I wanted to include valuesets, GDLs, AQL etc i.e. anything that is not ‘code’ as such which was why I did not want to use ‘models’ maybe ‘openehr-care-content’?
I just added this topic to a few of the repos I have access to.
I think it’s hard to come up with something much better than ‘openEHR-content’.
So could we settle on that for now?
@sebastian.garde could you do this for CKM mirror please? @rong.chen could you do so for the GDL repos? @SevKohler could you do so for the omocl and fhir-connect repos? @vanessap could you do so for your repos?
@Pete_Bouvier if we get this going, would be good to add this trick to the openEHR website page that lists CKMs.
Just as a heads-up, we’re looking at moving all our public Norwegian openEHR related repos to Codeberg.org due to … *waves hands vaguely at the state of the world*
Unfortunately topics are github specific afaik . Yhe whole point was to make the artefacts essily discoverable through gh search. Im not aware of any generic git approach. Also the openehr AD only supports github for read write, git is supported but readonly.
That’s why I’m mentioning it here, tbh. Nothing’s finally decided yet, but since we’re consolidating a number of repos from different organisations and personal accounts soon anyway, it only makes sense to make the move away from a US based service while we’re at it.
Ah, that’s an important consideration for our planned procurement. Thanks!
I think at least the on-prem AD supports GIT in general not only Github, but logins etc might be trickier to set up fo admins and adjust to for end users instead of just using Githubs’s/Microsofts’s. @borut.fabjan or somebody else at Better might know details.
@siljelb a first step to reduce reliance on US services could be to make sure that you set up some automatic copying of Github content to som non-US GIT provider. If a lot of openEHR users start using a particular non-US GIT-service, then I guess it could be worthwile for openEHR to set up a second CKM-mirror feed from CKM to that other GIT-service instead of only to Github.
