Dear colleagues,
The Weight archetype (openEHR-EHR-OBSERVATION.body_weight.v1) has completed a team review process and has been published in the Clinical Knowledge Manager today.
Reviews for its’ specialisations - Adjusted weight and Birth weight - will be initiated shortly.
As a reminder, the other archetypes that are currently in Team Review are:
Concept | Archetype ID |
- | - |
Blood Pressure
| openEHR-EHR-OBSERVATION.blood_pressure.v1 |
Height/Length
| openEHR-EHR-OBSERVATION.height.v1 |
Body Mass Index
| openEHR-EHR-OBSERVATION.body_mass_index.v1 |
Respirations
| openEHR-EHR-OBSERVATION.respirations.v1 |
Adverse Reaction
| openEHR-EHR-EVALUATION.adverse_reaction.v1
|
Microscopy findings - Melanoma
| openEHR-EHR-CLUSTER.melanoma_microscopy.v1 |
Microscopy findings - Prostatic cancer
| openEHR-EHR-CLUSTER.microscopy_prostate_carcinoma.v1 |
If you are interested in participating in any Team reviews please log in to CKM - www.openEHR.org/knowledge - and adopt the archetype to register your interest. At initiation of each review round all adoptors will be included as part of the review team and be sent instructions on how to participate. Instructions for adopting an archetype - see http://www.openehr.org/wiki/display/healthmod/Adopt+an+archetype
And finally, a reminder that the poll for selecting the next priority archetypes for CKM review is closing tomorrow - http://www.openehr.org/wiki/display/healthmod/Poll±+Top+10+archetypes+for+use+in+an+Emergency
Regards
Heather
The Weight archetype (openEHR-EHR-OBSERVATION.body_weight.v1) has completed
a team review process and has been published in the Clinical Knowledge
Manager today.
Thanks Heather - this is all excellent work and I'm really glad this is
all getting done.
I'd just like to note one small problem I have, which is that to be truly
'complete', these reviewed archetypes all need to have any
'included' archetypes also be reviewed. So I would contend that
body_temperature is not complete until
openEHR-EHR-CLUSTER.environmental_conditions.v1
openEHR-EHR-CLUSTER.exertion.v1
openEHR-EHR-CLUSTER.device.v1
have all also been reviewed, as these archetypes can be included
from body_temperature.
Is the intention that when it comes time to release the first
set of 'reviewed' archetypes, that it will included reviewed archetypes
for the whole transitive closure of archetypes referenced?
Andrew
I would suggest that there have to be two kinds of reviews; one is to review the ‘atoms’ (individual archetypes) so that at least that exercise is finite and limited. This is a bit like a software ‘unit test’ level. The kind of review you are talking about Andrew is a bit like a software integration test. At the moment I would imagine that the community is not quite ready for this to happen, or if it is, it needs to be treated as a second level review. Now, given that the ‘fan-out’ effect of archetype slots can create a combinatorial explosion of possibilities (each of which is a proto-template), I would imagine that this second level of reviewing needs to be limited to just some of those combination, or else it needs to take account of it in some way, without having to literally exhaustively review every such combination.
Andrew Patterson wrote:
(attachments)
Hello!
In our work on the laboratory report for Austria in the context of the
national EHR we noticed important missing details in the "atoms" as we
analysed the full context of the complete document.
I guess we therefore have to be aware that the "atoms" may frequently
have to be modified by reviews of the "combinations".
What I read from Andrews remark is another issue: Anything that goes
out must be reviewed as a complete "combination". This may not mean that
the atom needs to be reviewed, but that the way the atom is used in this
special combination is reviewed. The atom will often be restricted in a
combination. An expert group might best only review the combination that
they feel competent for. They will likely not be experts for the atom as
well.
We often found that a certain atom was not useful for the laboratory
report we were designing. We also felt that we were not the groupt that
should redesign and extend the atom (Telecom details within a "document
author" type of construct in a CDA lab report). In these cases we
approached the groups that were designing the atoms, and threw the
problem to them. We then received guidance and learned how to use the
atom right. Otherwise, if the atom developers found that we had hit a
new issue that nobody had taken into account in the atom design, the
atom was changed.
I guess archetype develoment will have to develop similar cooperations,
and get a distributed process going.
Just thinking.
Hope this helps, greetings from Vienna,
Stefan Sauermann
(will be on vacation soon now and be back next thursday)
Acting Program Director
Biomedical Engineering Sciences (Master)
University of Applied Sciences Technikum Wien
Hoechstaedtplatz 5, 1200 Vienna, Austria
Tel: +43(1)333 40 77 - 988
sauermann@technikum-wien.at
http://www.technikum-wien.at
Thomas Beale schrieb:
HI Andrew,
The CKM point of view is that the core content of the archetype as specified explicitly is ‘complete’ in this published archetype. In addition there are optional slots in which we can add further details pertaining to Environmental Conditions, Exertion and the Device, should we wish to include this information via additional reusable archetypes. The explicit content about Body Temp and the potential for additional information is what has been published.
The scope of the ‘potential information’ cannot be fully defined as the content of these optional cluster archetypes is not fixed and rigid according to this spec, only that there is capacity for these to be added if required. I can understand your point but this would only be achievable if these 3 clusters were the only archetypes that were permitted in those slots. In fact, any other cluster can be inserted at these points because the slots have not been constrained to only one specified archetype each. For example, specialisations of these 3 could be eminently sensible in these slots if some users had specific requirements. And there have been no exclusions specified for these slots, so it is even conceivable that in some (rare) situations a completely different cluster archetype may be required, including one out of CKM governance and with a completely different name - at least the parent containing the cord data spec is consistent.
Recently, in the CKM review, there is now functionality to open an archetype that has been specifically included in the slot - its purpose is to provide context for the reviewer to see the potential content here, but that is all, and other archetypes could potentially be inserted at that same point in a template.
So at review time we will endeavor to ensure that the archetypes and all the potential nested clusters are sensible. In effect this will be giving strong guidance by specifying recommended included clusters, but it would be going too far to be so rigid as to exclude all other clusters.
The intent of the first release set will be to build a cohesive set and error-free set of archetypes. At this point we could not guarantee that every archetype referenced will be included in that set. My personal opinion is that if one ‘minor’ cluster archetype was not ready for publication, I’d rather release a first set comprising all the Top 10, for example, with implementation notes stating the ones still pending etc, rather than hold them all back for another 3 months. The main thing is that whatever is released will be pragmatic and we will be as transparent as possible about issues arising; the community will be able to respond with their feedback.
Does this make sense? It’s trying to keep a balance between being pragmatic and giving some sensible guidance, without being too prescriptive to make the parent archetype unusable.
Regards
Heather
Does this make sense? It's trying to keep a balance between being pragmatic
and giving some sensible guidance, without being too prescriptive to make
the parent archetype unusable.
Yes, thanks Heather.
My concern is purely from the point of view of being able to deploy a
system 'creating' data for the archetypes - if there is not a
'reviewed' environmental
conditions, or exertion, or device then I would not feel comfortable
filling in that data in a BP instance in any real world system.
That said, I don't think it is an immediate problem because the scope of
this data is outside what is normally collected at point of care at
the moment.
So a pragmatic approach to completing the archetypes is fine by
me. A review giving guidance for use of recommended nested clusters is
also a good idea - it is exactly what is needed for limiting the
data scope of what my 'creating' systems are able to create.
Andrew