Class Archetype, eo

Implementers (archive)
1

I noticed that in the code I use, the class Archetype is immutable (no setters, only betters)

I also noticed that in, f.e. in Visual basc written Archetype Editor from Ocean Informatics, there is a class ADL_Archetype (this has setters), which inherits from class Archetype, but also the ancestor has setters. So the ArchetypeEditor has a lot more setter-functionality, this is of course very explainable.

I wonder, could the code-concepts be used to generate Archetypes from HL7 XML/XSD-files.

Still busy with this, and looking for a way to do it once.

Does some have an opinion about this?

Thanks
Bert

2

Bert Verhees wrote:

I noticed that in the code I use, the class Archetype is immutable (no setters, only betters)

I also noticed that in, f.e. in Visual basc written Archetype Editor from Ocean Informatics, there is a class ADL_Archetype (this has setters), which inherits from class Archetype, but also the ancestor has setters. So the ArchetypeEditor has a lot more setter-functionality, this is of course very explainable.

I wonder, could the code-concepts be used to generate Archetypes from HL7 XML/XSD-files.

I don't think so. We are studying this....my thinking so far:
* the structural design of HL7 RMIMs (and therefore any derived expression in XML) is heavily influenced by the HL7 RIM; it would be quite difficult to do a machine transformation from such structures to openEHR structures
* different RMIM designers do their own thing, and there is often limited commonality of structure in HL7 messages designs for components that are logically the same
* the fine-grained attribute design of HL7 is very problematic - mapping from all the Act, Act_relationship and Entity attributes to other models poses a lot of problems.
* Now that I have reviewed some of the NHS RMIMs, there are a lot of problems apparent, many due to HL7.

Ultimately the problem comes down to this: to get a good archetype, you need good quality clinical and/or domain expertise - i.e. a human being - who has deep knowledge of the reference model that the archetypes are based on. So rebuilding proper archetypes from HL7 structures is more likely to be done by a review team rather than writing a computer program.

- thomas

3

Thomas Beale schreef:

Bert Verhees wrote:

I noticed that in the code I use, the class Archetype is immutable (no
setters, only betters)

I also noticed that in, f.e. in Visual basc written Archetype Editor
from Ocean Informatics, there is a class ADL_Archetype (this has
setters), which inherits from class Archetype, but also the ancestor
has setters. So the ArchetypeEditor has a lot more
setter-functionality, this is of course very explainable.

I wonder, could the code-concepts be used to generate Archetypes from
HL7 XML/XSD-files.

I don't think so. We are studying this....my thinking so far:
* the structural design of HL7 RMIMs (and therefore any derived
expression in XML) is heavily influenced by the HL7 RIM; it would be
quite difficult to do a machine transformation from such structures to
openEHR structures
* different RMIM designers do their own thing, and there is often
limited commonality of structure in HL7 messages designs for components
that are logically the same
* the fine-grained attribute design of HL7 is very problematic - mapping
from all the Act, Act_relationship and Entity attributes to other models
poses a lot of problems.
* Now that I have reviewed some of the NHS RMIMs, there are a lot of
problems apparent, many due to HL7.

Ultimately the problem comes down to this: to get a good archetype, you
need good quality clinical and/or domain expertise - i.e. a human being
- who has deep knowledge of the reference model that the archetypes are
based on. So rebuilding proper archetypes from HL7 structures is more
likely to be done by a review team rather than writing a computer program.

Why, I don't understand. In fact HL7 are just data in a structure.
The data are delivered in XML-files, and if there are archetypes with
the same structure, the data can just fall in place.

I know this is not nice, and could have been done better by a domain
expert. Everything that can be done, can be done better.

In my opinion, you don't loose any information, you just save it. And
you are able to restore the XML-message again.

The advantage is that one can use the good thinking of the HL7 domain
modellers, which are recognized as experts.

The reason I would count as being severe in this context would be that
data-item so and so cannot be stored in a archetype and restored.

That, in fact is my question.

I think, as time goes by, we, in the project I work can restore data in
other structures/archetypes if that is the desire. But at this moment,
domain-modelling and mapping are things we want to avoid because of
time-pressure, that is why I did today start a Java-project for
translating XSD-structures into archetypes, and the first version will
be ugly, but it will do its job, and it will get better.

So, if you, ore someone else would please answer this question, I would
be helped and also very grateful:

Is it possible to create archetypes so that they can be used to store
and restore CMETs?

(if there is any interest, I can donate or publish this new code on a
place on the Internet, later to decide)

Thanks
Bert

4

Bert Verhees wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Beale schreef:
  

Bert Verhees wrote:
    

I noticed that in the code I use, the class Archetype is immutable (no
setters, only betters)

