# More doubts about assertions **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2006-08-24 18:20 UTC **Views:** 4 **Replies:** 13 **URL:** https://discourse.openehr.org/t/more-doubts-about-assertions/14568 --- ## Post #1 by @Rodrigo_Filgueira1 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 --- ## Post #2 by @thomas.beale 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 --- ## Post #3 by @Rodrigo_Filgueira1 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: --- ## Post #4 by @minreddy_minreddy 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 --- ## Post #5 by @Mattias_Forss1 There is already a Java-based archetype editor available here: [http://svn.openehr.org/knowledge/archetypes/dev/index.html](http://svn.openehr.org/knowledge/archetypes/dev/index.html) Regards, Mattias Forss 2006/8/27, minreddy minreddy <[minreddy@yahoo.com](mailto:minreddy@yahoo.com)>: --- ## Post #6 by @system > 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 \(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 --- ## Post #7 by @Mattias_Forss1 2006/8/28, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > > There is already a Java-based archetype editor available here: > > > > [http://svn.openehr.org/knowledge/archetypes/dev/index.html](http://svn.openehr.org/knowledge/archetypes/dev/index.html) > > 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 --- ## Post #8 by @system 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.html >> >> 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\. 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 --- ## Post #9 by @system 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\) --- ## Post #10 by @erik.sundvall > 2006/8/28, Bert Verhees <[bert.verhees@rosa.nl](mailto:bert.verhees@rosa.nl)>: > > > > There is already a Java-based archetype editor available here: > > > [http://svn.openehr.org/knowledge/archetypes/dev/index.html](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 --- ## Post #11 by @Mattias_Forss1 > This message was send too early because of the foreign keyboard layout, --- ## Post #12 by @system 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 ;\-\) and the keyboard\-layout still is >> 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 independant > > 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\. 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 --- ## Post #13 by @Mattias_Forss1 > \-\-\-\-\-BEGIN PGP SIGNED MESSAGE\-\-\-\-\- > Hash: SHA1 > > Mattias 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 --- ## Post #14 by @system Mattias Forss schreef: >> \-\-\-\-\-BEGIN PGP SIGNED MESSAGE\-\-\-\-\- >> Hash: SHA1 >> >> Mattias 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 --- **Canonical:** https://discourse.openehr.org/t/more-doubts-about-assertions/14568 **Original content:** https://discourse.openehr.org/t/more-doubts-about-assertions/14568