Using Github to share openEHR content

Tool Support REQUESTS
1

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

  1. Perhaps setup some sort of registry of GH accounts with public openEHR content repos.

  2. 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

e.g. GitHub - freshehrteam/Salford_PROM

4 Likes
2

A simple, yet effective way is following the tradition of ‘awesome X’ repositories. As in GitHub - krispo/awesome-haskell: A collection of awesome Haskell links, frameworks, libraries and software. Inspired by awesome projects line.

just google awesome bla and you’ll hit a repo. Assuming bla is a programming language, tech concept etc. Very common with frameworks, libraries etc.

then you put the repo link in your documentation or some other visible/central location.

4 Likes
3

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

You may not see the private repo

1 Like
4

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).

5

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.

1 Like
6

Great idea. And let’s link there from openEHR.org national CKM page.

7

Here is our open source github repo for clinical decision support models, GitHub - openEHR/gdl-guideline-models: Common clinical models in the forms of openEHR archetypes and GDL guidelines, based on openEHR archetypes and GDL/GDL2 guidelines.

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.

8

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
1 Like
9

Looks good as a starting point for sure. Seems to be a great topic to follow up on the tooling SEC Working Group.

1 Like
10

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.

1 Like
11

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 :sweat_smile:

12

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’?

Any better suggestions?

13

Maybe a bit too formal, but what about openehr-knowledge-resources?

2 Likes