You might want to consider creating a new organisation, e.g. openEHR-models or similar, since you’ll probably want more than one repo. If you do it within the current openEHR org account, you might want to prefix the repo names with openEHR-models-xxx or similar. Otherwise it gets hard to find/see repos…!
Hi guys, I’d be keen to join this group.
I had quite a bit of experience in Anatomical Path domain and have developed an information system
Now I’m going part time with my day job so I have more time to work on areas I’m passionate about! I’d be delighted to contribute. @ian.mcnicoll can you please put me in contact with the group lead(s)?
Just thinking about how Github works, I’d suggest to create a new organisation:
short name: openEHR-CPB display name: openEHR International Clinical Program Board logos: create a modified form of the logo with openEHR CPB or similar (this needs to be done centrally)
In some creation step, one or more people can become owners (Sebastian Iancu and I are the owners of openEHR on Github). I’d suggest that the owners be long term actively involved people, Possibly Sebastian Garde would be a good default owner, plus a couple of other CPB members.
You can create CPB / CKM related teams as well and then connect those teams to repos in the usual way.
Potentially the CKM-mirror repo currently under openEHR would move to this new org.
Do we really need the extra overhead and confusion of yet another openEHR Github organisation? I am not sure we’ll need that many different repositories for clinical modeling, a handful is likely enough if we use branches within the repositories to separate workstreams. That’s how we do it in e.g. …
…where you right now find 11 branches for different modeling workstreams). When a workstream/subproject is finished, the templates and archetypes can be moved to a suitable subdirectory and merged back the main/master branch if we want to close the workstream-specific branch.
Not sure that moving the current CKM-mirror repo would b a good idea, since it is likely to cause unwanted/unexpected side effects for those that have included the current URLs in system setups. There are also many forks of CKM-mirror, but if I understand the info at Transferring a repository - GitHub Docs correctly, then the connections might survive an organisaation transfer.
I think we could start experimenting with shared pathology modeling in a branch and subdirectory of https://github.com/openEHR/Sandbox to figure out if that works, and then later move to a separate better named modeling project on Github (likely under the existing openEHR organisation).
…and put me (ErikSundvall) and @siljelb (siljelb) in both groups…
…and then give the clin_mod_admin team admin permission for the repository openEHR/Sandbox (not admin rights for the whole openEHR organisation - I don’t want to risk messing up CKM-mirror once again).
Then we’ll try to add more people to the groups and start experimenting.
I think it will depend on who owns the intellectual property of these models. If the IP will be held by openEHR, then using the openEHR GH organization seems OK.
Either way, when this group finishes modeling and wants to publish the models, if the international CKM is used, then those models will end up in the CKM mirror, so it’s not so important what’s the GH repo used for the modeling process, it could be your personal GH account.
I don’t think it should be more complicated than that. Though when someone wants to work on these models, I’m not sure if they will work from the CKM or from the original repos, since the revision versioning will be managed by the CKM once the models are published, so the original repo is kind of useless once the models get published for the first time, because if the original repo is used, you will end up with two separated shared managed environments: the original repo and the CKM, which IMHO is confusing.
I think the CKM (Ocean’s or any CKM out there) should work as our GitHub, and then use GH just as a mirror for convenience, since the CKM doesn’t have a CLI tool which would be wonderful (wink @sebastian.garde ).
I don’t know whether there is more confusion or overhead one way or the other. I guess the obvious path is to start within openEHR as it is today, and if it gets unwieldy, move the repos and teams to a new org.
I have completed the setup you requested in the following message (you should check it
Agree! The GitHub repositories should only work as preliminary repos to avoid “feral” archetypes. Also remember, for some institutions - my own included, there are limitations on from where it is allowed to access and download files. GitHub is a no-go from Oslo University Hospital. In order to secure transparency and avoid diverting duplicates, the international CKM should stay as the only source for shared archetypes, once they’ve been uploaded.
Just to clarify, the intention of the shared modeling area is to simplify collaboration using Archetype Designer when experimenting with templates and sometimes archetypes. This is not in any way an attempt to repace or circumvent the CKM. If new or improved archeetypes of international interest are produced they will go through the normal CKM processes of review rounds etc.
@thomas.beale thanks for creating the teams! I managed to add @ian.mcnicoll (freshehr) to the clin_mod_editor team (since he was already a member of the openEHR github organisaion. However as team “maintainer” role I was not allowed to add svdubois (see screenshot below) - he is considered an “external collaborator” since he is not yet a member of the openEHR Github organisation. Not qiute sure what the best way to handle that is in order to not wamp organisation owners - I’ll try to collect the Github IDs of the people involved in the patology modeling so that an organisation owner can add all at once.
Just to add to the idea, there are open source implementations of GIT that you can host in your own computer or on a cheap server online, which adds the possibility of controlling the whole thing plus having normal GIT CLI commands to manage the repos. The challenge would be to coordinate the GIT versioning with the CKM versioning. If that could be done, we would be able to work seamlessly with archetypes and other artifacts from the GUI or CLI.