I also noticed that in, f.e. in Visual basc written Archetype Editor
from Ocean Informatics, there is a class ADL_Archetype (this has
setters), which inherits from class Archetype, but also the ancestor
has setters. So the ArchetypeEditor has a lot more
setter-functionality, this is of course very explainable.

I wonder, could the code-concepts be used to generate Archetypes from
HL7 XML/XSD-files.
      

I don't think so. We are studying this....my thinking so far:
* the structural design of HL7 RMIMs (and therefore any derived
expression in XML) is heavily influenced by the HL7 RIM; it would be
quite difficult to do a machine transformation from such structures to
openEHR structures
* different RMIM designers do their own thing, and there is often
limited commonality of structure in HL7 messages designs for components
that are logically the same
* the fine-grained attribute design of HL7 is very problematic - mapping
from all the Act, Act_relationship and Entity attributes to other models
poses a lot of problems.
* Now that I have reviewed some of the NHS RMIMs, there are a lot of
problems apparent, many due to HL7.

Ultimately the problem comes down to this: to get a good archetype, you
need good quality clinical and/or domain expertise - i.e. a human being
- who has deep knowledge of the reference model that the archetypes are
based on. So rebuilding proper archetypes from HL7 structures is more
likely to be done by a review team rather than writing a computer program.
    
Why, I don't understand. In fact HL7 are just data in a structure.
The data are delivered in XML-files, and if there are archetypes with
the same structure, the data can just fall in place.

I know this is not nice, and could have been done better by a domain
expert. Everything that can be done, can be done better.

Bert,
I might have misunderstood you - maybe you want to create archetypes based directly on the RIM. This is possble. No-one else is doing it, or probably will do it (because of the poor design of the RIM for EHR and related data), and there are no tools. But...the archetypes could be written by hand, and the Java ADL parser should process them properly. Is this what you want to do?

- thomas

5

Thomas Beale schreef:

Bert Verhees wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Beale schreef:

Bert Verhees wrote:
   

I noticed that in the code I use, the class Archetype is immutable (no
setters, only betters)

I also noticed that in, f.e. in Visual basc written Archetype Editor
from Ocean Informatics, there is a class ADL_Archetype (this has
setters), which inherits from class Archetype, but also the ancestor
has setters. So the ArchetypeEditor has a lot more
setter-functionality, this is of course very explainable.

I wonder, could the code-concepts be used to generate Archetypes from
HL7 XML/XSD-files.
      

I don't think so. We are studying this....my thinking so far:
* the structural design of HL7 RMIMs (and therefore any derived
expression in XML) is heavily influenced by the HL7 RIM; it would be
quite difficult to do a machine transformation from such structures to
openEHR structures
* different RMIM designers do their own thing, and there is often
limited commonality of structure in HL7 messages designs for components
that are logically the same
* the fine-grained attribute design of HL7 is very problematic - mapping
from all the Act, Act_relationship and Entity attributes to other models
poses a lot of problems.
* Now that I have reviewed some of the NHS RMIMs, there are a lot of
problems apparent, many due to HL7.

Ultimately the problem comes down to this: to get a good archetype, you
need good quality clinical and/or domain expertise - i.e. a human being
- who has deep knowledge of the reference model that the archetypes are
based on. So rebuilding proper archetypes from HL7 structures is more
likely to be done by a review team rather than writing a computer
program.
    
Why, I don't understand. In fact HL7 are just data in a structure.
The data are delivered in XML-files, and if there are archetypes with
the same structure, the data can just fall in place.

I know this is not nice, and could have been done better by a domain
expert. Everything that can be done, can be done better.

Bert,
I might have misunderstood you - maybe you want to create archetypes
based directly on the RIM. This is possble. No-one else is doing it, or
probably will do it (because of the poor design of the RIM for EHR and
related data), and there are no tools. But...the archetypes could be
written by hand, and the Java ADL parser should process them properly.
Is this what you want to do?

Yes, that is for the time being what I want to do.
Here in the Netherlands is the majority of all involved people in
opinion that HL7 RIM does not suffer from poor design.

But, there is no public discussion about this, and most people do not
know what one or the other thing in fact is.

That is, what I want to mention, in between: OpenEHR needs marketing!!!

But anyway, at this way, I do not oppose against this majority who
thinks HL7 is the best thing, and I implement OpenEHR, the wort of both
worlds?

Maybe, but with opportunities to grow to something better, which is not
yet planned.

One thing extra, the parsing of the DMIM-XSD's used in the Netherlands,
lead to 994 Jaa-classes. Thus, in fact, 994 archetypes, this can only be
done by generating, in such a short period of time I have.

So I want to write this generator in two or three weeks, maybe ugly
code, but it will work, and be based on OpenEHR 0.95.

This is because, it is what I have, and I have it complete, including
object relational layer for database.

Later I want to migrate to a more recent version, the migration path
will be very easy, a brilliant idea of Goran.

