Heather, no doubt clinicians are necessary to design archetypes, the
have the domain knowledge.
But you mentioned in your WIKI also the word "implementable", and this
in connection to technicians, of course this is not a black and white
word, some concepts are better implementable then others.
What does "implementable" as a technical term mean?
I think it means, predictable paths, so data can be found by queries
without even knowing exact what one is looking for. For example, the
eye-colour example for a pregnant woman as Thomas gave. I changed it to
iris, because iris is not often registered, but there are clinicians
which think it is important. A vendor could create an iris-analyzing
device, and hand over an archetype with it to read out the data. That is
what we wish for for OpenEhr, isn't it?
It ain't going to happen tomorrow, but it could happen in the future.
So when querying the particularities of a pregnancy an eventually
irisscopy must be part of the result-set, even when no-one asked for it.
So the vendor I just mentioned should have has archetype modeled in a
way that it fits in the querying structure. This is a technical issue,
deciding if an iris is interesting is a clinical issue, but storing an
irisscopy in a way that it can/will be found, even when it is not
expected is a technical issue.
There must be a pattern imposed on the archetype structures which causes
that data can be found, and never become invisible.
It is not that I want make technicians to important, it is not my call
anyway. I am glad that clinicians can do most of the jobs, but to
optimize the implementable aspect of archetypes, we need technicians, I
hope that this example makes this clear. And it is not the only example,
there are other examples which to find ask for other structures.
Bert
On 16-02-18 00:20, Heather Leslie wrote:
Hi Bert,
Unfortunately pattern by itself won't result in good archetypes. Mind you, I
think the RM classes are brilliant and they have been the cornerstone for our
modelling experience. In fact I suspect that the lack of these classes is a
large part of the reason why other modelling paradigms such as CIMI have not
been able to progress as far and as fast they had wished.
Clinical medicine is messy, by definition. Our experience is that we often
identify patterns and then we routinely come across as many examples that break
those patterns. The slow progress that results is the result of refining those
patterns to work as universally as possible in the clinical scenarios and how
to deal with apparently outlying data points.
Then you need to consider clinical diversity that takes into account the range
of clinicians; differing professional requirements; differing professional
levels of details; needs of specialists vs generalists; clinical context;
institution and location; cultural differences; language differences; personal
health records; requirements for public health and research.... I could go on.
We need to identify what a concept is and the appropriate scope; ensure
minimising overlap as well as minimising gaps between concetps. Good archetype
design is just not as simple as what you yearn for, despite how logical it
seems to you. Our job would be much easier if it were so.
The only practical way forward is to start with good representations of
clinical data and then get broad review from ALL experts - to ensure that the
clinical data is fit for use as well as to ensure that they are implementable.
As CKM Editors we try to get developers involved in reviews but they are often
in the minority - not because they are not invited but mostly because they
don't respond. We have a large list of technicians who were part of the
companies who funded the original openEHR sprint. Some responded immediately
with 'Accept' just to try to accelerate the archetype to get a published state.
Most ignore the invitations to participate. DIPS engineers have been the most
consistent participants and many modifications in archetypes arose from their
participation in reviews - this has reflected their requirements for clinical
content as well as their suggestions regarding the technical implications of
the archetype design.
The adverse reaction archetype is a case in point - eventually we had 221
reviews from 92 individuals in 16 countries PLUS an unknown number of
participants from HL7 Patient care and FHIR communities. Health informaticians
and IT experts comprised at least a third of reviewers - engineer engagement to
this level is not our usual experience and if my memory is correct, most of the
technical input came from the HL7 community, not openEHR.
Patterns have been identified and more are being refined... but don't expect
them for all concepts, there will always be lots of unique models. Representing
data that real clinicians can use will not be solved by patterns alone.
Engaging clinicians is critical. Ontologies are useful but don't necessarily
cater for the entire reality that is clinical practice. Engineer review and
input would be much appreciated if it were available.
Why don't you agitate to get more engineers participating in the reviews? I
would gladly invite anyone who is willing to engage. Get them to adopt an
archetype today and join in the collective effort - the resulting archetypes
can only be better for everyone.
Regards Heather
-----Original Message-----
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On
Behalf Of Bert Verhees
Sent: Friday, 16 February 2018 2:41 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Archetype pattern
An interesting wiki from Heather Leslie
https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns
She concludes that pattern are necessary, I agree with that, and she also
concludes that clinicians are better modelers then technicians.
Well, that depends, of course it is very important to have domain-knowledge
when modeling data, and clinicians have the best domain-knowledge. So from that
point of view, she is right.
But what we have seen until now is that clinicians create archetypes with
unpredictable paths. And that is bad, because it makes it very difficult to
find data and it makes it easy to miss important data, because some data were
on a path where one did not expect them.
OpenEhr works fine to find data which are on a known or predictable path, but
what if data are on an unknown path?
Let me explain by comparing this to a classical relational health-application.
There are similarities.
I have seen classical relational systems which experienced a wild-grow in
number of tables, I have seen once in a prestigious university-hospital where
they had a grown of 7000 tables in 20 years, more then one per day!! No one
understood the meaning of all the tables and data, no one dared to use data he
did not understand, many data were and still are redundant. Every new
development in the ICT starts with designing new tables.
How can in such a situation a clinician research a persons medical record, even
with the help of the current technical staff, this is often impossible. So,
important information can get lost. Adding to this are software-updates which
often cause a clean-up, and that clean-up is also done by people who do not
always know what they clean up. People live long, and a medical problem they
had 30 years ago can be important to find to solve a current problem. So old
data, and understand them, and be able to find them, can be important.
This can also happen with archetypes. Every new development in a application
can start with a new archetype, and at a moment there can be thousands. It is
impossible for a clinician to search all possible paths for medical
information, even with the help of the current technical staff this can be
impossible.
The old data-hell situation will not be solved by OpenEhr if there is not
something behind it. And that something, that is: PATTERN
It is not only a clinical thing to understand how pattern in paths are best
modeled, it is in fact also a technical thing. Clinical knowledge is not
stable, the thinking about clinical facts change all the time, what now is
important is tomorrow maybe not. So the pattern need a technical, mathematical
base, that, something like Codd-normalization, but of course then applicable to
archetypes.
The Wiki from Heather Leslie is a good starting point for the design of pattern
and stop the proliferation of paths.
I described an approach to solve this problem in a blog, one and a half year
ago.
http://www.bertverhees.nl/openehr/medical-data-context/
I had some discussion about that, but many had problems against the use of
SNOMED in this context. So, maybe read it and forget SNOMED ad find something
else to structure the medical data.
Bert
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
