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.