Because my archetyes can be imported from, and exported to HL7, I can
export them, use a new kernel and import them again.

Maybe at that time, some better modelling can take place, and some
tricks to get the data in other archetypes during the migation-proces

That is about it.

Thanks for your confirmation that HL7 DMIM data can be stored/restored
in/from OpenEHR

Bert

6

Bert Verhees wrote:

Thanks for your confirmation that HL7 DMIM data can be stored/restored
in/from OpenEHR

actually, they cannot; what my suggestion describes is the DMIM data being representable as archetypes on the HL7 RIM, not the openEHR reference model.

Re: marketing - now maybe openEHR does need some marketing, now that we have running applications and know that it works - that would be ethical and appropriate.....

- t

7

Thomas Beale schreef:

Bert Verhees wrote:

Thanks for your confirmation that HL7 DMIM data can be stored/restored
in/from OpenEHR

actually, they cannot; what my suggestion describes is the DMIM data being representable as archetypes on the HL7 RIM, not the openEHR reference model.

Yes, I understand, but it is the best option, given the amount of time, still left.
And it gives a base for developing an openehr application, somewhere later in time. And migrate the data to a proper OpenEHR model.
But at the beginning, we reach to targets

- we can communicatie with the Dutch health network
- we have a model for storing data
- we have a base from which we can migrate
- we have an interface layer which can present our data, data coming from elsewhere, and store data coming from elsewhere.

I guess, that is quite a lot for the moment.

The other option would be to migrate the data directly to an openehr model.
- we need to create an mapping to hl7, anyway, because that is the only source
- we need to define our model based on openehr
- we need to write an interface using openehr

8

I guess this is an obvious question, for those who read the mails with this subject.
Only for convenience, is there a ADL-editor, which does not enforce the OpenEHR reference model, but just is able to write syntax-OK ADL.
I don't think I will not have much luck on this.

<plan B>
I can generate my own ADL-files from XSD-files. I guess this will be possible.
I will win lots of time.

I have already java-classes generated from the XSD files with Jaxb

It must be will be possible to generate the code which uses the archetypes, and create instances of data-classes

Jaxb will take care of creating XML-files from the filled data-class instances

I think this is the best plan to proceed.

<questions>
<question>I need some ADL-examples. One. Does someone know a ADL-file which has a Archetype-slot in it, for example?</question>
<question>I have found one ADL-file based on a HL7, it was one which was a bit older. Still there were useful things in it, but I would like to have more. If someone can help me</question>
</questions>
</plan B>
thanks

Bert Verhees

9

Bert Verhees wrote:

I guess this is an obvious question, for those who read the mails with this subject.
Only for convenience, is there a ADL-editor, which does not enforce the OpenEHR reference model, but just is able to write syntax-OK ADL.
I don't think I will not have much luck on this.

at the moment, no - when I want to write a non-openEHR archetype at the moment I just do it by hand using gvim (with a colourising.adl profile) and then check it with the workbench. Not ideal, but that's the state of things today.

<plan B>
I can generate my own ADL-files from XSD-files. I guess this will be possible.
I will win lots of time.

I have already java-classes generated from the XSD files with Jaxb

It must be will be possible to generate the code which uses the archetypes, and create instances of data-classes

Jaxb will take care of creating XML-files from the filled data-class instances

I think this is the best plan to proceed.

<questions>
<question>I need some ADL-examples. One. Does someone know a ADL-file which has a Archetype-slot in it, for example?</question>

see the Section archetypes at http://svn.openehr.org/knowledge/archetypes/dev/html/en/ArchetypeMap.html (ADL is available from links within the html pages)

- thomas

10

Thomas Beale schreef:

Bert Verhees wrote:

I guess this is an obvious question, for those who read the mails with this subject.
Only for convenience, is there a ADL-editor, which does not enforce the OpenEHR reference model, but just is able to write syntax-OK ADL.
I don't think I will not have much luck on this.

at the moment, no - when I want to write a non-openEHR archetype at the moment I just do it by hand using gvim (with a colourising.adl profile) and then check it with the workbench. Not ideal, but that's the state of things today.

<plan B>
I can generate my own ADL-files from XSD-files. I guess this will be possible.
I will win lots of time.

I have already java-classes generated from the XSD files with Jaxb

It must be will be possible to generate the code which uses the archetypes, and create instances of data-classes

Jaxb will take care of creating XML-files from the filled data-class instances

I think this is the best plan to proceed.

<questions>
<question>I need some ADL-examples. One. Does someone know a ADL-file which has a Archetype-slot in it, for example?</question>

see the Section archetypes at http://svn.openehr.org/knowledge/archetypes/dev/html/en/ArchetypeMap.html (ADL is available from links within the html pages)

Very good, thanks
Bert