On 31/03/2018 10:38, Philippe Ameline wrote:
...
When I try to explain all this to lesser tech-savvy people (means, who
don't belong to this list ;-) ), I usually explain that:
- usual systems (with an information schema tied to a database schema)
are like a printed form. The day after you received the 5000 printed
sheet you ordered, you will realize that there are several design
flaws that you will have to endure while the stock is not empty,
- openEHR is a flexible schema, similar to a set of stamps that lets
you build forms dynamically from blank paper. If your design has to
evolve, you just have to adapt one of the stamps.
- in my system, based on an ontology and a dependency grammar, you can
use stamps (archetypes like) and/or "write" freely.
just by means of clarification for some readers, since I happen to know
how both openEHR and Philippe's system works, here's the way to
understand how openEHR would perform the same function as Ligne-de-vie
(which it can):
* build a lot of CLUSTER archetypes, and probably more OBSERVATION
ones; each CLUSTER archetype would be one of the 'trees' Philippe
talks about
* each of those CLUSTER archetypes has slot nodes that indicate where
subordinate CLUSTER archetypes join, and which ones are allowed, in
the usual openEHR fashion;
o remember, a slot can allow multiple possible substitutions
* at run time, a form containing a top level Entry, usually an
OBSERVATION will be deployed on the screen, and by a process of user
choice / UI movements etc, the data will get filled in, and
subordinate CLUSTER archetypes will be chosen on the way, and filled
in along the way.
This mode of operation is known by us in openEHR-land as 'dynamic
slot-filling' or 'runtime templating', as opposed to the more typical
design-time templating used in a lot of systems, where most of the
choices are made prior to runtime. But openEHR systems do use runtime
slot-filling as well, e.g. for writing discharge summaries and
referrals, where the data items are only knowable in the encounter or
report-writing session.
I have always understood openEHR as a link, a step, between the "good
old way" (discourse range hard coded into a database schema) and a
modern approach where you can really "tell a patient story" using a
genuine (structured, processable) language. 15 years ago, Thomas and I
spent hours discussing the opportunity for openEHR to include a
reference ontology in its kernel ; this decision was not made for very
good reasons, but I guess that it still remains a necessary evolution.
see above - in the last 5+ years, much greater use has been made of
smaller CLUSTER archetypes, which perform the function of the fils
guides trees, but not as well, because the modellers don't use the LdV
modelling discipline at that fine-grained level. We should do that in
openEHR; it would require somewhat better features in some of the
modelling tools.
I actually think we should consider how to map the fils guides into
OBSERVATION and CLUSTER archetypes in openEHR, and also export out
archetypes into fils guides format.
Thomas very accurately explained why SNOMED is a deceptive candidate
for such a reference ontology. And, unfortunately, it is deep rooted
in its origins as a coding system. I can hear all the arguments about
"legacy system" and even "legacy medicine" (the one still fully
organized for siloed acute care at a time our society already entered
the information age and suffers from chronic diseases). The question
remains to guess if SNOMED is a component that lets you stuck in the
past or helps you disrupt the legacy craps.
Now, let's imagine a modern system that would allow you to "tell a
patient medical story" from the various viewpoints of a
multidisciplinary patient centered team. What would be the point about
having "local vocabulary subsets"? Do you think that a GP shouldn't
use the word "mitral leak" or any other "specialized" word in the
medical vocabulary?
My feeling is that selected subset is a solution when using SNOMED as
a coding system. The subset being the global list of values that are
legal for the fields in the existing schema, in the same way you will
select subsets in a billing system. But when it comes to "telling a
story" using a language, in my opinion subsets are a non-sense. We
don't use "vocabulary subsets" when we talk, and each contributor in a
patient's team would mechanically get exposed to a super-set; subset
is actually only fit for silos... and at a time when medicine is
already becoming a narrow silo in health, I really don't see it as a
sound strategy.
I mostly agree here, with one major exception: entering a diagnosis. In
that case, you do want subsets that are meaningful to your work context.
If it is paediatric oncology, you may have a form with a field that can
only be some kind of cancer or related Dx that that department deals
with - then you want reference terminology terms in a subset that cuts
out everything else. You also want your subset to be structured, i.e.
with the IS-A links intact, so that you can navigate it to choose.
But for a vast amount of other textual / ?coded? data, interface
vocabularies, or just plain old text are what is needed. WHere interface
terms are used, they should of course have a reference to a
post-coordinated expression in an appropriate underlying terminology.
-thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
