A clinical modelling conversation...
sam.heard at oceaninformatics.com
Mon Aug 20 00:18:43 EDT 2018
The value and use of structured data in health care has long been debated:
openEHR allows for arbitrary levels of structuring and reuse. Many of the
larger companies, due to commitment to database technologies, and AI
proponents arguing for natural language processing and fuzzy indexing. There
is little evidence either way, but it is clear to me that structuring is the
easier and safer way (certainly for the foreseeable future). I have seen
very little advance in systems over my career, and most that has come has
been as a result of detailed information being captured and stored in a
Given our community's buy-in to the pro-structure approach, Heather and
Silje have some valid proposals for us all. Anyone involved can see the
advantage to quick turn arounds sharing development over a large pool of
interested parties. It is not so obvious to others, who enjoy the quarterly
gatherings and the narrow set of demands that arise from a (very) few people
in a room. However, rather than take national program objectives as our
driving force (which it has often been), I think we should add a layer to
the debate; that is, how do we prioritise efforts to agree on data
structure. The positive outcomes (health, process, reporting) that arise
from having data structured would appear to be important. I have been
working on Microbiology results lately and reporting around these results.
The aggregated reporting that is possible is really limited only by the
structure of the data, not just in microbiology but all the patient,
medication and logistic factors you want to report against. Adding one
element to one aspect of the data can massively affect the power of
reporting for instance.
High fidelity data is often critical in providing patient care in ways that
are difficult to foresee and which are implemented differently all over the
place. Hepatitis B infectivity and immunity is a current example of this for
me. Results of lab tests need to be structured, as do vaccination data and
time processed to see what is going on. This is relatively easy for a
hepatic specialist, but very difficult for a generalist without good records
and reports. It probably warrants a small case study. I raise this because
we could raise particular scenarios as priority areas of work rather than
Other examples I have come across are exposure to and treatment of syphilis
and managing advanced Kidney Disease. Are there common areas of process that
struggle without good data? What are the scale of these process, do they
required shared care to be effective? How many of these exist. Antenatal
care is another example but efforts to describe this as workflow have been
particularly unsuccessful - do we need AI and highly structured data?
I am interested in other people's ideas.
From: openEHR-clinical <openehr-clinical-bounces at lists.openehr.org> On
Behalf Of Thomas Beale
Sent: Thursday, 16 August 2018 9:11 PM
To: openehr-clinical at lists.openehr.org
Subject: Re: A clinical modelling conversation...
A few thoughts come to mind:
* sets of archetypes could potentially be developed closer to
completion by the grass-roots level, before submission to CKM, which would
reduce editorial time, if better guidelines on development rules, patterns,
etc i.e. the fabled handbook existed
* consider a set such as for ante-natal care + birth + post-natal (6
weeks) - there might be 50 archetypes implicated here, with (we hope) at
least half being generic (e.g. lab tests used in pregnancy are mostly not
unique to pregnancy) - there is a lot of work here.
* It might be a better approach if development teams were to try to
develop whole packages to a reasonable level, rather than just submitting
single archetypes and wait for results of review
* whole package generally would be based on some process, care pathway
etc, not just a data-oriented view. E.g. pregnancy; chemo+ monitoring; etc
* if the fabled handbook of patterns and criteria for good archetypes
existed, more editors could be trained.
* is there any reason not to have just more people on the editorial
group, e.g. 10?
* is it time to agree a set of major clinical sub-specialties (< 20)
and designate an owner for each one (i.e. an editor; some editors could own
more than one area)?
* we possibly need to distinguish two layers of archetypes, which
would potentially change how editorial work is done:
* generic all-of-medicine archetypes:
* vital signs
* many signs and symptoms
* a reasonable number of labs
* general purpose assessment / evaluations, i.e. Dx, problem
description etc, many things like lifestyle, substance use
* ?all of the persistent managed list types: medications, allergies,
problem list, family history, social situation, consents, etc
* the specialties, for each:
* specific signs and symptoms
* specific physical exam
* specific labs
* specific plans
* more than one relationship between specialty archetypes and generic
ones is possible, e.g. some are just new; some are formal specialisations in
the ADL sense.
My guess is there is a number of issues to consider. Whether any of the
above are the main ones I don't know.
On 03/07/2018 08:41, Heather Leslie wrote:
This email is jointly sent by the openEHR Clinical Knowledge Administrators,
Silje and Heather.
Following recent email threads, we would like to establish some common
understanding and expectations about the current clinical modelling effort
and effect that we hope might stimulate a constructive and innovative
conversation within the openEHR community about moving the clinical
modelling work forward.
Let's say that publication of a typical archetype takes four review rounds.
Each review round runs for 2 weeks. If we had dedicated Editors who can turn
those archetype reviews around immediately then we can take a draft
archetype and publish it 8 weeks later. The reality is that there will be
some lag times so the reality might be closer to 10 or 12 weeks, but we're
not talking 6 months or years.
Let's also say that the typical Editorial time for each review round is 3
hours - an hour for an Editor to do the editing and one hour each for two
Editors to facilitate the comments. So let's add in one hour preparing an
archetype for a review round and we have a total of 13 hours editorial time
per archetype. Simpler archetypes and well-known scales or scores can be
published in one or two review rounds. More complex ones like the adverse
reaction archetype has taken tens of hours, possibly closer to a hundred,
but worth the effort to get it right because of its importance in clinical
safety. However we're not talking unsustainable hours per archetype to get
the majority published.
Within the typical standards environment where review of information models
are done en masse in 3, 6 or 12 month cycles, our agile and dynamic approach
to archetype review and publication is outrageously fast and requires only a
modest budget. And the priorities can be driven by the implementer
We really need a different conversation happening about the archetype
development process, one that recognises the efficient and value for money
that we have put in place but is largely untapped, rather than complaining
that the work to date is not complete enough, not focused on the right
topics, not <insert whatever you like here> enough.
The practical reality is that by far the majority of the Editorial work is
not resourced, so there is a limited strategic plan apart from the Archetype
'Sprint'. Rather that the work is largely opportunistic:
* dependent on archetypes that are volunteered as a result of real
* translations by those reusing archetypes in different geographical
* reviews occurring when people ask and then volunteer to participate
in the process.
The Norwegian Nasjonal IKT work is a perfect example of this - so many of
the archetypes published in the international CKM in the past couple of
years are the direct result of the Norwegian priorities for content, driven
and facilitated by the Norwegian Editors but with enormous value contributed
by international input. Nasjonal IKT have effectively funded the majority of
this work to support their national program, gaining the enormous benefit of
international collaboration and input, and in return making available high
quality archetypes for the rest of the international openEHR, and broader,
community. They recognise this as a win-win situation.
The source of most of the limited funding that has recently been made
available for editorial work in the international CKM is Norway's Nasjonal
IKT membership fees, which have been deliberately directed toward the
international clinical modelling effort on request from Nasjonal IKT. A few
hours a week of dedicated editorial time has already increased the
international CKM activity manyfold in recent months. This includes timely
responsiveness to community requests and contributions, for the very first
time. It would be exciting to see this grow and expand through member
organisations joining and specifically allocating some of their fees towards
the clinical modelling effort.
With only modest, strategic resourcing, the collective benefit will be
orders of magnitude larger than any single organisation can achieve by
itself. The impact of this can extend way beyond the openEHR international
community but to other standards organisations and digital health in the
Silje Ljosland Bakke and Heather Leslie
Clinical Knowledge Administrators for the openEHR CKM
Dr Heather Leslie
MB BS, FRACGP, FACHI, GAICD
M +61 418 966 670
Twitter: @atomicainfo, @clinicalmodels & @omowizard
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
<mailto:openEHR-clinical at lists.openehr.org>
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare
Management Board, Specifications Program Lead, openEHR Foundation
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7056 bytes
Desc: not available
More information about the openEHR-clinical