Specs and documentation state that assertions should be used in reference to information inside the archetype they are defined in.
does this mean I cannot create an assertion in composition to validate some relation between two observations which are part-of the composition?
This situation came up while I was thinking on how to model the following, “perinatology reports should not be recorded for male patients”.
How would you represent this restriction with RM and archetypes?
thank you
Rodrigo Filgueira wrote:
Specs and documentation state that assertions should be used in
reference to information *inside *the archetype they are defined in.
does this mean I cannot create an assertion in composition to validate
some relation between two observations which are part-of the composition?This situation came up while I was thinking on how to model the
following, "perinatology reports should not be recorded for male
patients".
How would you represent this restriction with RM and archetypes?
this would be either in the include / exclude archetype slot list in a
Composition or Section archetype, or else in invariants in such an
archetype.
- thomas beale
All right , I get the idea with includes/excludes, but if I were to to use invariants (which means creating an assertion) then the “sex” or “gender” information should be available “inside” the archetype.
While this is possible, there seems to be no need to include this information in the archetype since it is obtainable from the demographic information of the patient.
So alternatives would be, include this redundant piece of information (sex) or have access from the assertion to data “outside” this archetype?
The second one is not possible I understand.
am I correct?
Thomas Beale wrote:
Hello
I’m thinking to port Archchetype editor to Linux.
(As myself don’t run windows at all)
Are there any other dependencies other than ADL parser? (adl_java_lib.dll)
Any help will be greatly appreciated!
rgds
minreddy
There is already a Java-based archetype editor available here:
http://svn.openehr.org/knowledge/archetypes/dev/index.html
Regards,
Mattias Forss
2006/8/27, minreddy minreddy <minreddy@yahoo.com>:
There is already a Java-based archetype editor available here:
Too bad, the sourcecode still is not published (last time I downloaded
it), I would like to see some improvements in (f.e.) error-handling. It
does never say why I ADL-file cannot be loaded, it just says it cannot
load it. There are many ADL-files, which it does not load, and I think for
good reasons, but it should say why. If it had sourcecode with it, I would
have repaired this, for my own use, because I have need for an
Archetype-editor which can also be used for debugging purposes. Another
good feature I would like to see is two way editing, in a GUI and in
ADL-editor, and see how changes on both sides reflect on the other side.
And another feature is support for more ADL-versions, not only the latest.
This could help migrate older ADL-files to newer versions. People who have
invested in previous versions now have to dive into the (for some people)
painful process of manually updating their ADL-files to newer versions.
So, except for not distributing the source-code, and to simple
error-handling, it is a very stable and good tool. I expect the
source-code to be published some day, because the creators indicated they
will, but they did, as far as I know, not indicate when.
The archetype editor from Ocean, which looks as GUI about the same as the
Java-Archetype-editor, has sourcecode, and if you do not like dotnet-VB,
you can still use it to extract useful parts of the architecture, and
build your own in every language you want. The Ocean version has a few
instabilities.
So there are two Archetype-Editors, both look about the same in GUI, but
both are build on complete different technologies. And both need
improvement.
I think there is a need for more, specially if there are improvements on
GUI-thinking. I know, all Word-processors look the same, and all cars look
the same, but is it the best way a car or Word-processor should look?
We do not know, so I suggest that someone who want to build an
archetype-editor, should not look at those who exists, he could get
trapped in obvious thinking.
These are only some suggestions from a rainy day in region of the South
Central France
regards
Bert Verhees
2006/8/28, Bert Verhees <bert.verhees@rosa.nl>:
There is already a Java-based archetype editor available here:
Too bad, the sourcecode still is not published (last time I downloaded
it), I would like to see some improvements in (f.e.) error-handling. It
does never say why I ADL-file cannot be loaded, it just says it cannot
load it. There are many ADL-files, which it does not load, and I think for
good reasons, but it should say why. If it had sourcecode with it, I would
have repaired this, for my own use, because I have need for an
Archetype-editor which can also be used for debugging purposes.
The source code will be published as open source in the future, but we at Linköping university haven’t decided when that will be.
The current Java ADL-parser isn’t complete yet and many archetypes are still badly formatted. The parser is not too forgiving, so for example if there are missing parts in the description part of an archetype the parsing process will fail. This is mainly why many ADL-files won’t load. Also, when an archetype fails to load it is often due to parsing errors but we don’t output the errors given by the parser because sometimes they don’t make sense at all. However, I am thinking about adding error outputs from the parser to a logfile.
Another
good feature I would like to see is two way editing, in a GUI and in
ADL-editor, and see how changes on both sides reflect on the other side.
And another feature is support for more ADL-versions, not only the latest.
This could help migrate older ADL-files to newer versions. People who have
invested in previous versions now have to dive into the (for some people)
painful process of manually updating their ADL-files to newer versions.
I have plans on making an ADL-editor that makes continuous checks as to whether the syntax is ok and marks the line number that the parser failed on, but this requires reloading of the edit buffer every time we want to show the changes in the GUI. It might become slow, but I believe it is possible to implement. However, there are many other things to implement before that, but it is definitely a good idea.
Older versions than 1.3 (I think) of ADL isn’t supported which depends on the ADL parser but I guess it would be possible to implement support for different versions. However, this would require to implement support for that in the ADLSerializer as well and not to forget it would require a lot of checking to ensure that semantics and syntax of these archetypes are correct.
However, I don’t believe there is any idea of maintaining the older (ADL version < 1.4) archetypes since they sometimes are inconsistent and faulty regarding to the reference model they are supposed to follow. I believe the current archetypes are the first ones that actually should be maintained since the openEHR project has suffered from teething troubles that are common to many large projects. At some point we must decide to migrate from older/obsolete versions even if it affects a lot of people, it is just a part of a natural evolution process for ADL.
I am not saying the archetypes that have been used in older systems should be deleted, but there is no need creating more mess than needed. The older systems will eventually and inevitably have to start using newer archetypes in the future if they want to transfer and receive data to/from other clinical systems that haven’t been around as long.
So, except for not distributing the source-code, and to simple
error-handling, it is a very stable and good tool. I expect the
source-code to be published some day, because the creators indicated they
will, but they did, as far as I know, not indicate when.The archetype editor from Ocean, which looks as GUI about the same as the
Java-Archetype-editor, has sourcecode, and if you do not like dotnet-VB,
you can still use it to extract useful parts of the architecture, and
build your own in every language you want. The Ocean version has a few
instabilities.So there are two Archetype-Editors, both look about the same in GUI, but
both are build on complete different technologies. And both need
improvement.
I think there is a need for more, specially if there are improvements on
GUI-thinking. I know, all Word-processors look the same, and all cars look
the same, but is it the best way a car or Word-processor should look?
Your suggestions on improvements are always welcome…
We do not know, so I suggest that someone who want to build an
archetype-editor, should not look at those who exists, he could get
trapped in obvious thinking.
We had a lot of ideas when building the Java archetype editor concering the GUI, but eventually decided to design it like Ocean’s GUI. There are a number of reasons we did this, the most obvious was that we wanted to enable a structured overview of an archetype and this is why the different views in the editor was created. This was an obvious way to make it easier for a user to know what part of an archetype he/she is editing. In retrospect, the current GUI design is not optimal and it could have been designed in several different ways but we didn’t want to compromise the usability of the program. For example if the entire archetype could be edited in a single view it could be to many things (buttons, floating toolbars, popup menus, commands, etc.) to keep in mind for the user.
We have many plans for the editor and there had been discussions of adding another view in which the user can edit large parts of archetypes in a completely different manner compared to the current editing process. Probably a lot of things will happen in the future when other programmers can join an open source Java archetype editor project.
Regards,
Mattias
Thanks Mattias for your answer. I keep it short, now, the weather has
improved, and I am on holiday 
and the keyboard-layout still is French,
which causes me to search every character.
> There is already a Java-based archetype editor available here:
>
> http://svn.openehr.org/knowledge/archetypes/dev/index.htmlToo bad, the sourcecode still is not published (last time I downloaded
it), I would like to see some improvements in (f.e.) error-handling. It
does never say why I ADL-file cannot be loaded, it just says it cannot
load it. There are many ADL-files, which it does not load, and I think
for
good reasons, but it should say why. If it had sourcecode with it, I
would
have repaired this, for my own use, because I have need for an
Archetype-editor which can also be used for debugging purposes.The source code will be published as open source in the future, but we at
Linköping university haven't decided when that will be.
I think you probably know that publishing source-code in a early stage has
advantages, this is specially true when one wants to publish it anyway. It
allows others to implement features they need, and you can keep control by
being the administrator of the CVS system, and hide forks you don't want.
F.e. this is facilitated in sourceforge.net.
This is why I don't understand that you do not publish the sourcecode now.
But I am sure you(or the university) have good reasons for this.
The current Java ADL-parser isn't complete yet and many archetypes are
still
badly formatted. The parser is not too forgiving, so for example if there
are missing parts in the description part of an archetype the parsing
process will fail. This is mainly why many ADL-files won't load. Also,
when
an archetype fails to load it is often due to parsing errors but we don't
output the errors given by the parser because sometimes they don't make
sense at all. However, I am thinking about adding error outputs from the
parser to a logfile.
This would be a good addition, and opening the logfile-window after
failure, it could help someone to update older ADL-files which for now he
has to update manually, and has no way to check in detail which small
thing he forgot to change. As being a programmer I think, you know exactly
what I mean.
Another
good feature I would like to see is two way editing, in a GUI and in
ADL-editor, and see how changes on both sides reflect on the other side.
And another feature is support for more ADL-versions, not only the
latest.
This could help migrate older ADL-files to newer versions. People who
have
invested in previous versions now have to dive into the (for some
people)
painful process of manually updating their ADL-files to newer versions.I have plans on making an ADL-editor that makes continuous checks as to
whether the syntax is ok and marks the line number that the parser failed
on, but this requires reloading of the edit buffer every time we want to
show the changes in the GUI. It might become slow, but I believe it is
possible to implement. However, there are many other things to implement
before that, but it is definitely a good idea.
You could an automatically reload replace by
This message was send too early because of the foreign keyboard layout,
excuse me for that, I will complete it now (please delete the previous)
2006/8/28, Bert Verhees <bert.verhees@rosa.nl>:
There is already a Java-based archetype editor available here:
http://svn.openehr.org/knowledge/archetypes/dev/index.html
Too bad, the sourcecode still is not published […]
If it had sourcecode with it, I would
have repaired this, for my own use, because I have need for an
Archetype-editor which can also be used for debugging purposes.The source code will be published as open source in the future, but we at Linköping university haven’t decided when that will be.
If there now are people that seriously want to contribute to the development with patches etc (like Bert suggests) I believe that it’s time to publish the source very soon. We’ll try to look in to this within a couple of weeks. Remind us if we forget it
So there are two Archetype-Editors, both look about the same in GUI, but
both are build on complete different technologies. And both need
improvement.
I think there is a need for more, specially if there are improvements on
GUI-thinking. I know, all Word-processors look the same, and all cars look
the same, but is it the best way a car or Word-processor should look?Your suggestions on improvements are always welcome…
We do not know, so I suggest that someone who want to build an
archetype-editor, should not look at those who exists, he could get
trapped in obvious thinking.We had a lot of ideas when building the Java archetype editor concering the GUI, but eventually decided to design it like Ocean’s GUI. There are a number of reasons we did this…
Since it begun as a master thesis project I believe one of the main resasons for not inventing too many interface changes was the limited time available. Personally I am interested
in information visualisation and usability and have several thoughts regarding possible interface alternatives. Time/resources still remain constraining factors so focus is on geting a somewhat complete editor first (and debugging/stabilising existing archetypes & specifications underway). But feel free to experiment with and contribute alternative views as soon as we release the code.
Best regards,
Erik Sundvall (ex-supervisor of Mattias, but now a colleague)
Currently at MIE in Maastricht
This message was send too early because of the foreign keyboard layout,
Mattias Forss schreef:
This message was send too early because of the foreign keyboard layout,
excuse me for that, I will complete it now (please delete the previous)________
Thanks Mattias for your answer. I keep it short, now, the weather has
improved, and I am on holiday
French,
which causes me to search every character.Hi Bert,
Sorry if this mail looks wierd, but I had to copy it from the mail
archive on the openEHR website since I didn't get the mail for some
wierd reason. I only got Erik's answer about publising the source
code. Sometimes mails get lost when using the technical list and I
don't know what's causing the problem.Anyway, I look forward to having more Java developers working on the
editor and I hope it could improve the editor a lot more. Hopefully I
can be inspired by other people's code and learn new things as well as
come up with creative solutions.
I doubt if you will learn many new things. But the product is very good
and stable, and easy to handle. It showed me that it is possible to
write responsive and stable interfaces in Java. That is a good thing.
It will be of profit for the product to open source it. At this moment I
am very busy on a very tight deadline, but it could well be possible in
the near feature to work on the editor.
The reason we haven't published the code is mainly that the code is
not that good looking (it is actually quite ugly) in many places and I
guess some people will have a hard time understanding the code, but
good reasons to publish the code, I understand there is need for code
improvement. As long as the object orientation is clear, code can be
improved bit by bit.
there are also pieces of the code which are rather good. The quality
of the code may vary, but this is because we had limited time during
the Master thesis project and we decided to implement as much
functionality as possible instead of coding as neat as possible. This
was probably because we felt the need to fully complete the editor for
the final demonstration. When we started developing the pure
Java-based archetype editor we decided to use some existing code from
a Java archetype editor that was in development at the openEHR
repository. This editor used a wrapped Eiffel parser and that is why
it wasn't purely platform independantWe used (and modified) parts of the code from the existing editor
which was used as a facade against the openEHR archetype object model
since that model is immutable. On the other hand, I don't think that
this code is easy to understand even if you understand the API for the
Java kernel. When we open source the code for the editor I suppose
there might be questions if the facade code is worth using anymore or
if it should be replaced with a better API that could be used as a
facade for the archetype object model.
I don't know what you mean in this, I think the best way to write a
archetype editor is to directly use the java-kernel-code.
I see some people want to rewrite the adl-parser, but, in fact the
adl-parser is in its source quite clear and good.
For me it is necessary to work also outside the reference model, but in
ADL. It is a bit complicated to explain, Maybe read my previous mails.
So I need a archetype-editor which loads ADL-files, and does not enforce
or check the referene model. I translate HL7 XSD-files directly to ADL,
that is to say, I am working on that, and the improvements give hope.
The thing I miss is to viualize my ADL-files, so I have to check/debug
them manually, which is hard. I could use the code of the archetype
editor to change it for my needs, maybe it is not hard to do, but maybe
it is, as I read about ugly code now.
Except from my needs, which is at this moment, get a certain HL7 DMIM
into ADL, I would think it is a good thing when a ADL-editor has a
possibility for not to enforce the OpenEHR reference model. With all
respect to the design of that model (clever people work hard on it. I
sure want to follow that in the near future), I think it can be good if
it is possible if people have good reasons to do something else with
ADL, to facilitate that.
So in this context, I think publishing the code will be very good. I
hope it will be done in short time.
regards
Bert Verhees
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Mattias Forss schreef:
> We used (and modified) parts of the code from the existing editor
> which was used as a facade against the openEHR archetype object model
> since that model is immutable. On the other hand, I don't think that
> this code is easy to understand even if you understand the API for the
> Java kernel. When we open source the code for the editor I suppose
> there might be questions if the facade code is worth using anymore or
> if it should be replaced with a better API that could be used as a
> facade for the archetype object model.I don't know what you mean in this, I think the best way to write a
archetype editor is to directly use the java-kernel-code.
I see some people want to rewrite the adl-parser, but, in fact the
adl-parser is in its source quite clear and good.
We cannot use the kernel code directly unless we make changes to it to
be mutable (changeable). The reason for this is because whenever you
want to alter things, the Archetype object has to be rebuilt all over
again because it is not allowed to be changed. Using the kernel code
directly and rebuilding every time some small thing has changed would
be very slow (especially very slow response in the GUI). However, I've
heard of a new technique that could be used in Java to be able to do
this a lot faster, but I'm not sure if it will solve all the problems
in this case.
For me it is necessary to work also outside the reference model, but in
ADL. It is a bit complicated to explain, Maybe read my previous mails.So I need a archetype-editor which loads ADL-files, and does not enforce
or check the referene model. I translate HL7 XSD-files directly to ADL,
that is to say, I am working on that, and the improvements give hope.The thing I miss is to viualize my ADL-files, so I have to check/debug
them manually, which is hard. I could use the code of the archetype
editor to change it for my needs, maybe it is not hard to do, but maybe
it is, as I read about ugly code now.
This would require a feature in the editor to chose an "unknown"
reference model (which you can give a name) and maybe also specify
that reference model's semantics. It could be really messy working
with unknown reference models, and hard to come up good ways to
display things in a GUI. Since any rm type name can really constrain
any data type (text, boolean, date) even things there aren't any
corresponding controls for.
I have almost finished implementing an ADL-editor, (in the formats
view of the archetype editor) which could be used to edit whatever the
parser accepts, but whenever the ADL is reloaded in the GUI, all
things not corresponding to the openEHR RM (and things that aren't
recognized as editable in the GUI) will disappear. I believe you could
use this ADL-editor as a start, since it marks the line number that
the parser fails on, but the downside is of course that you would have
to do things manually. On the other hand, I don't think it's easy to
create efficient GUIs for unknown reference models, since class and
attribute names always have to be specified, unless of course one
creates a really smart GUI that follows defined RM semantics which
configures the widgets' functionality.
Regards,
Mattias
Mattias Forss schreef:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Mattias Forss schreef:
> We used (and modified) parts of the code from the existing editor
> which was used as a facade against the openEHR archetype object model
> since that model is immutable. On the other hand, I don't think that
> this code is easy to understand even if you understand the API for the
> Java kernel. When we open source the code for the editor I suppose
> there might be questions if the facade code is worth using anymore or
> if it should be replaced with a better API that could be used as a
> facade for the archetype object model.I don't know what you mean in this, I think the best way to write a
archetype editor is to directly use the java-kernel-code.
I see some people want to rewrite the adl-parser, but, in fact the
adl-parser is in its source quite clear and good.We cannot use the kernel code directly unless we make changes to it to
be mutable (changeable). The reason for this is because whenever you
want to alter things, the Archetype object has to be rebuilt all over
again because it is not allowed to be changed. Using the kernel code
directly and rebuilding every time some small thing has changed would
be very slow (especially very slow response in the GUI). However, I've
heard of a new technique that could be used in Java to be able to do
this a lot faster, but I'm not sure if it will solve all the problems
in this case.
I think there are other solutions. As I told you, I generate ADL files
from XSD-files, and I had about the same problem. Took me some time,
even did some experiments with using copy-objects, but finally I found it.
It takes some logic from the other way around thinking, but I think it
is possible to use the kernel-code and leave the Archetype-related
objects immutable.
I don't say it is exactly the same problem, but the point is, built your
objects, build your main-object, but just before it is finished, built
your attribute-objects, and just before they are finished, build your
children objects, and so on and on.
And when there is nothing to build at the bottom, you finish the
building of the higher in hierarchy objects, so go back on your steps,
and you end with finishing building your archetype object.
This all happens in memory and therefore has no big load on the process
time, and when it does take to much time, create a "Process
Changes"-button, to make the actual building of everything a
user-action. This then makes it also possible for synchronizing
GUI-objects and ADL, and allow working in ADL (which has, of course
then, syntax highlighting), and after the "Process Changes" update the
other GUI-parts, like your design-page, and also your GUI-builder, which
is a very nice feature.
For me it is necessary to work also outside the reference model, but in
ADL. It is a bit complicated to explain, Maybe read my previous mails.So I need a archetype-editor which loads ADL-files, and does not enforce
or check the referene model. I translate HL7 XSD-files directly to ADL,
that is to say, I am working on that, and the improvements give hope.The thing I miss is to viualize my ADL-files, so I have to check/debug
them manually, which is hard. I could use the code of the archetype
editor to change it for my needs, maybe it is not hard to do, but maybe
it is, as I read about ugly code now.This would require a feature in the editor to chose an "unknown"
reference model (which you can give a name) and maybe also specify
that reference model's semantics. It could be really messy working
with unknown reference models, and hard to come up good ways to
display things in a GUI. Since any rm type name can really constrain
any data type (text, boolean, date) even things there aren't any
corresponding controls for.
Yes, it is a challenge, and maybe I can do that on my own, and that way
better explain what I mean.
You are right, there must be some constraints, but they do not need to
be OpenEHR related. One could for example use it for other companies
with complex data-objects that need flexibility, but I must think about
that before I explain it further. It is just a fantasy.
But anyway, I need now to store the hundreds of CMETs which populate a
average DMIM, and translating XSD to ADL makes it possible to use
OpenEHR as storage machine for HL7, which it will be in a transition
phase. later we are going to model everything to the real OpenEHR
reference model. Which off course has many advantages above HL7. But in
fact, that is not my profession. I do not have much knowledge of medical
informatics. My wife has, but until yet it did not seem to be
contagious. So I leave that to someone else who has very wise thoughts
about that. But we are in a hurry, that is why I generate most of the
code, and make a HL7 storage machine, which takes much less time then
model a OpenEHR information model, and stick it together.
I have almost finished implementing an ADL-editor, (in the formats
view of the archetype editor) which could be used to edit whatever the
parser accepts, but whenever the ADL is reloaded in the GUI, all
things not corresponding to the openEHR RM (and things that aren't
recognized as editable in the GUI) will disappear. I believe you could
use this ADL-editor as a start, since it marks the line number that
the parser fails on, but the downside is of course that you would have
to do things manually. On the other hand, I don't think it's easy to
create efficient GUIs for unknown reference models, since class and
attribute names always have to be specified, unless of course one
creates a really smart GUI that follows defined RM semantics which
configures the widgets' functionality.
Sorry, I talk to much, but you are right, there are some challenges to
be solved, which give the thing new possibilities. I like to work on
that, in the near future. It will be a unique piece of software. Also
the possibility to import XSD, will be good. Who will ever need XMI
again, which never is really accepted as a standard, every vendor
fantasizes his own extension, in a hurry to let no one share has
objects. OMG made a exchangeable object-language, and everyone uses it
to exclude other vendors. ADL is not only exchangeable, but also better,
because it has the possibility to exchange semantics and terminologies
also, and as you do, create rudimentary interfaces. There must be more
market for this, except from the medical market.
OK, I leave it here, and stop dreaming, and do what I am supposed to do
for the next few weeks. I hope the source code will be published soon. I
can build it on my own, but it is too much effort, and why do something
which is already done.
Regards
Bert Verhees