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@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 unionextension 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 that a right decision? Unfortunately,
time won't tell, since the alternatives are purely hypothetical.
[HKF: ] Obviously this deliberate decision was made without the parties that
were in Berlin who had come to that conclusion for a very good reason, they
had already tried that approach without success. So we are back to the same
position we were in 5 years ago, with another data types standard that is
unable to be used out of the box ubiquitously in healthcare information
systems.
which is more likely to be used out of the box?
intersection, or union?
Union at least has everything....
Grahame
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 then define an archetype on that, which has the effect of defining a constrained object structure based on the class model. So we do use both - every day. The openEHR and CEN Reference Models are of course published in UML, and this is what allows archetypes to be created on top of them.
In short: UML is good for static class models; ADL is good for static instance models.
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 namespacing? It would make that much difference to you to prefix all or some of the types with "DV_" or something? Surely not. Did you read the discussion in ISO 21090 about this point? (It was written specifically for you) (and btw, in my implementation, I did end up prefixing the names, for purely programming reasons)
obviously I know about namespacing… as I mentioned earlier, it is not me personally who is generally trying to interpret the standard in contexts where it is being used.
change UML). I fail to see why standards in e-health have to be done in such a bizarre way. There is nothing special about e-health requiring that.you changed the sense. Your original claim was that standards should just pick something that works well enough. My point is that ICT vertical interoperability standards don't work like that, including in health. As Ann pointed out, not everyone uses normal OO modelling, and for a variety of reasons. In fact, big companies are starting to move on - have you seen M (microsoft oslo)? I happen to think that design by constraint - which is the fundamental pattern of both v3 and openEHR - is irretrievably busted, and it's time
well there is the HL7v3 way of doing it, which I agree is irretrievably broken, but the archetype formalism works differently: it leaves the reference model intact, so that all data always conform to the one reference model for all time.
for us both to move on and find something better. (But perhaps we should spend some time implementing in the real world before we do that...) I'm watching M closely to see if a realistic alternative emerges there. It hasn't yet. And the alternative is to talk to OMG to talk about getting UML changed. But it's odd to have the pot call the kettle black, since ADL is hardly standard UML.
see other post: this is a misunderstanding. HL7 asked OMG to change UML itself; openEHR has no need of that.
Not the terminology realm, the ontology realm. The combination of any reference model, content constraining models, and terminology constitute a set of ontological commitments. openEHR chose to make the commitment for ‘Observation’ in the RM because it needs structure, and terminology doesn’t provide that. No-one on this discussion list (or indeed any other) has yet managed to show how it is easier to model typical content like OGTT, Apgar, and time-series vital signs, with no structure to represent timing, events, or patient state. Just putting a code on a lump of data calling it ‘observation’ doesn’t help the software know what it is looking at.
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 windows vs. linux discussion).
Reality is complex, and there are many ways of modeling reality, none is bad when it has a good utility.
My experience is that the HL7 ways of modeling things comes from representing XML Schemas in an object oriented way, but is not an schema, nor an UML.
When I need to use some HL7 message or a CDA, I just simply model the RIM or the CDA in UML, and implement that. Yes, it would be nicer if the model was already UML, but I know I’m a small ant, and I can’t tell a big elephant to change. So I work a little harder to get things done, and it works.
In the HL7 UML models I’ve done, I get rid of a lot of (I think) unnecesary classes, in HL7 dataypes I’ve only the CD and CS classes to represent codes, I get rid of GTS and use SET, for IVL I just use IVL. When it come to structures like SET, IVL, LIST and BAG, I don’t use ANY as a superclass. I separate real datatypes from structures.
Just my grain of sand.
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 and should influence the elephants
and their behaviour. The elephants were born and are sustained in
order to make life easier for those of us trying to solve real
information processing problems.
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 practice. My hope is that the healthcare IT community
(Ants, elephants and the rest of the menagerie) delivers increasing
value while continuing to learn together and from each other.
I am sure that the learning will involve sacred cows being challenged
and passed over, and will involve some discomfort as well as delight.
It will involve engineering, economics, politics, personalities, and
more
all the best
Charlie
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
<charlie@ramseysy
stems.co.uk> To
Sent by: For openEHR technical discussions
openehr-technical <openehr-technical@openehr.org>
-bounces@openehr. cc
org
Subject
Re: ISO 21090 data types too
11/09/2010 12:29 complex?
PM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
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 and should influence the elephants
and their behaviour. The elephants were born and are sustained in
order to make life easier for those of us trying to solve real
information processing problems.
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 practice. My hope is that the healthcare IT community
(Ants, elephants and the rest of the menagerie) delivers increasing
value while continuing to learn together and from each other.
I am sure that the learning will involve sacred cows being challenged
and passed over, and will involve some discomfort as well as delight.
It will involve engineering, economics, politics, personalities, and
more
all the best
Charlie
[1] http://www.infed.org/thinkers/et-lewin.htm
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 windows vs. linux discussion).
Reality is complex, and there are many ways of modeling reality, none is
bad
when it has a good utility.
My experience is that the HL7 ways of modeling things comes from
representing XML Schemas in an object oriented way, but is not an schema,
nor an UML.When I need to use some HL7 message or a CDA, I just simply model the RIM
or
the CDA in UML, and implement that. Yes, it would be nicer if the model
was
already UML, but I know I'm a small ant, and I can't tell a big elephant
to
change. So I work a little harder to get things done, and it works.
In the HL7 UML models I've done, I get rid of a lot of (I think)
unnecesary
classes, in HL7 dataypes I've only the CD and CS classes to represent
codes,
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 practice. My hope is that the healthcare IT community
(Ants, elephants and the rest of the menagerie) delivers increasing
value while continuing to learn together and from each other.
I have some phrases on my own 
I am sure that the learning will involve sacred cows being challenged
and passed over, and will involve some discomfort as well as delight.
It will involve engineering, economics, politics, personalities, and
more
Yes, but we cannot make a revolution in every step we take, because:
We have to find what we have in common in order to make a stronger community, if not, we are just ants that can’t work together, and destined to die of hunger.
My opinion is that today we have to work to make a stronger community, working on a common objetive. May be then we can make a big anthill of the size of an elephant.
Kind regards,
Pablo.
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.
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@results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
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
Sent by: To
openehr-technical openehr-technical@openehr.org
-bounces@openehr. cc
org
Subject
Re: ISO 21090 data types too
11/12/2010 05:46 complex?
AM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
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@results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713