As a CKA, I often feel I operate in a vacuum and it is only by accident that I find out about decisions made by the specs community or updates to the modelling tools I use.
One of the benefits that we promote about openEHR is that clinicians are able to participate in building the archetypes, while the software engineers focus on the specs. And while that separation works well to a point, what both technical and clinical groups miss out on is the richness that comes from active and deliberate cross-pollination to refine and provide nuance to each otherās work. We still operate in isolated professional silos rather than bringing this expertise together to collectively solve the challenges.
How can the specs evolve to solve clinical modelling issues without engagement and practical input from experienced clinical modellers?
How can we engage more software engineers and implementers to review archetypes from a technical POV to ensure appropriate technical representation?
There is currently zero collaboration about specifications priorities that involve the clinical modelling program and CKAs. Iām not suggesting that this should slow the specs dev process at all, rather it could/should make it more efficient at the same time as actively supporting the work of CKAs.
There is also no opportunity for collaborating on tooling priorities, especially where it impacts blockers to the modelling program and archetype representation, apart from registering a change request and waiting.
Iād love to discuss how we can work more collaboratively together. This would benefit the entire community.
Itās not quite as bad as that, not that we couldnāt improve cross-pollination. But just as a matter of current practice:
we have always endeavoured to have at least one clinical professional +/- modelling person on the Specs committee. In the past it was @Sam and Dipak, these days we have @ian.mcnicoll (MD), @rong.chen (MD), @bna (physiotherapist), and @ShinjiKobayashi (MD). We get a lot of clinical input from Ian and Bjorn particularly, also from Rong on CDS-related issues which drives changes to the specs.
some of us on the SEC (at least me, Ian, ? @yampeku , @sebastian.garde but I think others) plus others e.g. @borut.fabjan monitor the clinical topics on Discourse sufficiently well to catch a fair bit of needs being exposed in the discussions. We have obtained pretty much all the recent terminology / archetype related specification changes this way in recent times.
a certain amount of clinical questions from you / @siljelb / others are posted or linked to the Discourse specification groups, which causes more of us to see requests (e.g. Siljeās various archetype terminology questions in the last year).
developers of modelling tools, including Better (AD), Ocean (CKM, AE, TD), Veratech (LinkEHR), Nedap (Archie ADL libs) all monitor feedback from clinical users which provides a fairly constant stream of interesting questions for ADL and/or the reference model.
we have had more focussed input as well, which has been very useful:
@joostholslag (MD) from Nedap has been providing excellent general review of openEHR from a clinical point of view, plus a new point of view on various clinical speciality areas
@ian.mcnicoll over the long term, also @bna in more recent years, have acted as a source of specific requirements relating to e.g. problem lists (master problem list, other PLs, nursing PLs, etc), āviewsā, reports, how to think about order tracking, how terminology works in FHIR, and much else. Indeed, in the SEC meeting we just had in Berlin, we had a topic called āIanās thingsā which is everything to do with making AQL and terminology easier to use in openEHR.
we obviously get sporadic posts / discussions from clinical people which always teach us something, e.g. the long discussions on the POMR.
Iāve undoubtedly missed someone here - apologies, just working from memoryā¦!
The above is pretty informal, but I think we get a reasonable amount of insight current clinical needs this way. Itās somewhat random of course - depending as it does on what happens to be currently important to Norway, Nedap, Shinjiās group, CDS, Australian orgs or whatever other driver.
In recent times, the following kinds of spec changes have come from clinical sources:
Archetype Model
a number of changes to do with terminology sub-set representation in archetypes, including the FHIR āconstraint strengthā
default value specification in archetypes
negative durations (one of yours I think!)
rm-visibility in templates
Reference Model
added DV_SCALE to handle non-integer score values
added āepisodicā type to COMPOSITION.category
added CODE_PHRASE.preferred_term field
added ability to represent units other than UCUM in DV_QUANTITY
changes to better accommodate ādraftā clinical content
negative durations.
Task Planning was to answer needs for better representing planned medication administration e.g. chemo; long-running routine patient management, e.g. diabetes and many other scenarios, many provided by clinical people from DIPS, and working with or at Better.
You can easily find these change lists by clicking on any release in the right hand column of the specifications home page, e.g. in the RM block, ā1.1.0ā over on the right hand side (example). Then click on āChanges Implementedā just under the graphic (example).
It is probably worth mentioning that we in the specifications group make pretty much all changes these days in response to user / industry needs, rather than from internal drivers.
I donāt actually disagree with the sense of your criticism, but I think the above shows that we are doing better than one might think, if one were to look at just planned / official interactions (e.g. specific workshops or whatever).
What could we do better? Some thoughts:
the #1 thing Iād like to see is a managed list of all currently unmet clinical requirements (aka ācurrent clinical pain pointsā), of whatever size, that a combined group could review (twice a year?) and better plan work priorities for us in the specifications camp. We only have scattered representation of these needs today.
agree on tooling priorities. Iād rather see a roadmap developed and reviewed every (say) 6 months by a dedicated meeting / summit / workshop of tooling developers + clinical and other users
we could potentially have more clinical people on specific SEC calls, but weād have to change the way the call works - probably based around a presentation of some specific clinical need off the pain points list that we could think about in terms of specs. Most SEC calls are pretty dry and are often about pure IT questions like representation of some data type or AQL paths or whatever.
we could mark Problem Reports (PRs) and Change Requests (CRs) in Jira as āneeding clinical inputā or similar, and then use a query to generate a list of things we want clinical people to look at.
Iām sure there are many better suggestions available.
I think at the end of the day the specifications group needs to work off two lists:
requirements from clinical users & healthcare orgs - tend to be more semantic elements of RM or terminology
requirements from solution / tool vendors - tend to be technical tweaks to all specs
Currently Iād say we have a stronger connection to the latter, which we need to address.
Just to clarify the clinical connection to some potential readers: I believe @bna is a physiotherapist and the other three mentioned are physicians/doctors.
So at least four SEC members have clinical background, and several others of us do work with openEHR based software in practice in actual clinical projects or settings.
That said, e.g. prioritsed lists and dedicated shared meetings related to processing them as suggested by @thomas.beale above would be an improvement.
This is an important point. In addition to taking part in reviews I believe it is important that software engineers and implementers do raise change requests to archetypes when spotting things that can easily be misunderstood by tech-people or that they do request changes that make implementation easier or more maintainable.
Here is a picture to techies, use the icon marked in red to submit change requests at https://ckm.openehr.org/
My point was actually to get the leaders of the programs and tooling vendors together - to coordinate efforts for the benefit of the community.
It makes it hard for me to fulfil my leadership role as CKA without understanding what else is happening in the technical program or tooling.
@sebastian.iancu, @siljelb and I have met once before, about 12 months ago now, and we agreed it was helpful to continue. This is my attempt to raise this again and potentially include others who are interested in joining us, including Editors from a modelling perspective. For example - how do Editors learn there is a new Scale data type, why it has been added and how it is intended for use?
well the releases are published and announced and itās ārelativelyā easy (haha) to find the list of changes from the specs home page.
But what we probably should be doing is to publish a list of āclinically meaningfulā changes, which is a subset of all changes, in some easier to understand list. I think we could probably get close to this by tagging such CRs and building a report definition to generate this list. Iāll have a look at that.
I would think the idea of a cross-program meeting would mainly focus on more strategic priorities? We did think about how to run an openEHR working meeting, but then Covid cameā¦
The agenda for a cross-program meeting should/could reflect any/all issues and priorities relevant at the time. It should involve priority setting but I suspect that it could provide a lot more benefits than that, including planning a broader working meeting.
At the moment there is no strategic cross-pollination nor sense of us all working together as a team. Iād like to see this improve.
There are some things I donāt understand here. I do understand that regular strategic shared meetings would be good and an improvment, but I donāt quite understand the reasons for some of the rather strong wording in parts of some posts above. Is not @ian.mcnicoll part of the clinical modeling program somehow? Is the Clinical Modelling Editorial Group (CMEG) Members list not up to date? Does the group communicate internally on a somewhat regular basis? He certainly regularly brings a lot of clinical questions and modelling issues into the technical specification program via the Specifications Editorial Committee (SEC) where is also a member.
Many members of the SEC watch the news section of the CKM dashboard and take part in discussions here in discourse - if we, as @thomas.beale suggested above filter out what we beleive are changes of clinical interest, do you then think it would be possible for members of the clinical program to actively watch that kind of ānewsā feed in the same way many techies watch the CKM news?
Only Silje and I meet weekly as CKAs to coordinate what goes on in CKM - this has been our practice for years. I reiterate, there is no formal representation from the clinical modelling program or the active CKAs to the specifications program.
Honestly, Iām surprised and embarrassed that there is such strong pushback and that this idea is not a welcome opportunity for information & idea exchange, both ways.
Intersting surprises for both of us, based on the web I thought that Ian was deeper in the official clinical modelling loop.
I believe your suggestion of more collaboration meetings has been welcomed above - no pushback regarding that suggestion. The pushback I can sense is regarding the (possibly misread) implications that there currently would be no clinical input whatsoever to the technical SEC work.
Ok, so letās fix all this somehow rather sooner than later, can you, @siljelb, @thomas.beale and @sebastian.iancu discuss how to set up regular meetings between the programs?
A remaining question:
ā¦or is there a public backlog/todo-list or similar?
CKM is used as the source of truth - change requests & discussion are the public mechanism for community participation and accountability back to the community.
Discourse is increasingly being used for discussions
Regular editors most often meet weekly and are slowly getting used to using a Jira instance to track the CRs and coordinate distributed & asynchronous Editorial activity, but itās not particularly helpful for general consumption.
the #1 thing Iād like to see is a managed list of all currently unmet clinical requirements (aka ācurrent clinical pain pointsā), of whatever size, that a combined group could review (twice a year?) and better plan work priorities for us in the specifications camp. We only have scattered representation of these needs today.
@heather.leslie, great, then we can contiue to monitor CKM and discourse! (In addition to future meetings that I hope the program leads set up for us all.)
@thomas.beale, if there is no person overlap between the groups (as I erraneously thought) I think weāll need to meet in some form(s) more often than twice a year, even though major reviews of strategic roadmap could probably happen around twice a year or at whatever interval is agreed on.
TBH I am as surprised as everyone else to be on the CMEG web page since as Heather and Silje have indicated, I have had no formal role in the Clinical program for some time. I think that is just a historical misunderstanding when the site was being setup. I think I have access rights to take my name off that page.
There have been communications via the various JIRA CRs but I agree with Heather and Silje that a more regular, formal engagement with the Clinical group and SEC would be helpful.
I agree - meeting more often in some kind of way could be very useful. To ensure the technical people know the problems and requirements from the clinical modellers, to ensure the modellers know of any newly released features in specifications, and to help tooling developers schedule to prioritise the most important features form a modellers standpoint. Two times a year sounds very limited to me for these purposes.
Or, perhaps we could actually create some form of overlap between the groups by adding someone to the SEC, as a member, or as an expert, just like we have technical experts? This will probably consume some extra time and effort, from the modellers because extra meetings/tasks, and possibly from the technical people because they may have to spend some extra time to explain the more technical issues. But that could very well be worth the time and effort.
We could, although we have four clinical professionals already - Ian, Bjorn, Rong and Shinji. I think what is really needed is a better view of needs from the clinical modelling program, rather than more access to clinicians per se.
As I have mentioned already if we could see a consolidated list of current requirements from the CMG it would be very helpful indeed.
In my experience, a list of requirements, although very useful, is not at all the same thing as discussing these requirements with the people who actually need them. I know for example there have been requests for nested value sets, but I do not know the reasons behind this need. Interaction and discussion could help to achieve a much better solution and prioritization.
The overlap is just one way of doing that of course, many other ways are possible.
Agree on that - to solve that we probably need is better access to people / orgs generating requirements which tend to be a) vendor projects with HC provider orgs looking at specific things, and b) large jurisdictions doing major areas of medicine, e.g. obstetrics.
I am not at all against adding another clinical person to the SEC, but I suspect it wonāt help us as much as some kind of forum in which we can connect to as many of these projects as possible.
