On 21/06/2012 19:07, Gerard Freriks wrote:
So to summarise, it came down to finding categories on which /health
information data structures /- i.e. information models - could be
based that would work reliably for most if not all of medicine. Now,
having used these categories for some
Yes.
It all is about classifying.
It is all about proper definitions we all share and use.
I believe that when we all interpret the definitions in our own way in our own
data bases all is working nicely.
The moment we start to exchange this data we will discover that we are not
interoperable,
On 20/06/2012 20:30, Diego Bosc? wrote:
So you have to select the ITEM_STRUCTURE class but you don't have to
select the EVENT class? (most CKM archetypes have now EVENT and not
INTERVAL_EVENT or POINT_EVENT)
I think it should be allowed/forbidden following only one criteria.
*
*
in
Hi Thomas / Diego,
As far as the published archetypes are concerned we will have thought
fairly carefully about if and when to constrain EVENT to Point or
Interval, and this is definitely something that should be applied at
template level in most cases but, as ever, we have to be careful not
to
Hello Ian and everyone
Thank you for your response. (a) and (b) are clear but not towards what
the question is really about.
I wouldn't like this to drag on too much so maybe it's better if i
implement it the way i understand it and correct any errors afterwards.
All the best
Athanasios
Hi Thomas Ian,
I see what you mean, and I agree that in its current form
ITEM_STRUCTURE has no sense to be put and not restricted. Maybe there
are other cases where this is still valid (restrict the ENTRY class in
its current form I would say that it has no sense either, but maybe
CARE_ENTRY
On 21/06/2012 11:49, Diego Bosc? wrote:
Hi Thomas Ian,
I see what you mean, and I agree that in its current form
ITEM_STRUCTURE has no sense to be put and not restricted. Maybe there
are other cases where this is still valid (restrict the ENTRY class in
its current form I would say that it
On 21/06/2012 12:08, Thomas Beale wrote:
On 21/06/2012 11:49, Diego Bosc? wrote:
Hi Thomas Ian,
I see what you mean, and I agree that in its current form
ITEM_STRUCTURE has no sense to be put and not restricted. Maybe there
are other cases where this is still valid (restrict the ENTRY class
Let me try and clarify the time aspect of the ontology... the question
is not that time doesn't relate to all Entry types. The question is how.
In the Clinical Investigator Ontology Sam and I constructed, there are 3
temporal upper level categories
* history - i.e. information relating to
On 21/06/2012 17:08, Thomas Beale wrote:
Now consider the diagnosis archetype (an instance of the 'opinion' aka
'description' type)... it contains the main 'proposition' - i.e. the
identified index condition, diabetes or whatever - and a bunch of
times / dates / durations / other
Hi Anthanasios
I think time has shown that this is probably an area of over engineering
in openEHR. All archetypes are now ITEM_TREE and could be clusters.
If we think of these as providing constraint on an underlying cluster -
ITEM_LIST is a cluster of ELEMENTs and ITEM_TABLE sets up a set of
Hi Athanasios,
Just to back up what Sam has said, experience has shown that it is
best practice to model every top-level archetype structure as
ITEM_TREE to allow for maximum flexibility to develop the model in the
future without breaking backward compatibility, and as Sam has said
there appears
See openEHR 2.x RM candidates A-3 and A4 here
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model.
On 20/06/2012 11:50, Sam Heard wrote:
Hi Anthanasios
I think time has shown that this is probably an area of over
engineering in openEHR. All
Hello everyone
Thank you very much for your responses Sam Ian, they were helpful. In
any case the changes you describe do not seem to be reducing the
flexibility of the model. This definitely also helped me in clarifying
the use of ITEM_TABLE.
There is another part to that question though
Hi Athanasios,
a) The very first thing you have to do is to decide on the structure
and this is static. The archetyped definition sits within a sub-class
of item structure. So if I am creating a new Observation archetype and
want to add elements to 'data' I first have to decide which structure
to
So you have to select the ITEM_STRUCTURE class but you don't have to
select the EVENT class? (most CKM archetypes have now EVENT and not
INTERVAL_EVENT or POINT_EVENT)
I think it should be allowed/forbidden following only one criteria.
2012/6/20 Ian McNicoll Ian.McNicoll at oceaninformatics.com
Hello everyone
I am sending this email to clarify the role of ITEM_STRUCTURE in
relation to other structures (such as HISTORY and EVENT) both from the
point of view of EHR semantics as well as the computational view.
My problem in one line is that i can't understand if ITEM_STRUCTURE
are there
17 matches
Mail list logo
