Thomas
I am not sure that we need to do such a major rework. These samples are time
ordered but have no sensible time. So they could appear in the history list
without an offset, labelled in what ever way was helpful, recognising they
are part of the same measurement. On thinking about this (if
Thomas
My approach to this, which is expressed in the editor, is to standardise
only on the base and maximum values of the ordinal. The terms that are used
are not an issue and standardisation is really way beyond scope when people
use all sorts of terms for this purpose. Apgar is a classic -
Thomas
It is more that units match Force/Length^2 for pressure and it is an
expression that the property of pressure is the property of Force per
property of area - this does allow a very wide range of units to be used
if that is the requirement.
I am starting to see that things do get
Sam wrote:
Thomas
I am not sure that we need to do such a major rework. These samples are time
ordered but have no sensible time. So they could appear in the history list
without an offset, labelled in what ever way was helpful, recognising they
are part of the same measurement. On
Bhupinder
The only values we are not wanting to show are those that are wrong - and
have been changed in a later version. The idea behind this is to store the
information in an openEHR system inside the Pathology service and then send
an extract - rather than develop a lot of messages.
Cheers,
Vincent McCauley vincem at mccauleysoftware.com,
Hi Thomas,
The issue here is that Pathology labs will produce a numeric result for say
Potassium
but when it is high willl look at the specimen, decide it is haemolysed and
actually
report Haemolysed as the result. The Lab will store two
HI,
On one hand there is the notion as used in HL7 where series of messages
update databases producing a list of updated measurements.
On the other hand there is the notion as used in CEN/TC251 and OpenEHR
where documents are used to enhance the raw data by providing a human
interpretation and
Hi,
Only an attribute will not be enough.
It has to be accompanied by rules.
Information will be stored in various contexts and not always in the same
system. The same information will be stored in separate contexts.
A change in the status of the 'Lifecycle marker' in one machine will not
result
Bhupinder Singh bobdog at sancharnet.in
Hi Sam,
What yo usuggest is OK . But the issue is who is to decide what is right
and what is wrong. Should it not be the prerogative of the clinician.
There are situations where medical decisions are based upon results which
trigger clinical
I think there is a need for both superceded and exclude from automatic
processing.
Wherever the haemolysed marker ends up in the archetype/EHR it won't be
the only such beast.
Some other examples are clotted and clumped for full blood counts,
incorrectly collected (specimen in wrong type of tube
Vince
The notion of superceded applies to compositions and is inherent in the
versioning approach. Exclude from automatic processing is for entries.
Sam
-Original Message-
From: owner-openehr-technical at openehr.org
[mailto:owner-openehr-technical at openehr.org]On Behalf Of Vincent
11 matches
Mail list logo