harmonization CR regarding CLUSTER/TABLE etc and
ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi!
I now noticed that my message with the pencil-modified UML diagram
bounced four days ago because of attachment size. Now it's edited
below to only include link to the image
http
Hi Zam! :-)
I was merely trying to keep most of the same semantic power in the
change suggestion as when the abstract ITEM_STRUCTURE (that subsumed
ITEM_SINGLE, ITEM_TREE etc) was used rather than ITEM_TREE in various
places in the RM model. But you might be completely correct that it
would be
On 13/11/2010 00:07, pablo pazos wrote:
Hi,
I would also concur with your statements about the ENTRY sub
types, as Sam mentioned we have built an INSTRUCTION index that
tracks the current state/care flow step of instructions and their
associated ACTIONs providing efficient
Hi!
I now noticed that my message with the pencil-modified UML diagram
bounced four days ago because of attachment size. Now it's edited
below to only include link to the image
http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg
After that mail was written Heath indicated that one of Tom's
] On Behalf Of Erik Sundvall
Sent: Wednesday, 10 November 2010 11:16 PM
To: For openEHR technical discussions
Subject: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and
ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hello again!
Here comes a more complete version
In a message dated 10-11-2010 8:41:09 W. Europe Standard Time,
hugh.leslie at oceaninformatics.com writes:
Hi William
I didn't see anyone say that the hl7 models have been developed without
clinical input. I am certain this isn't true.
I don't completely agree with you about the
Hi Ed,
I am a mouse that roars (sometimes) :-)
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
On 11/11/2010 23:14, Heath Frankel wrote:
Hi Erik,
Interestingly, this is the same proposal I put to Thomas about 8 years
ago and I go the same response. I do understand his rationale for
making a table a class rather than an attribute with additional
conformance statements to ensure a
Hi,
I would also concur with your statements about
the ENTRY sub
types, as Sam mentioned we have built an INSTRUCTION index
that tracks the current
state/care flow step of instructions and their associated
ACTIONs providing
I like it I hope others help me build my menangre.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Williamtfgoossen@
cs.com
regarding CLUSTER/TABLE etc
and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi!
On Wed, Nov 10, 2010 at 17:26, tom.seabury at nhs.net wrote:
My simple reading of this is that what are currently trees would
instead be
expressed as a sparsely populated arrays
You can find here the related work to this problem from our colleagues at
the University of Murcia.
An approach for the semantic interoperability of ISO EN 13606 and OpenEHR
archetypes.
Catalina Mart?nez-Costa, Marcos Men?rguez Tortosa, Jesualdo Tom?s
Fern?ndez-Breis
Journal of Biomedical
On Thu, 2010-11-11 at 08:52 +0930, Sam Heard wrote:
We have learned a lot over the past few years - but I am a practicing
clinician and the following should be read with that in mind!
While a lot has been learned. The universe of people actually
developing archetypes is rather small when
On 11/11/2010 12:32, Tim Cook wrote:
As far as the comment about the ENTRY sub-classes intruding on the
ontological space. They do not intrude, that is a point of intersection
where one represents knowledge and the other gives it structure. Both
are a requirement for interoperability.
well
Hi William
I didn't see anyone say that the hl7 models have been developed without
clinical input. I am certain this isn't true.
I don't completely agree with you about the ease of accessibility for
clinicians of UML models and MIF models - it's not our experience.
Regards Hugh
Sent
Hi!
I hope you don't mind breaking out a side thread with a concrete
harmonisation sugestion. First an openEHR change request, then an ISO 13606
change request.
1.
Regarding ITEM_TABLE (and the other classes in the openEHR item_structure
package) there was a change request from Sam that went
Oops, I intended to push the save-button, not the send-button on that last
message. Now we'll just have to make a fire, shovel some snow, milk our
goats, say good morning to cat and chickens, fix a leaking car tire, get
kids to school and myself and my wife to work before I can continue writing.
Hello again!
Here comes a more complete version of the mail I happened to send unfinished
this morning.
I hope you don't mind me breaking out a side thread with concrete
harmonisation suggestions. First an openEHR change request (CR), then an ISO
13606 change request.
1. item_structure (openEHR
technical discussions
Subject: Re: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and
ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Tom, did I really express myself in such an unclear way or did you not read
properly? Or did you respond to the wrong thread somehow? Perhaps
On 10/11/2010 16:16, Erik Sundvall wrote:
Tom, did I really express myself in such an unclear way or did you not
read properly? Or did you respond to the wrong thread somehow? Perhaps
i misinterpret your tone and arguments so please clarify if you have
problems with the following:
Audiogram, reflexes and vision results are sometimes recorded and
displayed in two-column tables in clinical settings. There is an
audiogram Observation archetype on CKM at Audiogram result
http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.44 -
this does not use a table
Just for info the only current example of a CKM archetype which uses
ITEM_TABLE is
Tendon and Babinski reflexes
http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.256_1
and the Audiogram example in Thomas's link shows exactly why
ITEM_TABLE in an archetype root is unhelpful, since
Hi!
On Wed, Nov 10, 2010 at 17:26, tom.seabury at nhs.net wrote:
My simple reading of this is that what are currently trees would instead be
expressed as a sparsely populated arrays ? is that the point?
Just to clarify it is has not already been clarified enough by others:
Everything that is
hi All
A roll up of comments:
1. ISO 21090 is often (always?) profiled
It seems remarkable to me that people think it's a problem that ISO 21090
needs to be profiled. Who would've guessed that a full standard that meets
many requirements is simpler to implement if you profile out the features
21090 data types too complex?
hi All
A roll up of comments:
1. ISO 21090 is often (always?) profiled
It seems remarkable to me that people think it's a problem that ISO
21090
needs to be profiled. Who would've guessed that a full standard that
meets
many requirements is simpler
hi Tom
The only kind of 'profile' I know of elsewhere in other standards is of
the kind 'we only implement x, y but not z'.
which is the kind I'm talking about
The answers Grahame gave me last time I discussed how to profile
21090 for 13606 use are here, about half-way down.
rather
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101109/e630e31e/attachment.html
Reading your post I have remembered something I have read sometimes
but I haven't still gotten a satisfactory answer:
If UML and ADL are that similar, why don't we use both? What does UML
can express that ADL can not express that makes some people to dislike
it (and also what can ADL express that
Regarding Cluster, there is a code to tell if a cluster is a table or
a list, so the computer always knows which one was chosen
2010/11/9 Hugh Leslie hugh.leslie at oceaninformatics.com:
Hi Andrew
I'm happy to continue to have this discussion with you.? I still am not sure
whether your
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101109/a0b3c13d/attachment.html
www.zorginformatiemodel.nl is available since about 2005.
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
As an ISO standard, I believe that it should be an intersection of
all the
input specifications, rather than a union
extension has it's own difficulties, as does union. We were aware of
the
berlin decision, but ISO 21090 resulted from a deliberate decision
to do something different. Was
which is more likely to be used out of the box?
intersection, or union?
Union at least has everything
Grahame
On Tue, Nov 9, 2010 at 7:14 PM, Heath Frankel
heath.frankel at oceaninformatics.com wrote:
As an ISO standard, I believe that it should be an intersection of
all the
input
On 09/11/2010 00:37, Grahame Grieve wrote:
There is no escaping from the fact that having a type called 'Any'
representing a concept that should be called something like 'AnyDataValue'
(in openEHR it is DV_ANY) is annoying and has to be dealt with in some way.
really? You've not heard of
Hi Diego,
it has never been said that ADL is intended to be any kind of
replacement of UML. Instead it relies on the UML object meta-model, and
defines a constraint formalism on top of it. This allows you to define a
static class model in the normal way, e.g. in a UML tool or whatever,
and
On 09/11/2010 05:54, Williamtfgoossen at cs.com wrote:
They (the clinical models in HL7 v3 R-MIM format) are all part of
extensive clinician input and review, sorry clinicians do understand
the modeling in HL7 space, but indeed like any other modeling effort,
need some education first.
Hi All,
I think this is a good intelectual interchange, but I really don't know what
conclussions will reach.
From outside I see people comparing positions and opinions, instead of
searching some common point of harmonization. Instead we talk about formats
and ways of modeling (it's like the
Pablo
I agree that this is a good intellectual exchange. I also agree that
the delight and interest in finding differences exemplified in this
discussion sometimes obscures the substantial amount of (very similar)
utility that these various elephants provide.
I have confidence that the ants can
I always thought of myself as a jackass.
Perhaps other animals will declare themselves.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Charles McCay
Hi Charlie,
Alongside that I would say that these architectural and process
discussions are valuable - There is nothing so practical as a good
theory [1] -- interestingly Kurt Lewin was as interested in how to
find good theories, as in maintaining a productive balance between
theory and
Have a look at ISO 11404, it is an intersection (datetime is defined
elsewhere ) and every programming language, database system and
serialisation format uses it and extends it as required.
On 09/11/2010 7:13 PM, Grahame Grieve grahame at kestral.com.au wrote:
which is more likely to be used
I second that!!
Carol
Dra Carola Hullin Lucay Cossio
Presidente of IMIA-LAC
PhD Health Informatics
www.imia-lac.net
+5628979701 Chile
From: s...@vivici.nl
Subject: Re: ISO 21090 data types too complex?
Date: Sun, 7 Nov 2010 14:53:04 +0100
To: openehr-technical at openehr.org
Stef et al,
In response to Stef's plea for others' opinions, I'd like to add my voice to
Tom's concerns.
I certainly believe that the whole ISO process with respect to health
informatics standards is deeply flawed. As Grahame implies with the datatypes
standard, the process is politically
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/ee957113/attachment.html
I see a kind of cooperation emerging here, which is fine and what I like
most.
Eric points at one are that has my particular interest since I started to
represent such assessment scales in HL7 v3 space in 2002. We where using the
existing HL7 R1 datatypes then and found that for the
William,
I follow most of your posting, and I agree that much of the modelling of the
concepts you describe can be done independently of an implementation context.
[There is, of course, the question of tools that best help with this.] I
think, in many instances, you are seeking agreement on
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/ea79d47f/attachment.html
Andrew,
I agree that there can be value in producing lower common denominator artefacts
for short term implementation gains. I don't, however, see why we can't aim to
gain agreement on more specifically defined artefacts as the basis for clinical
models, and then, as you suggest, provide
of IMIA-LAC
PhD Health Informatics
www.imia-lac.net
+5628979701 Chile
From: stef at vivici.nl
Subject: Re: ISO 21090 data types too complex?
Date: Sun, 7 Nov 2010 14:53:04 +0100
To: openehr-technical at openehr.org
It looks like we're getting
On Mon, 2010-11-08 at 08:45 -0500, William E Hammond wrote:
I would like to see some real proposals to try to provide simpler, workable
global solutions. It's like World Peace - a great idea but probably not
achievable.
I think that pretty much sums up the situation. :-)
Cheers,
Tim
I want to pick up on a few points here...
On 08/11/2010 11:05, Andrew McIntyre wrote:
Hello Hugh,
As someone who believes in a level playing field I think an
international standard, even if a little flawed is better than waiting
forever for perfection which will never come. I would extend
On 08/11/2010 13:45, William E Hammond wrote:
I appreciate all of the remarks that have been make thus far. I am
responding because I think we might have some shot at being better. I
think many of you tak pot-shots at HL7, and that's OK.
I want to clarify one thing: HL7v2 is an excellent
Well said Ed!
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
-- next part --
An
In a message dated 8-11-2010 15:38:26 W. Europe Standard Time,
thomas.beale at oceaninformatics.com writes:
I have been asking HL7 since 2003 or so to show a clean model of any of
the following in RIM or CDA structures:
2 or 3 sample Apgar
standard 3 sample GTT (glucose tolerance test)
Great, do you have a link where they can be found/seen.
Cheers,
Stef
Op 8 nov 2010, om 21:02 heeft Williamtfgoossen at cs.com het volgende
geschreven:
In a message dated 8-11-2010 15:38:26 W. Europe Standard Time, thomas.beale
at oceaninformatics.com writes:
I have been asking HL7 since
Thanks.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Williamtfgoossen@
cs.com
On 08/11/2010 20:02, Williamtfgoossen at cs.com wrote:
In a message dated 8-11-2010 15:38:26 W. Europe Standard Time,
thomas.beale at oceaninformatics.com writes:
I have been asking HL7 since 2003 or so to show a clean model of any
of the following in RIM or CDA structures:
2 or 3 sample
On 08/11/2010 18:51, Grahame Grieve wrote:
hi All
A roll up of comments:
1. ISO 21090 is often (always?) profiled
It seems remarkable to me that people think it's a problem that ISO 21090
needs to be profiled. Who would've guessed that a full standard that meets
many requirements is
From: openehr-technical-bounces at openehr.org
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: 08 November 2010 21:19
To: openehr-technical at openehr.org
Subject: Re: ISO 21090 data types too complex?
On 08/11/2010 18:51, Grahame Grieve wrote:
hi All
A roll up
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101107/49910900/attachment.html
hi Tom
David's points are right on the money. The heart of the matter
is not invented here. A related issue is the fact that the
ISO 21090 data types are optimised for exchange, not storage
(explicitly a statement in their scope), but the NCI scope includes
storage - which raises hard questions
Grahame,
On 06/11/2010 21:17, Grahame Grieve wrote:
hi Tom
David's points are right on the money. The heart of the matter
is not invented here.
they might well be; my original question was: is this the only possible
reaction (these data types are complex, untested and risky); is there no
ISO 21090 is a true ISO standard.
It does include a lot of OpenEHR data type specs, except where OpenEHR
decided to go their own way.
And in the HL7 space some are working on implementing the ISO 21090
standard in the HL7 models, which is quite a task, not impossible, but a lot of
work.
Wiliiam,
openEHR 'cooperating more' and not 'reinventing' would have been
impossible without time travel. The openEHR data types were started in
2002, and were in production use in Australia in 2004. Since then nearly
all changes have involved refactorings of functions and abstract types.
If
hi Tom
I'm not going to get into a long debate here about modeling
philosophy. I'll respond with brief points to each of yours, and
then I'll shut up. Other people can take it further if they want.
they might well be; my original question was: is this the only possible
reaction (these data
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101107/5d3a9dc8/attachment.html
It is not clear to me that Tom's remarks help either. HL7 had data types
very early. That is not the point. The issue is is there anything in the
future we can agree and work togwether. Unfortunately, I have come to the
conclusion we cannot not, and as a result we shall let the market make
-bounces at openehr. Subject
org Re: ISO 21090 data types too
complex?
11/06/2010 05:36
It looks like we're getting to the heart of the matter here.
What I really would like to know from the others what their opinion's on these
subjects are?
If it indeed turns out to be true that Tom don't understand how datatypes, RIM
or data types are working, we, as the openEHR community,
*
*The NCI's take, from this document
https://wiki.nci.nih.gov/download/attachments/18941682/Policy_Guidelines_ISO_21090_Final+%28Approved%29.doc?version=1modificationDate=1247258606000
available here
https://wiki.nci.nih.gov/display/ISO21090/CBIIT+Guidelines+for+Using+the+ISO+21090+Standard
On 06/11/2010 15:29, David wrote:
Thomas,
I've been retired for some time now but have kept a quiet watch over
things that have been happening in the world of heath data
standardisation. I stay quiet because I do not wish to intrude into
arguments that people in the real world are
openehr-technical cc
-bounces at openehr.
org Subject
Re: ISO 21090 data types too
Hi Ed,
well since you asked ... my list of problems, from a cursory examination:
* The model is defined such that all data types inherit from HXIT
and then ANY, which contain 7 attributes specific to HL7v3
messages. This means that any other types, such as BL (Boolean)
: ISO 21090 data types too
complex?
11/06/2010 05:36
PM
74 matches
Mail list logo
