Thomas Beale schreef:
Bert Verhees wrote:
Those classes are very simple, I do not understand why it is impossible
to translate them into arcetypes.
it is not impossible, it is just not likely to be automatable safely,
with _no bugs_, no data errors, so that the result does exactly what it
is supposed to do....
It is not so that for every message a new schema is generated, but for
every message-type it is.
every message type, yes, this is what we usually mean when we say this...
Yes, excuse me, I thought so. But then, in my opinion, it does not need
to be a big problem, because it is limited to (number of) the messages
one want to use, and the messages are machine-interpreted, so they will
not change often, and when they do, it will be important to communicate
this, and I think, but I am not sure, when the CMET's change, they will
get a new number/name.
But in the Netherlands we have to deal with three message-types, for
now, I don't see the problem.
actually, there are about 40 - see
http://www.zorginformatiemodel.nl/observaties.html
But there are only three involved with primary care, there is one large,
that is the one that is of interest to me. It contains a complete
medical dossier, and there is one, which is about the same, but smaller,
for medical services on duty (this contains relevant medications, etc.)
And some other small things.
I downloaded this information from Nictiz, it is from April this year.
But the information in documents is in Dutch, and which is worse, very
incomplete. Even the JPG's in the documentation, are unreadable.
But they also included the XSD's from the messages from this DMIM, which
is called, as I wrote before: Prica (primary care)
These XSD's are most important, because they describe very exactly the
DMIM, and also the message derived from this, and I can derive
Java-classes from them.
I see big problems for those who do not use openehr for storing HL7
messages, every time the message definition evolves, they have to
rewrite their database scheme, and maybe also their application.
But I am going to use OpenEhr, so I have good hopes, things will go more
smoothly
What do you think about this?
I think that we need to re-engineer the good thinking that is trapped in
the HL7 message framework, into an archetype / reference model
framework. Then we can have the intended effect, in a technical paradigm
that will do the right thig, and won't force us to bechanging the
database schema and software all the time.
I understand why you see a problem, and I cannot judge it, but I have a
feeling you are right in your situation.
The reason is because you are thinking of a generic solution (as I
understand it). This is not what I am thinking of, but you may have
understood this already.
- -----------------
Let me describe my application-architecture-thinking.
- - I need to store medical related data
- - I want to use openehr
- - I need to think of a model for archetyping
- - I need to communicatie with Dutch Medical network (based on ONE DMIM)
- - I need to provide an inter-face-application with data in XML
Which "thing" is the thing that comes to mind:
HL7 Prica
- - It implictely contains a model to store data
- - It communicates with the Dutch Medical Network
- - It is an XML message
- - It contains (in largest form) a complete medical record
- - It is designed by a group of well educated an recognised experts in
the Dutch field. There is hardly any doubt on any university in the
Netherlands on the quality of their work.
- - because it can be broken down in CMET's, which can be seen in fact
very simple classes, with only constraints and properties, I think they
are easy to express in archetypes.
But the problem is, it contains about 900 classes, and some of them are
really stupid, and there is a lot of redundancy, and there is no or very
little technical modelling
Maybe, medical seen, they are very good, I leave that to others to think
about, and I trust Nictiz in this. But technically, they are, in my
humble opinion, a mess.
It looks like they designed every CMET by what comes to mind, without
looking to what was already there to derive (inherit) from.
And that is my question too, In a glance, I can reduce the number of
classes to 50 instead of 900 hunred. That was what I was expecting to
get, when I was automatically interpreting the CMET's (XSD's).
So, if I keep it this way, I have to create 900 archetypes, maybe I
could write software to do so. I haven't thought about it yet.
The other option is to model the classes, like it should in UML, and
work with the 50 classes left. But in that case, I have to do all manually.
What do you advise, I think, there are ther options too.
regards
Bert Verhees