How about creating an openEHR test base?
Hi Seref, Can you put a small reference of Bosphorus services on the wiki page: http://www.openehr.org/wiki/display/dev/Development+test+base I've added some thoughts about artifact access services there. Thanks a lot! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 11 May 2012 01:04:03 +0100 Subject: Re: How about creating an openEHR test base? From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Pablo, Let me first say that I really appreciate all the constructive discussions you've initiated, and your work. To be honest, I was hoping that my points sould ring other bells :) Open source licenses are quite different beasts, and their combinations in projects is a nightmare. If you take licences seriously (which we'd better do), you can end up in some pretty frustrating situations, where you can use someone else's code, but can't distribute it with your work, etc etc. I have no objection to exposing services, remember Bosphorus? It is happily running as a service out there for some months now. However, to work together, we need to handle licensing issues. I'm going to move Opereffa to Apache 2.0. Shinji has done the same. I do not want to push anyone towards a particular open source license, but I'd at least like to know the licenses of all projects that would be included in what you're suggesting. Believe me, I understand the urge to actually do stuff, I share the same urge, but at this day and age, one can never be too careful about licensing. Seeing what you're trying to do, I just wanted to save you from a lot of headache :) Kind regards Seref On Fri, May 11, 2012 at 12:42 AM, pablo pazos pazospablo at hotmail.com wrote: Hi guys, Seref, I was thinking a lot about what you said There are various bits of functionality implemented in different projects..., and that rang a bell somewhere. I think we are implementing the same things again and again because the technology we choose can't handle what is already implemented, and I believe this is a great opportunity to start creating common services providing this funcionality to our systems, so we only implement service clients not the same functionality in an alternative way. There is a great deal of functionality developed by Rong company (and other projects, .Net, Ruby, ...), and some of the functionality can be exposed as public services somewhere (like archetype flattening, AOM 2 ADL serialization, RM 2 XML serialization, etc.). Is there some posibility that the foundation could host those services? What do you think? I'm willing to dedicate time to this, because I think this will be beneficial for all (also for creating the proposed test set that started this topic). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120515/894ea9eb/attachment.html
How about creating an openEHR test base?
From a licencing view, you are correct!!From a ENCOURAGING PERSPECTIVE, you must declare your position: you are selling?? fantastic, then the service and product is well defined.But if you use the term openehr as a marketing tool, then you must be able to see the meaning of collective goods and personal benefits. The community of openehr is a great asset to our societies, and we need sellers, intellectual and great people like you. But as my work is defined as a collective impact, I strongly recommend that the SELLERS must declare the price and products functionality. In our region, people believe that openehr only belongs to sellers that is not the case. Cheers Carol Date: Sat, 12 May 2012 13:14:57 +0100 Subject: Re: How about creating an openEHR test base? From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Dear Carol, Every tangible (as tangible as knowledge based artefacts can be) aspect of this discussion is subject to a license, ranging from Mozilla to Apache 2.0 These licenses allow their users to reap the benefits of these items in any way they see fit, maybe with some constraints related to the licensed entity. So if Pablo uses his knowledge and the collective effort to make money, he is not introducing any conflicts. He is absolutely free to do so, and I'd personally like to see him do it. Unless I'm wrong with the current state of things, as long as an individual complies with the published terms and conditions related to openEHR, they're free to do whatever they want to Best regards Seref On Sat, May 12, 2012 at 12:56 PM, Dra Carola Hullin Lucay Cossio carolhullin at hotmail.com wrote: Dear All, I have been reading all the posting from all the internacional community of openehr.It is confusing at times and some clarity appears too. My contribution is in regards to Just to let you know my personal agenda :D I need to do this to encourage openEHR adoption here in South America From my perspective: Brasil is already encouraging the use of openehr and others countries are using too, specially from a public and collective benefits. The conflict of interest is when PERSONALLY this knowledge is used as a product to sell and make money transfer from a collective good without an aggremment. For example, in Chile, a course was offered to the members with a cost, great beginning. I was very happy that THE ENCOURAGEMENT STARTED..however, the approach used last year confused the collective groups since at this side of the world (Chile) , the archetypes were introduced at the goverment level in 2006 by ocean informatics as a powerful tool of integration ( with a very different level of wisdom). So, my recommendation for this area of developing countries is to provide some encouragement BUT always engaged with the wisdom first, meaning if we all want openehr to be successful ensure a strong collaboration at SELLING POINT, that is the add value of openehr. When a PERSONAL wish cross the collective good, there is room for error as expect but when previous work is not acknowledge in the same country, you will run to RESISTANT that is what is happening in Latino America and Caribe. Cheers Carol IMIA LAC President,PhD, Post Doc Health Informatics Date: Sat, 12 May 2012 17:51:10 +0900 Subject: Re: How about creating an openEHR test base? From: skoba at moss.gr.jp To: openehr-technical at lists.openehr.org Hi Pablo, Seref and all, I think many implementation on the same API would make competitive and innovative environment. While re-invention of wheel is considered as waste of time, implementation by many ways sometimes makes innovation. Ruby on Rails is a web development framework, which affect many development framework, but web frameworks has been generated before/after RoR. All of them aim to product Web with ease, but approaches are not same. I am glad to have such environment with you on the openEHR. Licensing is a sensitive matter to share artefacts. It subjects not only code bases, but also on API like Oracle/Google issues. However, my artefacts are under Apache 2.0 or other open licenses. Cheers, Shinji. 2012/5/11 pablo pazos pazospablo at hotmail.com: Hi guys, Seref, I was thinking a lot about what you said There are various bits of functionality implemented in different projects..., and that rang a bell somewhere. I think we are implementing the same things again and again because the technology we choose can't handle what is already implemented, and I believe this is a great opportunity to start creating common services providing this funcionality to our systems, so we only implement service clients not the same functionality in an alternative way. There is a great deal of functionality developed by Rong company (and other projects, .Net, Ruby, ...), and some of the functionality can be exposed as public services
How about creating an openEHR test base?
Hi Pablo, Seref and all, I think many implementation on the same API would make competitive and innovative environment. While re-invention of wheel is considered as waste of time, implementation by many ways sometimes makes innovation. Ruby on Rails is a web development framework, which affect many development framework, but web frameworks has been generated before/after RoR. All of them aim to product Web with ease, but approaches are not same. I am glad to have such environment with you on the openEHR. Licensing is a sensitive matter to share artefacts. It subjects not only code bases, but also on API like Oracle/Google issues. However, my artefacts are under Apache 2.0 or other open licenses. Cheers, Shinji. 2012/5/11 pablo pazos pazospablo at hotmail.com: Hi guys, Seref, I was thinking a lot about what you said There are various bits of functionality implemented in different projects..., and that rang a bell somewhere. I think we are implementing the same things again and again because the technology we choose can't handle what is already implemented, and I believe this is a great opportunity to start creating common services providing this funcionality to our systems, so we only implement service clients not the same functionality in an alternative way. There is a great deal of functionality developed by Rong company (and other projects, .Net, Ruby, ...), and some of the functionality can be exposed as public services somewhere (like archetype flattening, AOM 2 ADL serialization, RM 2 XML serialization, etc.). Is there some posibility that the foundation could host those services? What do you think? I'm willing to dedicate time to this, because I think this will be beneficial for all (also for creating the proposed test set that started this topic). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 8 May 2012 08:52:04 +0100 Subject: Re: How about creating an openEHR test base? From: serefarikan at kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Interesting point again. There are various bits of functionality implemented in different projects, but the projects have different open source licences. I'm not Rong of course, but his code uses mpl, and since I've used his code when I started Operaffa, Opereffa is mpl too (though it'll be apache very soon). So you'd need to check how licensing issues need to be handled if you use Rong's code, assuming your work is not under mpl. I think you've touched another important point Pablo Kind regards Seref On Mon, May 7, 2012 at 10:37 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Rong, That's great news, but we have our own RM implementation because it handles ORM too. But I think I can adapt your xml-binding component to use our RM impl, what do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 7 May 2012 21:08:57 +0200 Subject: Re: How about creating an openEHR test base? From: rong.acode at gmail.com To: openehr-technical at lists.openehr.org On 7 May 2012 16:39, pablo pazos pazospablo at hotmail.com wrote: Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. Hi Pablo, The xml-binding component in the Java reference implementation does just that. It binds RM object instance to generated XML objects that can be serialized according to published XSD. /Rong ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
How about creating an openEHR test base?
Dear Carol, Every tangible (as tangible as knowledge based artefacts can be) aspect of this discussion is subject to a license, ranging from Mozilla to Apache 2.0 These licenses allow their users to reap the benefits of these items in any way they see fit, maybe with some constraints related to the licensed entity. So if Pablo uses his knowledge and the collective effort to make money, he is not introducing any conflicts. He is absolutely free to do so, and I'd personally like to see him do it. Unless I'm wrong with the current state of things, as long as an individual complies with the published terms and conditions related to openEHR, they're free to do whatever they want to Best regards Seref On Sat, May 12, 2012 at 12:56 PM, Dra Carola Hullin Lucay Cossio carolhullin at hotmail.com wrote: Dear All, I have been reading all the posting from all the internacional community of openehr. It is confusing at times and some clarity appears too. My contribution is in regards to Just to let you know my personal agenda :D I need to do this to encourage openEHR adoption here in South America From my perspective: Brasil is already encouraging the use of openehr and others countries are using too, specially from a public and collective benefits. The conflict of interest is when PERSONALLY this knowledge is used as a product to sell and make money transfer from a collective good without an aggremment. For example, in Chile, a course was offered to the members with a cost, great beginning. I was very happy that THE ENCOURAGEMENT STARTED..however, the approach used last year confused the collective groups since at this side of the world (Chile) , the archetypes were introduced at the goverment level in 2006 by ocean informatics as a powerful tool of integration ( with a very different level of wisdom). So, my recommendation for this area of developing countries is to provide some encouragement BUT always engaged with the wisdom first, meaning if we all want openehr to be successful ensure a strong collaboration at SELLING POINT, that is the add value of openehr. When a PERSONAL wish cross the collective good, there is room for error as expect but when previous work is not acknowledge in the same country, you will run to RESISTANT that is what is happening in Latino America and Caribe. Cheers Carol IMIA LAC President, PhD, Post Doc Health Informatics Date: Sat, 12 May 2012 17:51:10 +0900 Subject: Re: How about creating an openEHR test base? From: skoba at moss.gr.jp To: openehr-technical at lists.openehr.org Hi Pablo, Seref and all, I think many implementation on the same API would make competitive and innovative environment. While re-invention of wheel is considered as waste of time, implementation by many ways sometimes makes innovation. Ruby on Rails is a web development framework, which affect many development framework, but web frameworks has been generated before/after RoR. All of them aim to product Web with ease, but approaches are not same. I am glad to have such environment with you on the openEHR. Licensing is a sensitive matter to share artefacts. It subjects not only code bases, but also on API like Oracle/Google issues. However, my artefacts are under Apache 2.0 or other open licenses. Cheers, Shinji. 2012/5/11 pablo pazos pazospablo at hotmail.com: Hi guys, Seref, I was thinking a lot about what you said There are various bits of functionality implemented in different projects..., and that rang a bell somewhere. I think we are implementing the same things again and again because the technology we choose can't handle what is already implemented, and I believe this is a great opportunity to start creating common services providing this funcionality to our systems, so we only implement service clients not the same functionality in an alternative way. There is a great deal of functionality developed by Rong company (and other projects, .Net, Ruby, ...), and some of the functionality can be exposed as public services somewhere (like archetype flattening, AOM 2 ADL serialization, RM 2 XML serialization, etc.). Is there some posibility that the foundation could host those services? What do you think? I'm willing to dedicate time to this, because I think this will be beneficial for all (also for creating the proposed test set that started this topic). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 8 May 2012 08:52:04 +0100 Subject: Re: How about creating an openEHR test base? From: serefarikan at kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Interesting point
How about creating an openEHR test base?
Hi Carola, Dear All, I have been reading all the posting from all the internacional community of openehr.It is confusing at times and some clarity appears too. My contribution is in regards to Just to let you know my personal agenda :D I need to do this to encourage openEHR adoption here in South America From my perspective: Brasil is already encouraging the use of openehr and others countries are using too, specially from a public and collective benefits. And that's a good start, but we all want to collaborate to get further adoption in public, private and education areas too. The conflict of interest is when PERSONALLY this knowledge is used as a product to sell and make money transfer from a collective good without an aggremment. At some point adoption means that someone has to do some work, and that work takes time of someones life, someone that has to eat, pay bills, etc. So money will be always involved in this kinds of things, these are the rules of the game... someone has to work and someone has to pay, and what is created in the middle should be something of value for many people, that's the only sustainable approach I can think. I'll be very happy if someone can think of something better, in the mean time I'll keep working forward adoption with a sustainable approach. I've talked a lot about the adoption problems of openEHR, and we always fall into the funding problem. And that's a problem: we don't have a sustainable approach to adoption. For example, in Chile, a course was offered to the members with a cost, great beginning. I was very happy that THE ENCOURAGEMENT STARTED..however, the approach used last year confused the collective groups since at this side of the world (Chile) , the archetypes were introduced at the goverment level in 2006 by ocean informatics as a powerful tool of integration ( with a very different level of wisdom). I think you know that I've created that course, and this is the first time I heard about any confusion. For the student recommendations (see my linkedin profile) and outputs we received (http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html) I don't think they where confused at all, and ACHISA (http://achisa.org) members where very happy about that course adn they encourage me to give a second edition (what I'm doing right now, with a very good reception by students). So, my recommendation for this area of developing countries is to provide some encouragement BUT always engaged with the wisdom first, meaning if we all want openehr to be successful ensure a strong collaboration at SELLING POINT, that is the add value of openehr. When a PERSONAL wish cross the collective good, there is room for error as expect but when previous work is not acknowledge in the same country, you will run to RESISTANT that is what is happening in Latino America and Caribe. Don't take me wrong, but IMO you are confusing various concepts here, about what I want to do and how to do it. I think others (who know me, my work and how I work) don't think the same way. First of all, this is not a political discusion, is about what we need to do to get things done, and what resources we need to have that done. Second, my personal intentions are meant for a collective good, as an example I take money from the course I gave, to create an openEHR portal in spanish, and I've done all the work to put it online (including software development, community management, etc...). I also ask the openEHR community BEFORE doing anything, like the openEHR course, and everyone encourages it and I never receive any complain about it. As I see it, that's a declaration of intention, and the community gave me their approval. I'm always willing to give everyone the guarantees they need. Third, I'm always encouraging collaboration and doing things together, but in South America there is a resistances before start, the problem is the political part, not the technical, and I'm a technician trying to convince politicians. And just to be clear: I don't sell software: almost all my projects are open source, I don't work for a company or organization: I'm an independent researcher developer, from time to time I help companies to get things done, and I love to teach: bring what I learn to the community. I would like to know the community opinions about this topic, as I don't want to step in anyone's shoe. Kind regards,Pablo. Cheers Carol IMIA LAC President,PhD, Post Doc Health Informatics -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120512/2ed844d0/attachment-0001.html
How about creating an openEHR test base?
Pablo, Let me first say that I really appreciate all the constructive discussions you've initiated, and your work. To be honest, I was hoping that my points sould ring other bells :) Open source licenses are quite different beasts, and their combinations in projects is a nightmare. If you take licences seriously (which we'd better do), you can end up in some pretty frustrating situations, where you can use someone else's code, but can't distribute it with your work, etc etc. I have no objection to exposing services, remember Bosphorus? It is happily running as a service out there for some months now. However, to work together, we need to handle licensing issues. I'm going to move Opereffa to Apache 2.0. Shinji has done the same. I do not want to push anyone towards a particular open source license, but I'd at least like to know the licenses of all projects that would be included in what you're suggesting. Believe me, I understand the urge to actually do stuff, I share the same urge, but at this day and age, one can never be too careful about licensing. Seeing what you're trying to do, I just wanted to save you from a lot of headache :) Kind regards Seref On Fri, May 11, 2012 at 12:42 AM, pablo pazos pazospablo at hotmail.comwrote: Hi guys, Seref, I was thinking a lot about what you said There are various bits of functionality implemented in different projects..., and that rang a bell somewhere. I think we are implementing the same things again and again because the technology we choose can't handle what is already implemented, and I believe this is a great opportunity to start creating common services providing this funcionality to our systems, so we only implement service clients not the same functionality in an alternative way. There is a great deal of functionality developed by Rong company (and other projects, .Net, Ruby, ...), and some of the functionality can be exposed as public services somewhere (like archetype flattening, AOM 2 ADL serialization, RM 2 XML serialization, etc.). Is there some posibility that the foundation could host those services? What do you think? I'm willing to dedicate time to this, because I think this will be beneficial for all (also for creating the proposed test set that started this topic). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos -- Date: Tue, 8 May 2012 08:52:04 +0100 Subject: Re: How about creating an openEHR test base? From: serefarikan at kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Interesting point again. There are various bits of functionality implemented in different projects, but the projects have different open source licences. I'm not Rong of course, but his code uses mpl, and since I've used his code when I started Operaffa, Opereffa is mpl too (though it'll be apache very soon). So you'd need to check how licensing issues need to be handled if you use Rong's code, assuming your work is not under mpl. I think you've touched another important point Pablo Kind regards Seref On Mon, May 7, 2012 at 10:37 PM, pablo pazos pazospablo at hotmail.comwrote: Hi Rong, That's great news, but we have our own RM implementation because it handles ORM too. But I think I can adapt your xml-binding component to use our RM impl, what do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos Date: Mon, 7 May 2012 21:08:57 +0200 Subject: Re: How about creating an openEHR test base? From: rong.acode at gmail.com To: openehr-technical at lists.openehr.org On 7 May 2012 16:39, pablo pazos pazospablo at hotmail.com wrote: Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. Hi Pablo, The xml-binding component in the Java reference implementation does just that. It binds RM object instance to generated XML objects that can be serialized according to published XSD. /Rong ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
How about creating an openEHR test base?
Hi Rong, I've updated my java-ref-impl from SVN: http://www.openehr.org/svn/ref_impl_javaI builded it and generated the jars: xxx-1.0.2-SNAPSHOT.jar Is the version 1.0.2-SNAPSHOT correct? I remember I builded this a long time ago and was generating the same version. I will try the archetype flattener with the suggestions made by Thomas in another topic:http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007023.html I have a question about the flattener.If you see: http://www.openehr.org/svn/ref_impl_java/TRUNK/oet-parser/src/test/resources/archetypes/openEHR-EHR-COMPOSITION.prescription_flattened.v1.adlIt doesn't have the reference to the resolved slots, instead it has at for all those nodes and doesn't resolve the ontology part to include referenced terms.The suggestion made by Thomas is to replace the nodeId with the archetypeId on the resolved slots, and put the ontology terms of the resolved archetypes in the flattened archetype ontology.Do you think this should be corrected on the flattener? (I don't know if this is a bug or this is the expected behaviour and the reference to the slots and ontologies are resolved in some other way). Then I'll try the adl-serialized to generate full adl archetypes. The last thing I want to try is the xml-serializer for RM instances. I'll put the results here: http://www.openehr.org/wiki/display/dev/Development+test+base -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 8 May 2012 15:31:25 +0200 Subject: Re: How about creating an openEHR test base? From: rong.acode at gmail.com To: openehr-technical at lists.openehr.org On 7 May 2012 23:37, pablo pazos pazospablo at hotmail.com wrote: Hi Rong, That's great news, but we have our own RM implementation because it handles ORM too. But I think I can adapt your xml-binding component to use our RM impl, what do you think? Pablo, The xml-binding component leverages the annotated constructors in the RM classes for instantiating RM objects. It uses reflections extensively. Take a look of the XMLBinding class for some inspiration. I am sure you can adapt it for your own classes. /Rong ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120510/dd0a0a6c/attachment.html
How about creating an openEHR test base?
Hi guys, Seref, I was thinking a lot about what you said There are various bits of functionality implemented in different projects..., and that rang a bell somewhere. I think we are implementing the same things again and again because the technology we choose can't handle what is already implemented, and I believe this is a great opportunity to start creating common services providing this funcionality to our systems, so we only implement service clients not the same functionality in an alternative way. There is a great deal of functionality developed by Rong company (and other projects, .Net, Ruby, ...), and some of the functionality can be exposed as public services somewhere (like archetype flattening, AOM 2 ADL serialization, RM 2 XML serialization, etc.). Is there some posibility that the foundation could host those services? What do you think? I'm willing to dedicate time to this, because I think this will be beneficial for all (also for creating the proposed test set that started this topic). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 8 May 2012 08:52:04 +0100 Subject: Re: How about creating an openEHR test base? From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Interesting point again. There are various bits of functionality implemented in different projects, but the projects have different open source licences. I'm not Rong of course, but his code uses mpl, and since I've used his code when I started Operaffa, Opereffa is mpl too (though it'll be apache very soon). So you'd need to check how licensing issues need to be handled if you use Rong's code, assuming your work is not under mpl. I think you've touched another important point Pablo Kind regards Seref On Mon, May 7, 2012 at 10:37 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Rong, That's great news, but we have our own RM implementation because it handles ORM too.But I think I can adapt your xml-binding component to use our RM impl, what do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 7 May 2012 21:08:57 +0200 Subject: Re: How about creating an openEHR test base? From: rong.acode at gmail.com To: openehr-technical at lists.openehr.org On 7 May 2012 16:39, pablo pazos pazospablo at hotmail.com wrote: Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. Hi Pablo, The xml-binding component in the Java reference implementation does just that. It binds RM object instance to generated XML objects that can be serialized according to published XSD. /Rong ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120510/af51239b/attachment.html
How about creating an openEHR test base?
Hi Seref, About licensing, I think Software as a Service is a more flexible approach than source code / library reuse, because we are just users of the service, we don't distribute it with our projects. And to use the code to create services, we must have written permission from the owner. Maybe I'm over simplifying the problem. BTW our project is Apache 2.0 http://code.google.com/p/open-ehr-gen-framework/ so I think sometime we can talk about what we have and what parts can be abstracted as services, but that's for another discussion topic. Just to let you know my personal agenda :D I need to do this to encourage openEHR adoption here in South America. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 11 May 2012 01:04:03 +0100 Subject: Re: How about creating an openEHR test base? From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Pablo, Let me first say that I really appreciate all the constructive discussions you've initiated, and your work. To be honest, I was hoping that my points sould ring other bells :) Open source licenses are quite different beasts, and their combinations in projects is a nightmare. If you take licences seriously (which we'd better do), you can end up in some pretty frustrating situations, where you can use someone else's code, but can't distribute it with your work, etc etc. I have no objection to exposing services, remember Bosphorus? It is happily running as a service out there for some months now. However, to work together, we need to handle licensing issues. I'm going to move Opereffa to Apache 2.0. Shinji has done the same. I do not want to push anyone towards a particular open source license, but I'd at least like to know the licenses of all projects that would be included in what you're suggesting. Believe me, I understand the urge to actually do stuff, I share the same urge, but at this day and age, one can never be too careful about licensing. Seeing what you're trying to do, I just wanted to save you from a lot of headache :) Kind regards Seref On Fri, May 11, 2012 at 12:42 AM, pablo pazos pazospablo at hotmail.com wrote: Hi guys, Seref, I was thinking a lot about what you said There are various bits of functionality implemented in different projects..., and that rang a bell somewhere. I think we are implementing the same things again and again because the technology we choose can't handle what is already implemented, and I believe this is a great opportunity to start creating common services providing this funcionality to our systems, so we only implement service clients not the same functionality in an alternative way. There is a great deal of functionality developed by Rong company (and other projects, .Net, Ruby, ...), and some of the functionality can be exposed as public services somewhere (like archetype flattening, AOM 2 ADL serialization, RM 2 XML serialization, etc.). Is there some posibility that the foundation could host those services? What do you think? I'm willing to dedicate time to this, because I think this will be beneficial for all (also for creating the proposed test set that started this topic). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 8 May 2012 08:52:04 +0100 Subject: Re: How about creating an openEHR test base? From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Interesting point again. There are various bits of functionality implemented in different projects, but the projects have different open source licences. I'm not Rong of course, but his code uses mpl, and since I've used his code when I started Operaffa, Opereffa is mpl too (though it'll be apache very soon). So you'd need to check how licensing issues need to be handled if you use Rong's code, assuming your work is not under mpl. I think you've touched another important point Pablo Kind regards Seref On Mon, May 7, 2012 at 10:37 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Rong, That's great news, but we have our own RM implementation because it handles ORM too.But I think I can adapt your xml-binding component to use our RM impl, what do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 7 May 2012 21:08:57 +0200 Subject: Re: How about creating an openEHR test base? From: rong.acode at gmail.com To: openehr-technical at lists.openehr.org On 7 May 2012 16:39, pablo pazos pazospablo at hotmail.com wrote: Hi Seref, I've a tool that generates composition instances from
How about creating an openEHR test base?
Hi Erik, I think that using an EHR service to store RM instances would be better than storing in SVN or GIT. Ultimately if the service was able to work from a GIT repository we would have the best of both worlds. I had considered offering the Ocean EHR server but I assumed the usual issues relating to the commercial backend would have made this not suitable so I didn't bother. Would your service be an alternative, especially since it is RESTful? Perhaps there is a need for multiple service implementations to be available working from the same instance repository, I am sure each have their strengths and weaknesses and interface approaches. For example the ocean EHR service picked up a data validation error reported on the list that another didn't. We can also use this to start comparing service models. Heath On 07/05/2012 4:32 PM, Erik Sundvall erik.sundvall at liu.se wrote: Hi! I agree that we need some RM instances etc initially. We have versioned compositions in the demo server for our LiU EEE-system. We don't know if they are 100% according to spec since they have not been extensively tested. I'll upload some of them to the wikipage after a deadline I have this week (remind me if they are not there next monday ;-) I can give a limited number of people access to them now via REST-interfaces (HTTP via a browser works fine). Mail me off-list if you are in a hurry. Would EHR-data reflecting a number realistic patient stories be interesting to collaborate on as a second step? I am in desperate need of such EHR data in order to create and test EHR-visualisations. Getting real patient data is a pain to get access to and if we get it we can never share it. Could we share the effort of creating a number of such EHR instances (and perhaps write a shared academic paper about it) - If so let's first check/discuss some of the options for data entry and once that is fixed we can involve more clinicians to create and improve/review the stories. A shared set could be reused in several projects and make them more comparable too. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Mon, May 7, 2012 at 12:48 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Diego Peter, What Diego said about evolving tests for ADL1.5 is true, we don't want to test the tools or the specs, we want to test our implementations (EHRs, services, repositories, etc). I agree this overlaps in some way with the CKM content (archetypes and templates), but our focus is on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know waht I mean. I agree what Diego said in the last message: we want RM instances (XML) in the repo, which will be valid against XSDs (that we need to test and fix, XSDs will be included in the repo too). JSON instances will be welcome too :D To give more context, this is taken from a private message to Erik: What I have in mind is to create something like a unit test for openEHR applications and services, with archetypes, rm instances and term sets. E.g. having a test set with some archetypes, a template, some term sets and a couple of instances in xml and json formats, and create some small software that can handle those test sets, validating instances to schemas, validating structures to archetypes, etc. and maybe geting data from the instances and doing something with it, -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: yampeku at gmail.com Date: Mon, 7 May 2012 00:23:44 +0200 Subject: Re: How about creating an openEHR test base? To: openehr-technical at lists.openehr.org Pablo also mentioned 'RM instances in a variety of formats', which are not 'artefacts'. 2012/5/7 Peter Gummer peter.gummer at oceaninformatics.com: Diego Bosc? wrote: I would say the scope of that repository is different, as that is part of the test for current evolving 1.5 syntax and does not include 'real' archetypes My understanding was that Pablo was not proposing real archetypes either. In his original post, Pablo proposed a test base with sample artifacts. How would this be different from the purpose of the existing http://www.openehr.org/svn/knowledge2 repository? The only difference that I can see is that Pablo has proposed adding a greater variety of artefacts (OPTs, etc.), so it seems natural to add them to the existing repository. - Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr
How about creating an openEHR test base?
Hi Pablo, What issues do you have with the XSD? We have been producing valid instances for years. I have tools that can validate these in seconds. I am sitting on hundreds of test instances. Problem is I am not sitting around with nothing to do. If you have a student willing to do some dot NET code with little support you can go to openehr.codeplex.com to get what you need to create and validate openehr instances against OPTs and RM. BTW, I have a local xsd that further constrains the published schema that picks up several additional RM invariants. Happy to contribute this but don't want to confuse the status of the official schema. I also have a demographic schema which I believe is currently not part of the current openEHR release. Heath On 08/05/2012 12:09 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. In order to do that, we should resolve current reported issues with the XSDs (see my first email), and then generate XMLs, at first maybe by hand, later integrated into tools. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos -- Date: Mon, 7 May 2012 15:26:28 +0100 Subject: Re: How about creating an openEHR test base? From: serefarikan at kurumsalteknoloji.com To: openehr-technical at lists.openehr.org I don't have the time to do what I'm going to suggest next, but if someone has time in their hands, I'd suggest writing a tool that will automatically generate valid XML RM documents, such as compositions etc. Archetypes and templates define boundaries of all valid instances of clinical models, and one can generate random instances that belong to this set. Opereffa's current version supports this, but not with XML output. I used this approach to test performance of persistence options If our argument is that all the clinical information can be represented via models, why should be create RM instances by hand? Regards Seref On Mon, May 7, 2012 at 3:05 PM, pablo pazos pazospablo at hotmail.comwrote: Hi Thomas, just to be sure we are on the same page: From previous emails: *What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept).* * * *We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean.* JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs, 2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too, 4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results, 6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards, Pablo. -- Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? * * My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool
How about creating an openEHR test base?
Seref, I think meaningful data is more useful than random maximal or minimal data. I think that using the template data schema approach could be an easier way to produce data by hand if a GUI is not available but I am assuming this is not the case for Pablo. The Ocean Template Designer is free to download, TDS can be generated, some work using a good XML tool can produce an instance fairly quickly. The TDD to openEHR transform is available on openehr.codeplex.com, you can use you language of choice to load the instance into an XML DOM, validate it against the schema to inject the default and fixed values and transform to openEHR. From there you will need a bit more OPT and RM validation but you will be 90% of the way (especially if you use my further constrained version of basetypes.xsd, which I might make available on codeplex along with the transform). Heath On 07/05/2012 11:56 PM, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: I don't have the time to do what I'm going to suggest next, but if someone has time in their hands, I'd suggest writing a tool that will automatically generate valid XML RM documents, such as compositions etc. Archetypes and templates define boundaries of all valid instances of clinical models, and one can generate random instances that belong to this set. Opereffa's current version supports this, but not with XML output. I used this approach to test performance of persistence options If our argument is that all the clinical information can be represented via models, why should be create RM instances by hand? Regards Seref On Mon, May 7, 2012 at 3:05 PM, pablo pazos pazospablo at hotmail.comwrote: Hi Thomas, just to be sure we are on the same page: From previous emails: *What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept).* * * *We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean.* JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs, 2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too, 4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results, 6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards, Pablo. -- Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? * * My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful, because it lacks too many basic semantics - particularly dynamic type markers. Its cousin YAML is over-complicated (and in its whitespace form, nearly impossible to get right!), but does have proper OO semantics and I think can be used as a lossless serialisation. Others may have more evolved ideas on how
How about creating an openEHR test base?
Pablo, This is a good list, I have already commented on 1-3 and I am also interested 4-6. I think a JSON format project would be good to make sure we get consistency earlier than later, it is not like XML where you can publish a schema and I suspect various toolkits will have their variations. Producing test data is a time consuming effort, producing valid instance is easy enough but at present clinical archetypes are still moving so these get out of date quickly. The real work is developing know bad instances, because there are so many ways something can be bad. So we need to define the scope of this effort and perhaps using the test archetypes on openEHR is not a bad approach as these may be more stable than the clinical archetypes at this point. Having said that, perhaps as part of the CKM review process we can produce test instances that can be made available to CKM users and developers alike, this could be done at any stage of the review process, not just at completion. Interoperability testing is extremely important, the IHE process demonstrates the benefits of this. I have done this with Rong several years ago and we found a few slight variations and assumptions that we needed to correlate, again I think we should do this sooner than later before we have too many systems installed with their own set of assumptions. This really needs resourcing but I think it should be the vendors that do this since ultimately they will be beneficiary of having an openEHR compatible system, but we do need some governance and tooling to support this process so we need some additional contributions to kick start the process. I think your initiative is a really good start, it is certainly not a new idea but you're making it happen, keep it up. Regards Heath From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of pablo pazos Sent: Monday, 7 May 2012 11:36 PM To: openeh technical Subject: RE: How about creating an openEHR test base? Hi Thomas, just to be sure we are on the same page: From previous emails: What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept). We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean. JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs, 2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too, 4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results, 6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards, Pablo. _ Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful
openEHR on GitHub (was Re: How about creating an openEHR test base?)
Hi Thomas Beale, Our, Ruby implementation repository has already moved on GitHub for our convenience last year for our convenience. I was wondering if we could move our repository under github://openehr/ruby-impl-openhr. It would be comprehensive rather than under skoba/ruby-impl-openehr for publicity. Regards, Shinji Kobayashi 2012/5/7 Thomas Beale thomas.beale at oceaninformatics.com: yes, we will obviously migrate over to Github in the coming months. I have a slight concern about how to avoid chaos, and I do think we need to think carefully about how we organise Git projects/subprojects in general. The openEHR terminology is not large (at all), but looks like it will become more than one file, according to a discussion the other day (I will write this up and post it before doing anything), but I was thinking it needs to be part of a broader openEHR knowledge repository. Although... I have listed it as a distinct 'component' of the specification program - maybe it should have its own repository anyway. Translations of it will multiply the number of files substantially as time goes on, so that is another reason perhaps for a separate repository. I think test archetypes templates probably should be separate from test example data, so that is two repositories right there. That would give us: open terminology test archetypes templates test example data We need to add existing active software projects: Java ref implem project ADL Workbench (Ocean) Archetype Editor Opereffa Not sure about the following: LiU modelling tools Ruby I think is on its own repository; the Python implementation I believe is no longer openEHR, but some kind of custom fork in its own repositories. openEHR on .Net is on codeplex. Any others? - thomas On 07/05/2012 10:55, Erik Sundvall wrote: Hi Tom! Could we use the openEHR github project (that you registered) for hosting a subproject with the openEHR Terminology? I believe it can make ongoing branching/patching more visible and easier to merge/administrate. There is no hurry to move existing test-archetypes there, but for new efforts (terminology, RM-instance-examples etc) me might as well start there (perhaps as a separate subproject). ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
How about creating an openEHR test base?
Interesting point again. There are various bits of functionality implemented in different projects, but the projects have different open source licences. I'm not Rong of course, but his code uses mpl, and since I've used his code when I started Operaffa, Opereffa is mpl too (though it'll be apache very soon). So you'd need to check how licensing issues need to be handled if you use Rong's code, assuming your work is not under mpl. I think you've touched another important point Pablo Kind regards Seref On Mon, May 7, 2012 at 10:37 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Rong, That's great news, but we have our own RM implementation because it handles ORM too. But I think I can adapt your xml-binding component to use our RM impl, what do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos Date: Mon, 7 May 2012 21:08:57 +0200 Subject: Re: How about creating an openEHR test base? From: rong.acode at gmail.com To: openehr-technical at lists.openehr.org On 7 May 2012 16:39, pablo pazos pazospablo at hotmail.com wrote: Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. Hi Pablo, The xml-binding component in the Java reference implementation does just that. It binds RM object instance to generated XML objects that can be serialized according to published XSD. /Rong ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/769f28c0/attachment.html
openEHR on GitHub (was Re: How about creating an openEHR test base?)
On 08/05/2012 03:59, Shinji KOBAYASHI wrote: Hi Thomas Beale, Our, Ruby implementation repository has already moved on GitHub for our convenience last year for our convenience. I was wondering if we could move our repository under github://openehr/ruby-impl-openhr. It would be comprehensive rather than under skoba/ruby-impl-openehr for publicity. * * you certainly can. I have to travel for a few days, but once I am back I will get on to organising with you and other teams how to structure the openEHR Github area. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/ef5f9fbb/attachment-0001.html
How about creating an openEHR test base?
Dear Erik and all (This email might appear a bit long but it actually makes just two points a) Data Synthesizer Tool, b)Availability of Realistic Subject data) A) Data Synthesizer Tool I absolutely agree on the data synthesizer tool. It is something i would like to do as a test case for parsing an archetype's definition node and generating a representative object because in this case, each and every node defined in the spec would have to be handled. It's not that much of a time consuming task if you already have the RM builder. The AM provides everything that is needed (For example: http://postimage.org/image/mcytss26f/ bounds for primitive types, cardinality / multiplicity for other data structures), so instead of just creating an object from the RM and attaching it in a hierarchy (just by calling its constructor maybe), some values would have to be generated and attached to its fields as well. Once the RM object is constructed it can be serialized to anything (XML included) (and there goes a first test base) From this perspective, it is absolutely essential that the XSDs are valid (to ensure a valid structure) and also (Seref's got a very good point) that the archetypes are valid to ensure a valid content. B) Availability of Realistic Subject Data As far as clinically realistic datasets are concerned, i would like to suggest the following: The Alzheimer's Disease Neuroimaging Initiative (ADNI) in the US is a long term project that collects, longitudinally, various clinical parameters from subjects at various stages in the disease (http://adni.loni.ucla.edu/). At the moment, the dataset contains about 800 subjects. Each subject would have 4-5 sessions associated with it (at 6 month intervals usually) and for each session a number of parameters would be collected such as MMSE scores, ADAS Cog scores, received medication, lab tests and others as well as imaging biomarkers (MRI mostly). A basic demographics section is also available for each subject. (To put it in the context of a visualisation, the story that these data reveal is the progression of AD on a subject / population of subjects which is very interesting.) The data are made available as CSV files (about 12 MB just for the numerical data). An application must be made to ADNI to obtain the data. As redistribution of the data is prohibited (http://adni.loni.ucla.edu/wp-content/uploads/how_to_apply/ADNI_DSP_Policy.pdf) we would be working towards a tool that would accept a set of ADNI CSV files and transform them into a local openEHR enabled repository. The task here would be to create some archetypes / templates that reflect the structure of the data shared by ADNI and then scan the CSVs and populate the openEHR enabled repository. The CSV files are not in the best of conditions (the structure has been changed from version to version, certain fields (such as dates) might be in a number of different formats, the terminology is not exactly standardised, etc). For us (ctmnd.org) to work on these files we have created an SQL database and a set of scripts that sanitize and import the CSVs. I would be interested in turning this database into an openEHR enabled repository (whether a set of XML files or proper openEHR database) because it can be used for a number of things (especially for testing AQL). If you think that this can be of help, let me know how we can progress with it. Obviously the tool can be made available to everybody who can then apply to download the ADNI data locally. I am not so sure about the data (even if they become totally anonymised), i will have to check, but in any case, going from I have nothing to I have a database of multi-modal data from 800 subjects that is more realistic than test data is got to worth the trouble of converting the CSVs. Looking forward to hearing from you Athanasios Anastasiou
How about creating an openEHR test base?
Hi Athanasios, The problem is always about time. If someone is willing to model an existing clinical data set, then for those who do not know about it, the UCI machine learning repository has some interesting clinical data sets. They're freely available for research, and I think it would be fairly easy to use them for the type of test based we're discussing. Just google UCI machine learning repository, and you should see what I'm talking about. If the openEHR community has members who can put time into creating models for any of these (or other) data sets, and then turning them to valid RM serializations, I for one will not say no to that :) Kind regards Seref On Tue, May 8, 2012 at 11:38 AM, Athanasios Anastasiou athanasios.anastasiou at plymouth.ac.uk wrote: Dear Erik and all (This email might appear a bit long but it actually makes just two points a) Data Synthesizer Tool, b)Availability of Realistic Subject data) A) Data Synthesizer Tool I absolutely agree on the data synthesizer tool. It is something i would like to do as a test case for parsing an archetype's definition node and generating a representative object because in this case, each and every node defined in the spec would have to be handled. It's not that much of a time consuming task if you already have the RM builder. The AM provides everything that is needed (For example: http://postimage.org/image/**mcytss26f/http://postimage.org/image/mcytss26f/bounds for primitive types, cardinality / multiplicity for other data structures), so instead of just creating an object from the RM and attaching it in a hierarchy (just by calling its constructor maybe), some values would have to be generated and attached to its fields as well. Once the RM object is constructed it can be serialized to anything (XML included) (and there goes a first test base) From this perspective, it is absolutely essential that the XSDs are valid (to ensure a valid structure) and also (Seref's got a very good point) that the archetypes are valid to ensure a valid content. B) Availability of Realistic Subject Data As far as clinically realistic datasets are concerned, i would like to suggest the following: The Alzheimer's Disease Neuroimaging Initiative (ADNI) in the US is a long term project that collects, longitudinally, various clinical parameters from subjects at various stages in the disease (http://adni.loni.ucla.edu/ ). At the moment, the dataset contains about 800 subjects. Each subject would have 4-5 sessions associated with it (at 6 month intervals usually) and for each session a number of parameters would be collected such as MMSE scores, ADAS Cog scores, received medication, lab tests and others as well as imaging biomarkers (MRI mostly). A basic demographics section is also available for each subject. (To put it in the context of a visualisation, the story that these data reveal is the progression of AD on a subject / population of subjects which is very interesting.) The data are made available as CSV files (about 12 MB just for the numerical data). An application must be made to ADNI to obtain the data. As redistribution of the data is prohibited (http://adni.loni.ucla.edu/wp-** content/uploads/how_to_apply/**ADNI_DSP_Policy.pdfhttp://adni.loni.ucla.edu/wp-content/uploads/how_to_apply/ADNI_DSP_Policy.pdf) we would be working towards a tool that would accept a set of ADNI CSV files and transform them into a local openEHR enabled repository. The task here would be to create some archetypes / templates that reflect the structure of the data shared by ADNI and then scan the CSVs and populate the openEHR enabled repository. The CSV files are not in the best of conditions (the structure has been changed from version to version, certain fields (such as dates) might be in a number of different formats, the terminology is not exactly standardised, etc). For us (ctmnd.org) to work on these files we have created an SQL database and a set of scripts that sanitize and import the CSVs. I would be interested in turning this database into an openEHR enabled repository (whether a set of XML files or proper openEHR database) because it can be used for a number of things (especially for testing AQL). If you think that this can be of help, let me know how we can progress with it. Obviously the tool can be made available to everybody who can then apply to download the ADNI data locally. I am not so sure about the data (even if they become totally anonymised), i will have to check, but in any case, going from I have nothing to I have a database of multi-modal data from 800 subjects that is more realistic than test data is got to worth the trouble of converting the CSVs. Looking forward to hearing from you Athanasios Anastasiou __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org
How about creating an openEHR test base?
Hello Seref Many thanks for the UCI reference, i was personally not aware of it and it's a great resource. Well, as it seems there are plenty of dummy but realistic (!) dataset opportunities out there for creating a test-base, it is indeed a matter of time and i am sorry to not have more experience with actually building archetypes, i can see the value in this and i'd definitely give it a try. Perhaps we can create drafts though and even if these are not entirely correct they would be edited by others (?) All the best Athanasios Anastasiou On 08/05/2012 12:16, Seref Arikan wrote: Hi Athanasios, The problem is always about time. If someone is willing to model an existing clinical data set, then for those who do not know about it, the UCI machine learning repository has some interesting clinical data sets. They're freely available for research, and I think it would be fairly easy to use them for the type of test based we're discussing. Just google UCI machine learning repository, and you should see what I'm talking about. If the openEHR community has members who can put time into creating models for any of these (or other) data sets, and then turning them to valid RM serializations, I for one will not say no to that :) Kind regards Seref On Tue, May 8, 2012 at 11:38 AM, Athanasios Anastasiou athanasios.anastasiou at plymouth.ac.uk mailto:athanasios.anastasiou at plymouth.ac.uk wrote: Dear Erik and all (This email might appear a bit long but it actually makes just two points a) Data Synthesizer Tool, b)Availability of Realistic Subject data) A) Data Synthesizer Tool I absolutely agree on the data synthesizer tool. It is something i would like to do as a test case for parsing an archetype's definition node and generating a representative object because in this case, each and every node defined in the spec would have to be handled. It's not that much of a time consuming task if you already have the RM builder. The AM provides everything that is needed (For example: http://postimage.org/image/__mcytss26f/ http://postimage.org/image/mcytss26f/ bounds for primitive types, cardinality / multiplicity for other data structures), so instead of just creating an object from the RM and attaching it in a hierarchy (just by calling its constructor maybe), some values would have to be generated and attached to its fields as well. Once the RM object is constructed it can be serialized to anything (XML included) (and there goes a first test base) From this perspective, it is absolutely essential that the XSDs are valid (to ensure a valid structure) and also (Seref's got a very good point) that the archetypes are valid to ensure a valid content. B) Availability of Realistic Subject Data As far as clinically realistic datasets are concerned, i would like to suggest the following: The Alzheimer's Disease Neuroimaging Initiative (ADNI) in the US is a long term project that collects, longitudinally, various clinical parameters from subjects at various stages in the disease (http://adni.loni.ucla.edu/). At the moment, the dataset contains about 800 subjects. Each subject would have 4-5 sessions associated with it (at 6 month intervals usually) and for each session a number of parameters would be collected such as MMSE scores, ADAS Cog scores, received medication, lab tests and others as well as imaging biomarkers (MRI mostly). A basic demographics section is also available for each subject. (To put it in the context of a visualisation, the story that these data reveal is the progression of AD on a subject / population of subjects which is very interesting.) The data are made available as CSV files (about 12 MB just for the numerical data). An application must be made to ADNI to obtain the data. As redistribution of the data is prohibited (http://adni.loni.ucla.edu/wp-__content/uploads/how_to_apply/__ADNI_DSP_Policy.pdf http://adni.loni.ucla.edu/wp-content/uploads/how_to_apply/ADNI_DSP_Policy.pdf) we would be working towards a tool that would accept a set of ADNI CSV files and transform them into a local openEHR enabled repository. The task here would be to create some archetypes / templates that reflect the structure of the data shared by ADNI and then scan the CSVs and populate the openEHR enabled repository. The CSV files are not in the best of conditions (the structure has been changed from version to version, certain fields (such as dates) might be in a number of different formats, the terminology is not exactly standardised, etc). For us (ctmnd.org http://ctmnd.org) to work on these files we have created an SQL database and a set of scripts that sanitize and import the CSVs. I would be
How about creating an openEHR test base?
Once again we have tooling to convert csv files to openEHR using template data schema but someone has to do the hard work of creating the archetypes, templates and transforms to make it all happen. This continues to be the blocker of this kind initiative. Let us know if anyone has the bandwidth. Heath On 08/05/2012 8:08 PM, Athanasios Anastasiou athanasios.anastasiou at plymouth.ac.uk wrote: Dear Erik and all (This email might appear a bit long but it actually makes just two points a) Data Synthesizer Tool, b)Availability of Realistic Subject data) A) Data Synthesizer Tool I absolutely agree on the data synthesizer tool. It is something i would like to do as a test case for parsing an archetype's definition node and generating a representative object because in this case, each and every node defined in the spec would have to be handled. It's not that much of a time consuming task if you already have the RM builder. The AM provides everything that is needed (For example: http://postimage.org/image/**mcytss26f/http://postimage.org/image/mcytss26f/bounds for primitive types, cardinality / multiplicity for other data structures), so instead of just creating an object from the RM and attaching it in a hierarchy (just by calling its constructor maybe), some values would have to be generated and attached to its fields as well. Once the RM object is constructed it can be serialized to anything (XML included) (and there goes a first test base) From this perspective, it is absolutely essential that the XSDs are valid (to ensure a valid structure) and also (Seref's got a very good point) that the archetypes are valid to ensure a valid content. B) Availability of Realistic Subject Data As far as clinically realistic datasets are concerned, i would like to suggest the following: The Alzheimer's Disease Neuroimaging Initiative (ADNI) in the US is a long term project that collects, longitudinally, various clinical parameters from subjects at various stages in the disease (http://adni.loni.ucla.edu/ ). At the moment, the dataset contains about 800 subjects. Each subject would have 4-5 sessions associated with it (at 6 month intervals usually) and for each session a number of parameters would be collected such as MMSE scores, ADAS Cog scores, received medication, lab tests and others as well as imaging biomarkers (MRI mostly). A basic demographics section is also available for each subject. (To put it in the context of a visualisation, the story that these data reveal is the progression of AD on a subject / population of subjects which is very interesting.) The data are made available as CSV files (about 12 MB just for the numerical data). An application must be made to ADNI to obtain the data. As redistribution of the data is prohibited (http://adni.loni.ucla.edu/wp-** content/uploads/how_to_apply/**ADNI_DSP_Policy.pdfhttp://adni.loni.ucla.edu/wp-content/uploads/how_to_apply/ADNI_DSP_Policy.pdf) we would be working towards a tool that would accept a set of ADNI CSV files and transform them into a local openEHR enabled repository. The task here would be to create some archetypes / templates that reflect the structure of the data shared by ADNI and then scan the CSVs and populate the openEHR enabled repository. The CSV files are not in the best of conditions (the structure has been changed from version to version, certain fields (such as dates) might be in a number of different formats, the terminology is not exactly standardised, etc). For us (ctmnd.org) to work on these files we have created an SQL database and a set of scripts that sanitize and import the CSVs. I would be interested in turning this database into an openEHR enabled repository (whether a set of XML files or proper openEHR database) because it can be used for a number of things (especially for testing AQL). If you think that this can be of help, let me know how we can progress with it. Obviously the tool can be made available to everybody who can then apply to download the ADNI data locally. I am not so sure about the data (even if they become totally anonymised), i will have to check, but in any case, going from I have nothing to I have a database of multi-modal data from 800 subjects that is more realistic than test data is got to worth the trouble of converting the CSVs. Looking forward to hearing from you Athanasios Anastasiou __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/44eb3365/attachment.html
How about creating an openEHR test base?
On 7 May 2012 23:37, pablo pazos pazospablo at hotmail.com wrote: Hi Rong, That's great news, but we have our own RM implementation because it handles ORM too. But I think I can adapt your xml-binding component to use our RM impl, what do you think? Pablo, The xml-binding component leverages the annotated constructors in the RM classes for instantiating RM objects. It uses reflections extensively. Take a look of the XMLBinding class for some inspiration. I am sure you can adapt it for your own classes. /Rong
How about creating an openEHR test base?
Hi Heath, I don't want to open the scope to much at this stage. I know this is a process that will take some time. Maybe some of us can focus on artifacts and others on services repositories. I really like the idea of having different repositories sharing the same artifacts, this can be a good technical proof of concept of a distributed CKM. (not a new topic, but maybe a forgotten one: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2011-September/002201.html). If some of you want to open the access to your services, I can write clients for the EHRGen project to consume artifacts and evaluate how it all works together. Kind regards,Pablo. Date: Tue, 8 May 2012 08:19:11 +0930 Subject: Re: How about creating an openEHR test base? From: heath.fran...@oceaninformatics.com To: openehr-technical at lists.openehr.org Hi Erik, I think that using an EHR service to store RM instances would be better than storing in SVN or GIT. Ultimately if the service was able to work from a GIT repository we would have the best of both worlds. I had considered offering the Ocean EHR server but I assumed the usual issues relating to the commercial backend would have made this not suitable so I didn't bother. Would your service be an alternative, especially since it is RESTful? Perhaps there is a need for multiple service implementations to be available working from the same instance repository, I am sure each have their strengths and weaknesses and interface approaches. For example the ocean EHR service picked up a data validation error reported on the list that another didn't. We can also use this to start comparing service models. Heath On 07/05/2012 4:32 PM, Erik Sundvall erik.sundvall at liu.se wrote: Hi! I agree that we need some RM instances etc initially. We have versioned compositions in the demo server for our LiU EEE-system. We don't know if they are 100% according to spec since they have not been extensively tested. I'll upload some of them to the wikipage after a deadline I have this week (remind me if they are not there next monday ;-) I can give a limited number of people access to them now via REST-interfaces (HTTP via a browser works fine). Mail me off-list if you are in a hurry. Would EHR-data reflecting a number realistic patient stories be interesting to collaborate on as a second step? I am in desperate need of such EHR data in order to create and test EHR-visualisations. Getting real patient data is a pain to get access to and if we get it we can never share it. Could we share the effort of creating a number of such EHR instances (and perhaps write a shared academic paper about it) - If so let's first check/discuss some of the options for data entry and once that is fixed we can involve more clinicians to create and improve/review the stories. A shared set could be reused in several projects and make them more comparable too. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/d109724f/attachment.html
How about creating an openEHR test base?
Hi Heath, The issues I mentioned were from seeing emails on the lists from other colleagues reporting problems, until now I didn't worked with openEHR XSDs. I remember someone mentioned a problem of correspondence between XSDs and openEHR specs. Maybe each member can mention what problems they had (Erik?, Athanasios?). Just for fun I've searched XSD on the lists: https://www.google.com/search?sourceid=chromeie=UTF-8q=xsd+site%3Alists.openehr.org%2Fpipermail%2Fopenehr-implementers_lists.openehr.org%2F#hl=essclient=psy-abq=xsd+site:lists.openehr.org%2Fpipermail%2Fopenehr-implementers_lists.openehr.orgoq=xsd+site:lists.openehr.org%2Fpipermail%2Fopenehr-implementers_lists.openehr.orgaq=faqi=aql=gs_l=serp.3...42653.42653.0.42798.1.1.0.0.0.0.0.0..0.0...0.0.C216hd-inngpbx=1bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osbfp=ca1c69677034f246biw=1280bih=687 https://www.google.com/search?sourceid=chromeie=UTF-8q=xsd+site%3Alists.openehr.org%2Fpipermail%2Fopenehr-technical_lists.openehr.org%2F#hl=essclient=psy-abq=xsd+site:lists.openehr.org%2Fpipermail%2Fopenehr-technical_lists.openehr.orgoq=xsd+site:lists.openehr.org%2Fpipermail%2Fopenehr-technical_lists.openehr.orgaq=faqi=aql=gs_l=serp.3...2087.2087.0.2601.1.1.0.0.0.0.242.242.2-1.1.0...0.0.3-xa3a0gTaYpbx=1bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osbfp=ca1c69677034f246biw=1280bih=687 Please do contribute! you can add your name and attach the files here: http://www.openehr.org/wiki/display/dev/Development+test+base so there's no mess up with current releases. Please mention what changes you have done to the XSDs here: http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html If you have some XML instances for those schemas, would be great too! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 8 May 2012 08:32:20 +0930 Subject: RE: How about creating an openEHR test base? From: heath.fran...@oceaninformatics.com To: openehr-technical at lists.openehr.org Hi Pablo, What issues do you have with the XSD? We have been producing valid instances for years. I have tools that can validate these in seconds. I am sitting on hundreds of test instances. Problem is I am not sitting around with nothing to do. If you have a student willing to do some dot NET code with little support you can go to openehr.codeplex.com to get what you need to create and validate openehr instances against OPTs and RM. BTW, I have a local xsd that further constrains the published schema that picks up several additional RM invariants. Happy to contribute this but don't want to confuse the status of the official schema. I also have a demographic schema which I believe is currently not part of the current openEHR release. Heath -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/891bd5f2/attachment.html
How about creating an openEHR test base?
Hi Pablo, It makes more sense to me to add all of that to the existing repository rather than fragmenting the effort. - Peter On 06/05/2012, at 22:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: How about creating an openEHR test base? From: peter.gummer at oceaninformatics.com Date: Sun, 6 May 2012 21:39:25 +1000 To: openehr-technical at lists.openehr.org pablo pazos wrote: I have proposed here *** that we can start attaching files to the wiki and linking them under our names, each one of us can describe each artifact, what issues it has, what tweaks and fixes have made over those artifacts, etc. Hi Pablo, I get the impression that you aren't aware that this test repository already exists: http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test Have you considered building on this, rather than starting a whole new repository? - Peter
How about creating an openEHR test base?
Diego Bosc? wrote: I would say the scope of that repository is different, as that is part of the test for current evolving 1.5 syntax and does not include 'real' archetypes My understanding was that Pablo was not proposing real archetypes either. In his original post, Pablo proposed a test base with sample artifacts. How would this be different from the purpose of the existing http://www.openehr.org/svn/knowledge2 repository? The only difference that I can see is that Pablo has proposed adding a greater variety of artefacts (OPTs, etc.), so it seems natural to add them to the existing repository. - Peter
How about creating an openEHR test base?
Pablo also mentioned 'RM instances in a variety of formats', which are not 'artefacts'. 2012/5/7 Peter Gummer peter.gummer at oceaninformatics.com: Diego Bosc? wrote: I would say the scope of that repository is different, as that is part of the test for current evolving 1.5 syntax and does not include 'real' archetypes My understanding was that Pablo was not proposing real archetypes either. In his original post, Pablo proposed a test base with sample artifacts. How would this be different from the purpose of the existing http://www.openehr.org/svn/knowledge2 repository? The only difference that I can see is that Pablo has proposed adding a greater variety of artefacts (OPTs, etc.), so it seems natural to add them to the existing repository. - Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
How about creating an openEHR test base?
Hi! I agree that we need some RM instances etc initially. We have versioned compositions in the demo server for our LiU EEE-system. We don't know if they are 100% according to spec since they have not been extensively tested. I'll upload some of them to the wikipage after a deadline I have this week (remind me if they are not there next monday ;-) I can give a limited number of people access to them now via REST-interfaces (HTTP via a browser works fine). Mail me off-list if you are in a hurry. Would EHR-data reflecting a number realistic patient stories be interesting to collaborate on as a second step? I am in desperate need of such EHR data in order to create and test EHR-visualisations. Getting real patient data is a pain to get access to and if we get it we can never share it. Could we share the effort of creating a number of such EHR instances (and perhaps write a shared academic paper about it) - If so let's first check/discuss some of the options for data entry and once that is fixed we can involve more clinicians to create and improve/review the stories. A shared set could be reused in several projects and make them more comparable too. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Mon, May 7, 2012 at 12:48 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Diego Peter, What Diego said about evolving tests for ADL1.5 is true, we don't want to test the tools or the specs, we want to test our implementations (EHRs, services, repositories, etc). I agree this overlaps in some way with the CKM content (archetypes and templates), but our focus is on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know waht I mean. I agree what Diego said in the last message: we want RM instances (XML) in the repo, which will be valid against XSDs (that we need to test and fix, XSDs will be included in the repo too). JSON instances will be welcome too :D To give more context, this is taken from a private message to Erik: What I have in mind is to create something like a unit test for openEHR applications and services, with archetypes, rm instances and term sets. E.g. having a test set with some archetypes, a template, some term sets and a couple of instances in xml and json formats, and create some small software that can handle those test sets, validating instances to schemas, validating structures to archetypes, etc. and maybe geting data from the instances and doing something with it, -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: yampeku at gmail.com Date: Mon, 7 May 2012 00:23:44 +0200 Subject: Re: How about creating an openEHR test base? To: openehr-technical at lists.openehr.org Pablo also mentioned 'RM instances in a variety of formats', which are not 'artefacts'. 2012/5/7 Peter Gummer peter.gummer at oceaninformatics.com: Diego Bosc? wrote: I would say the scope of that repository is different, as that is part of the test for current evolving 1.5 syntax and does not include 'real' archetypes My understanding was that Pablo was not proposing real archetypes either. In his original post, Pablo proposed a test base with sample artifacts. How would this be different from the purpose of the existing http://www.openehr.org/svn/knowledge2 repository? The only difference that I can see is that Pablo has proposed adding a greater variety of artefacts (OPTs, etc.), so it seems natural to add them to the existing repository. - Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
How about creating an openEHR test base?
On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? * * My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful, because it lacks too many basic semantics - particularly dynamic type markers. Its cousin YAML is over-complicated (and in its whitespace form, nearly impossible to get right!), but does have proper OO semantics and I think can be used as a lossless serialisation. Others may have more evolved ideas on how these particular formalisms should be used in openEHR, so I am very happy to be educated by the experts. My main aim is to make sure that the transformations of ADL = JSON and ADL = YAML are correct. You can experiment with JSON, YAML and XML outputs of any ADL 1.4 or 1.5 archetypes right now, using the ADL workbench, which has a bulk export mode into these formalisms. We have already discussed last week with Rong Sebastian about moving the openEHR terminology there, and how to manage it more effectively, so the scope of this knowledge repository is going to continue to grow anyway. So any community input on how to expand this repository and manage it is welcome from my point of view (I realise the above might only be a subset of your original scope Pablo, so there are probably some things that still need to be done elsewhere.) - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120507/26077e7a/attachment-0001.html
How about creating an openEHR test base?
Hi Tom! Could we use the openEHR github project (that you registered) for hosting a subproject with the openEHR Terminology? I believe it can make ongoing branching/patching more visible and easier to merge/administrate. There is no hurry to move existing test-archetypes there, but for new efforts (terminology, RM-instance-examples etc) me might as well start there (perhaps as a separate subproject). Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 We have already discussed last week with Rong Sebastian about moving the openEHR terminology there, and how to manage it more effectively, so the scope of this knowledge repository is going to continue to grow anyway. So any community input on how to expand this repository? and manage it is welcome from my point of view (I realise the above might only be a subset of your original scope Pablo, so there are probably some things that still need to be done elsewhere.)
openEHR on GitHub (was Re: How about creating an openEHR test base?)
yes, we will obviously migrate over to Github in the coming months. I have a slight concern about how to avoid chaos, and I do think we need to think carefully about how we organise Git projects/subprojects in general. The openEHR terminology is not large (at all), but looks like it will become more than one file, according to a discussion the other day (I will write this up and post it before doing anything), but I was thinking it needs to be part of a broader openEHR knowledge repository. Although... I have listed it as a distinct 'component' of the specification program - maybe it should have its own repository anyway. Translations of it will multiply the number of files substantially as time goes on, so that is another reason perhaps for a separate repository. I think test archetypes templates probably should be separate from test example data, so that is two repositories right there. That would give us: * open terminology * test archetypes templates * test example data We need to add existing active software projects: * Java ref implem project * ADL Workbench * (Ocean) Archetype Editor * Opereffa Not sure about the following: * LiU modelling tools Ruby I think is on its own repository; the Python implementation I believe is no longer openEHR, but some kind of custom fork in its own repositories. openEHR on .Net is on codeplex. Any others? - thomas On 07/05/2012 10:55, Erik Sundvall wrote: Hi Tom! Could we use the openEHR github project (that you registered) for hosting a subproject with the openEHR Terminology? I believe it can make ongoing branching/patching more visible and easier to merge/administrate. There is no hurry to move existing test-archetypes there, but for new efforts (terminology, RM-instance-examples etc) me might as well start there (perhaps as a separate subproject). -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120507/bb038140/attachment.html
How about creating an openEHR test base?
Hi Thomas, just to be sure we are on the same page: From previous emails: What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept). We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean. JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs,2. have some RM XML instances are correct validated against XSDs,3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too,4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps,5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results,6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards,Pablo. Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful, because it lacks too many basic semantics - particularly dynamic type markers. Its cousin YAML is over-complicated (and in its whitespace form, nearly impossible to get right!), but does have proper OO semantics and I think can be used as a lossless serialisation. Others may have more evolved ideas on how these particular formalisms should be used in openEHR, so I am very happy to be educated by the experts. My main aim is to make sure that the transformations of ADL = JSON and ADL = YAML are correct. You can experiment with JSON, YAML and XML outputs of any ADL 1.4 or 1.5 archetypes right now, using the ADL workbench, which has a bulk export mode into these formalisms. We have already discussed last week with Rong Sebastian about moving the openEHR terminology there, and how to manage it more effectively, so the scope of this knowledge repository is going to continue to grow anyway. So any community input on how to expand this repository and manage it is welcome from my point of view (I realise the above might only be a subset of your original scope Pablo, so there are probably some things that still need to be done elsewhere.) - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120507/80df2ed3/attachment.html
How about creating an openEHR test base?
I don't have the time to do what I'm going to suggest next, but if someone has time in their hands, I'd suggest writing a tool that will automatically generate valid XML RM documents, such as compositions etc. Archetypes and templates define boundaries of all valid instances of clinical models, and one can generate random instances that belong to this set. Opereffa's current version supports this, but not with XML output. I used this approach to test performance of persistence options If our argument is that all the clinical information can be represented via models, why should be create RM instances by hand? Regards Seref On Mon, May 7, 2012 at 3:05 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Thomas, just to be sure we are on the same page: From previous emails: *What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept).* * * *We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean.* JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs, 2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too, 4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results, 6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards, Pablo. -- Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? * * My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful, because it lacks too many basic semantics - particularly dynamic type markers. Its cousin YAML is over-complicated (and in its whitespace form, nearly impossible to get right!), but does have proper OO semantics and I think can be used as a lossless serialisation. Others may have more evolved ideas on how these particular formalisms should be used in openEHR, so I am very happy to be educated by the experts. My main aim is to make sure that the transformations of ADL = JSON and ADL = YAML are correct. You can experiment with JSON, YAML and XML outputs of any ADL 1.4 or 1.5 archetypes right now, using the ADL workbench, which has a bulk export mode into these formalisms. We have already discussed last week with Rong Sebastian about moving the openEHR terminology there, and how to manage it more effectively, so the scope of this knowledge repository is going to continue to grow anyway. So any community input on how to expand this repository and manage it is welcome from my point of view (I realise the above might only be a subset of your original scope Pablo, so there are probably some things that still need to be done elsewhere.) - thomas ___ openEHR-technical mailing list openEHR-technical
How about creating an openEHR test base?
Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. In order to do that, we should resolve current reported issues with the XSDs (see my first email), and then generate XMLs, at first maybe by hand, later integrated into tools. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 7 May 2012 15:26:28 +0100 Subject: Re: How about creating an openEHR test base? From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org I don't have the time to do what I'm going to suggest next, but if someone has time in their hands, I'd suggest writing a tool that will automatically generate valid XML RM documents, such as compositions etc. Archetypes and templates define boundaries of all valid instances of clinical models, and one can generate random instances that belong to this set. Opereffa's current version supports this, but not with XML output. I used this approach to test performance of persistence options If our argument is that all the clinical information can be represented via models, why should be create RM instances by hand? Regards Seref On Mon, May 7, 2012 at 3:05 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Thomas, just to be sure we are on the same page: From previous emails: What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept). We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean. JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs,2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too,4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results,6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards,Pablo. Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful, because it lacks too many basic semantics - particularly dynamic type markers. Its cousin YAML is over-complicated (and in its whitespace form, nearly impossible to get right!), but does have proper OO semantics and I think can be used as a lossless serialisation. Others may have more evolved ideas on how these particular formalisms should be used in openEHR, so I am very happy to be educated
How about creating an openEHR test base?
I'm working on that, but the instances that are being generated for the moment still need some further processing to be considered clinically valid (e.g. if archetype says that a number 1000 is expected, one valid value is -1234567, which makes no sense from a clinical perspective). It needs works but looks promising so far 2012/5/7 pablo pazos pazospablo at hotmail.com: Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. In order to do that, we should resolve current reported issues with the XSDs (see my first email), and then generate XMLs, at first maybe by hand, later integrated into tools. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 7 May 2012 15:26:28 +0100 Subject: Re: How about creating an openEHR test base? From: serefarikan at kurumsalteknoloji.com To: openehr-technical at lists.openehr.org I don't have the time to do what I'm going to suggest next, but if someone has time in their hands, I'd suggest writing a tool that will automatically generate valid XML RM documents, such as compositions etc. Archetypes and templates define boundaries of all valid instances of clinical models, and one can generate random instances that belong to this set. Opereffa's current version supports this, but not with XML output. I used this approach to test performance of persistence options If our argument is that all the clinical information can be represented via models, why should be create RM instances by hand? Regards Seref On Mon, May 7, 2012 at 3:05 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Thomas, just to be sure we are on the same page: From previous emails: What we need is to?test our implementations (EHRs, services, repositories, etc),?we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept). We want to concentrate on?flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean. JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs, 2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too, 4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results, 6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards, Pablo. Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful, because it lacks too many basic semantics - particularly dynamic type markers. Its cousin YAML is over-complicated (and in its whitespace form, nearly
How about creating an openEHR test base?
That is my point exactly. If you use only the model (archetype || template) and your data is not clinically valid, then should not this mean that the archetype needs work? What if someone in a clinical setting entered -1234567 in real life? You would not be able to catch that with archetype based validation. In this case, you should not be amending your code, you should be amending the archetype, or that is how I'd attempt to do it. Kind regards Seref On Mon, May 7, 2012 at 3:59 PM, Diego Bosc? yampeku at gmail.com wrote: I'm working on that, but the instances that are being generated for the moment still need some further processing to be considered clinically valid (e.g. if archetype says that a number 1000 is expected, one valid value is -1234567, which makes no sense from a clinical perspective). It needs works but looks promising so far 2012/5/7 pablo pazos pazospablo at hotmail.com: Hi Seref, I've a tool that generates composition instances from archetypes and data, what I don't have is a way to generate a valid XML form from those compositions. In order to do that, we should resolve current reported issues with the XSDs (see my first email), and then generate XMLs, at first maybe by hand, later integrated into tools. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 7 May 2012 15:26:28 +0100 Subject: Re: How about creating an openEHR test base? From: serefarikan at kurumsalteknoloji.com To: openehr-technical at lists.openehr.org I don't have the time to do what I'm going to suggest next, but if someone has time in their hands, I'd suggest writing a tool that will automatically generate valid XML RM documents, such as compositions etc. Archetypes and templates define boundaries of all valid instances of clinical models, and one can generate random instances that belong to this set. Opereffa's current version supports this, but not with XML output. I used this approach to test performance of persistence options If our argument is that all the clinical information can be represented via models, why should be create RM instances by hand? Regards Seref On Mon, May 7, 2012 at 3:05 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Thomas, just to be sure we are on the same page: From previous emails: What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a guitar concept). We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean. JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs, 2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too, 4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results, 6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards, Pablo. Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.beale at oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas
How about creating an openEHR test base?
pablo pazos wrote: I have proposed here *** that we can start attaching files to the wiki and linking them under our names, each one of us can describe each artifact, what issues it has, what tweaks and fixes have made over those artifacts, etc. Hi Pablo, I get the impression that you aren't aware that this test repository already exists: http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test Have you considered building on this, rather than starting a whole new repository? - Peter
How about creating an openEHR test base?
Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets.Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: How about creating an openEHR test base? From: peter.gummer at oceaninformatics.com Date: Sun, 6 May 2012 21:39:25 +1000 To: openehr-technical at lists.openehr.org pablo pazos wrote: I have proposed here *** that we can start attaching files to the wiki and linking them under our names, each one of us can describe each artifact, what issues it has, what tweaks and fixes have made over those artifacts, etc. Hi Pablo, I get the impression that you aren't aware that this test repository already exists: http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test Have you considered building on this, rather than starting a whole new repository? - Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120506/20b32e5a/attachment.html
How about creating an openEHR test base?
Hi Peter, That makes sense, but I think we are on a previous stage than deciding the physical location of the files.Now we are trying to see what artifacts were developed individualy, what problems we have with our implementations, trying to improve and harmonize all that, etc. then we'll look for a location for all that. http://www.openehr.org/wiki/display/dev/Development+test+base Artifact governanceJust to start with a clear view of what we have and in which state, each published artifact will be under the collaborator's name, because each one of us might have different versions (maybe structurally different, with different tweaks and fixes) of those artifacts. Then we will try to converge on a common version for each artifact type.Please attach files to this page and link them in the sections below. Please add a small description to each file, like what it represents and if you have tweaked the format or fixed some problem with the format, please comment about that too. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: How about creating an openEHR test base? From: peter.gummer at oceaninformatics.com Date: Sun, 6 May 2012 23:43:06 +1000 To: openehr-technical at lists.openehr.org Hi Pablo, It makes more sense to me to add all of that to the existing repository rather than fragmenting the effort. - Peter On 06/05/2012, at 22:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: How about creating an openEHR test base? From: peter.gummer at oceaninformatics.com Date: Sun, 6 May 2012 21:39:25 +1000 To: openehr-technical at lists.openehr.org pablo pazos wrote: I have proposed here *** that we can start attaching files to the wiki and linking them under our names, each one of us can describe each artifact, what issues it has, what tweaks and fixes have made over those artifacts, etc. Hi Pablo, I get the impression that you aren't aware that this test repository already exists: http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test Have you considered building on this, rather than starting a whole new repository? - Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120506/f6f460ee/attachment-0001.html
How about creating an openEHR test base?
I would say the scope of that repository is different, as that is part of the test for current evolving 1.5 syntax and does not include 'real' archetypes 2012/5/6 Peter Gummer peter.gummer at oceaninformatics.com: Hi Pablo, It makes more sense to me to add all of that to the existing repository rather than fragmenting the effort. - Peter On 06/05/2012, at 22:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: How about creating an openEHR test base? From: peter.gummer at oceaninformatics.com Date: Sun, 6 May 2012 21:39:25 +1000 To: openehr-technical at lists.openehr.org pablo pazos wrote: I have proposed here *** that we can start attaching files to the wiki and linking them under our names, each one of us can describe each artifact, what issues it has, what tweaks and fixes have made over those artifacts, etc. Hi Pablo, I get the impression that you aren't aware that this test repository already exists: http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test Have you considered building on this, rather than starting a whole new repository? - Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
How about creating an openEHR test base?
Hi Diego Peter, What Diego said about evolving tests for ADL1.5 is true, we don't want to test the tools or the specs, we want to test our implementations (EHRs, services, repositories, etc). I agree this overlaps in some way with the CKM content (archetypes and templates), but our focus is on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know waht I mean. I agree what Diego said in the last message: we want RM instances (XML) in the repo, which will be valid against XSDs (that we need to test and fix, XSDs will be included in the repo too). JSON instances will be welcome too :D To give more context, this is taken from a private message to Erik: What I have in mind is to create something like a unit test for openEHR applications and services, with archetypes, rm instances and term sets. E.g. having a test set with some archetypes, a template, some term sets and a couple of instances in xml and json formats, and create some small software that can handle those test sets, validating instances to schemas, validating structures to archetypes, etc. and maybe geting data from the instances and doing something with it, -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: yampeku at gmail.com Date: Mon, 7 May 2012 00:23:44 +0200 Subject: Re: How about creating an openEHR test base? To: openehr-technical at lists.openehr.org Pablo also mentioned 'RM instances in a variety of formats', which are not 'artefacts'. 2012/5/7 Peter Gummer peter.gummer at oceaninformatics.com: Diego Bosc? wrote: I would say the scope of that repository is different, as that is part of the test for current evolving 1.5 syntax and does not include 'real' archetypes My understanding was that Pablo was not proposing real archetypes either. In his original post, Pablo proposed a test base with sample artifacts. How would this be different from the purpose of the existing http://www.openehr.org/svn/knowledge2 repository? The only difference that I can see is that Pablo has proposed adding a greater variety of artefacts (OPTs, etc.), so it seems natural to add them to the existing repository. - Peter -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120506/51bcdd01/attachment.html
How about creating an openEHR test base?
Hi Shinji and guys, Right now I don't care about license issues, if we have problems in the future, we can just create our own testing archetypes and templates and go on with the development :D About publishing, I think we need to discuss a little about how we will govern this repository, and how we will converge to a common and consistent set of artifacts for testing. I have proposed here *** that we can start attaching files to the wiki and linking them under our names, each one of us can describe each artifact, what issues it has, what tweaks and fixes have made over those artifacts, etc. When we have this baseline, we can start working on fixing problems, harmonizing formats, etc. Then we can create consistent test sets, and small pieces of software that can process those test sets and execute some test (like unit testing for openEHR). In this stage we can move those test sets to something more powerful like github. What do you think about this plan? Does it makes sense? Does all of us agree? Please leave a comment at (or edit) the wiki page: *** http://www.openehr.org/wiki/display/dev/Development+test+base -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Sat, 5 May 2012 18:07:27 +0900 Subject: Re: How about creating an openEHR test base? From: skoba at moss.gr.jp To: openehr-implementers at lists.openehr.org HI Pablo, I have been seeking such repository to share our artefacts. But I am hesitated to make it out, because of license issue. I know that all the artefacts will be available under Apache 2 license, but it is not officially announced. Articles about license on the openEHR.org are confused. http://www.openehr.org/free_commercial_use.htm.html http://www.openehr.org/298-OE.html By the way, we cannot wait so long time to step out. Shall we share our materials on GitHub? Best regards, Shinji Kobayashi 2012/5/5 pablo pazos pazospablo at hotmail.com: I've created a page on the wiki: http://www.openehr.org/wiki/display/dev/Development+test+base We'll keep it up to date with our progress. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: pazospablo at hotmail.com To: openehr-technical at lists.openehr.org; openehr-implementers at lists.openehr.org Subject: How about creating an openEHR test base? Date: Wed, 2 May 2012 19:27:01 -0300 Hi all, I'm analyzing different ways of having more people involved in openEHR software development at our spanish spakers openEHR community (http://openehr.org.es). The idea of having a test base with sample artifacts just came through my mind. Obviously this could be beneficial for all the openEHR community! The idea is to have a public repository with some archetypes, templates and OTPs, with some referenced term sets, and some composition instances in XML/JSON format and also extract instances in XML/JSON could be great for us all, because we can try implementation and communication of openEHR data using those artifacts. What I have trouble with is to find valid composition and extract instances in XML format, and also, with the current openEHR XSDs, issues with those have been reported several times and I don't know if they were corrected or not, or if the current XSDs are valid and correct: http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html Can we think of creating something like that in the near future? Just drop me a line if you want to collaborate! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos ___ openEHR-implementers mailing list openEHR-implementers at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org ___ openEHR-implementers mailing list openEHR-implementers at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org ___ openEHR-implementers mailing list openEHR-implementers at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120505/02238d82/attachment.html
