An ACTION or INSTRUCTION referencing an AGENT, is it possible?
Hi Gustavo, As Heather pointed out, the solution seems to be to reference the internal structure of a device (or any other demographic archetype) through a CLUSTER. But I think those demographic concepts should be also modelled as complete, separate demographic archetypes, referencing the same internal structure (CLUSTER). This allow us (developers) to create functionalities for searching and processing on demographic archetypes. About the internals of a test, I think most often includes both ACTION and OBSERVATION, because an ACTION could be used when you need to record information about the execution itself (being or not a clinical intervention on the patient, e.g. the recording of the device used to make the test should be part of the ACTION not of the OBSERVATION), then the OBSERVATION(s) could hold the information about the test result or information about clinical findings during the test. Then the whole record of a test execution should be recorded into a COMPOSITION that references those ACTION(s) and OBSERVATION(s). The INSTRUCTION of a test could reference to a device that should be used on the test, but during the test maybe another device was used, and that should be part of the ACTION that executes the INSTRUCTION. Does this makes sense to you? Please correct me if I'm wrong. My student detected some oftalmologic concepts that are not in the CKM, maybe I can put you both in contact to collaborate on the modelling of those concepts. -- 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: gbace...@gmail.com Date: Sun, 17 Jun 2012 10:03:15 +0100 Subject: Re: An ACTION or INSTRUCTION referencing an AGENT, is it possible? To: openehr-clinical at lists.openehr.org Hi Pablo,I'm an ophthalmologist and would be gladful to help. There are some issues about the archetype class and the nature of the test. As it is a study test it must be considered the existence of an intervention. If it does not include, so the most appropriate would be to record as an OBSERVATION archetype for the test. If it includes an intervention, then the most appropriate is to record as ACTION. For both situations use the Device CLUSTER on the CKM to record the device, remembering this archetype is not adequate to record a substance (e.g. fluorescein). To record the device that should be used for the test at an INSTRUCTION archetype, also consider the element Description of Procedure of Procedure Request archetype on CKM, which could be used to specify the device. I hope it was helpful.-- Gustavo BacelarMD + MBA + Med Informatics gustavobacelar.com+351 91 203 2353 +55 71 8831-2860Skype: gustavobacelar ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120617/56b74c95/attachment.html
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?
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?
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 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 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?
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?
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?
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
Questions about ADL/AOM 1.5, archetype flattening and operational templates
Hi, I'm reading this page trying to understand how to implement archetype flattening and operational template support to our EHRGen project: http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Source%2Cflatandoperationalformsofarchetypessupported What I don't get is: when you have a flat archetype (e.g. without slots, internal refs and only with the specialized nodes) or an operational template (also flat), where is the reference to the original archetype nodes in the flattened AOM object for the resolved references (slots, internal refs, etc.)? For example: Archetype A: [at] OBS - [at0001] HISTORY - [at0002] EVENT (slot to archetype B)Archetype B: [at] EVENT - [at0001] ITEM_TREE - ... Flattened: (Archetype A) [at] OBS - [at0001] HISTORY - [at0002] EVENT - (Archetype B) [at] EVENT - [at0001] ITEM_TREE - ... If I use the flattened archetype in my application, I would like to know what is the original archetype that constrained my EVENT, because could create queries based on the paths of that archetype. Maybe there's another way of doing the same that I can't see yet. Thanks a lot! -- Kind regards, Ing. Pablo Pazos Guti?rrezopenEHR community in spanish: http://openehr.org.es 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/20120430/ef2a72ac/attachment-0001.html
13606 revisited - list proposal
Hi Thomas, Date: Mon, 26 Mar 2012 20:47:05 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: 13606 revisited - list proposal On 26/03/2012 19:49, pablo pazos wrote: Hi Thomas, A while ago, we gave this issue a big thought when designing the EHRGen framework. Periodic event records are needed when recording certain studies and when monitoring a patient, but this can be recorded as single point events, and using a query to get all the points in a series. it can but that's very inefficient, and doesn't correctly represent what is happening, when you are talking about multiple samples in a series, e.g. coming from vital signs monitors, orthostatic BP, apgar, and many others. What I've said was incorrect, I mentioned periodic events and I should have said an Observation with many events, that was your question about, sorry for that. Here is the corrected answer: if you want to record a series of eventual events you can do it with only one Observation with many EVENT, or many Observarions with a single EVENT and an query to get the whole series, e.g. do create a graph. E.g. for vital signs when a patient is under observation at an ER. From the GUI perspective is very difficult to record periodic events, because you have to login, select a patient, select a record, select the section of that record that contains the periodic data, enter a new item to the time series. and presumably enter another, and another. That doesn't sound like a problem - it's how normal GUI for Apgar and multi-sample manual BP collection work. Don't forget, we are talking about time series in the seconds to minutes domain here. Although Glucose tolerance test data would make more sense to be entered as one time series, after the fact. Consider this my comment with the right answer. From the GUI perspective is very difficult to record MANY EVENTS IN THE SAME OBSERVATION, because you have to login, select a patient, select a record, select the section of that record that contains the OBSERVATION, enter a new EVENT FOR THAT OBSERVATION. The other option is to have the patient's record always open, and that is not possible in all scenarios (for technical or security reasons). well ifyou are talking about long period of time, like repeated nursing observations, you should be committing those 1 sample at a time. Consider this ER scenario: a BP value could be recorded each 30 or so, and the system could be used 1. for many patients, 2. by many users, 3. on the same machine. The problem is when an item is commited, it should be as a part of a COMPOSITION (?), so if a nurse want to record a second take of a BP she is monitoring, and of course she wants to see the current recorded values for that series, another COMPOSITION should be created only for that value (or not?). Sorry again for the confusion. Kind regards,Pablo. Of course, the system could have something in the middle storing all the values without commiting them In the other hand, in the majority of cases of clinical record through a GUI, the data is recorded as a single point event, e.g. at a patient visit. So we design the EHRGen just to use point events, and if you want to record a series of events, a service should be provided to get the data from other systems (e.g. a LAB system), but not from the GUI. that and vital signs monitors are certainly a common source of time-based data. But whether the source of the data is the GUI or somewhere else doesn't change the semantics of the model, or the need for it. Like I said elsewhere, I have no problem with adding a single-event Observation as well. But having only that will completely cripple many hospital apps and efficient data representation and querying related to this data. - thomas ___ 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/20120327/50b7decc/attachment.html
Suggestion to replace use of generics with inheritence in future RM versions
Developers are expensive, tools are reusable :D -- 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, 26 Mar 2012 15:43:15 +0100 Subject: Re: Suggestion to replace use of generics with inheritence in future RM versions From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org If any developer would do better than a tool, why would anybody write tools in the first place? On Mon, Mar 26, 2012 at 3:26 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 23/03/2012 12:09, Heath Frankel wrote: I know every developer can do it better than the next but any developer can do it better than a tool. How true. That statement should be on the wall of every UML tool vendor's office! - thomas ___ 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/20120326/05269231/attachment.html
13606 revisited - list proposal
Hi Thomas, A while ago, we gave this issue a big thought when designing the EHRGen framework. Periodic event records are needed when recording certain studies and when monitoring a patient, but this can be recorded as single point events, and using a query to get all the points in a series. From the GUI perspective is very difficult to record periodic events, because you have to login, select a patient, select a record, select the section of that record that contains the periodic data, enter a new item to the time series. The other option is to have the patient's record always open, and that is not possible in all scenarios (for technical or security reasons). In the other hand, in the majority of cases of clinical record through a GUI, the data is recorded as a single point event, e.g. at a patient visit. So we design the EHRGen just to use point events, and if you want to record a series of events, a service should be provided to get the data from other systems (e.g. a LAB system), but not from the GUI. I don't know if I'm clear here, but hope that helps. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Date: Fri, 23 Mar 2012 14:25:34 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: 13606 revisited - list proposal In the thread below, Pablo asked whether Action should have as its data not just an ItemStructure but a History, like Observation. Does anyone else have evidence supporting this need? A related question is: is there a need for an Observation type that only has one Event in it, i.e. one time-point? Obviously quite a few observations in real life, including 'patient story' are of this form. Our original motivation was to make all Observation data structures the same, hence the current data structures. Introducing more types makes code more complex and therefore error-prone, but generally makes data simpler/smaller overall. thoughts? - thomas On 13/02/2012 21:31, pablo pazos wrote: Hi Thomas, Sorry for the delay, I'm working on several projects right now and have little time to follow discussion here. I'm also thinking about the ENTRY model, to lift up the data/description attributes from all entry subclasses to the ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as ITEM_STRUCTURE or as a HISTORY. We did think about this a long time ago, but it did not seem useful. But I assume you are thinking of doing it because you want to make ENTRY a concrete class which could have 'any' structure. Nope, is because I see a common pattern on concreate ENTRY subclases. In theory doing this breaks a basic modelling rule, which is that a superclass whose descendants define the possible data space should not itself be concrete. I think this is not the case, having a ENTRY.data : DATA_STRUCTURE is in fact a more specific ENTRY class, but is still a generic one that could be specialized in many ways. In my (maybe biased) experience, all subclasses from ENTRY would make use of this attribute since a structure is needed to record information. The argument here I suppose is that we want to build in a 13606-style 'uncommitted' kind of ENTRY. In fact we already have this - it's currently called GENERIC_ENTRY. This doesn't get used at the moment (although it has been there for years), and if we want to make it a subtype of ENTRY, that could be done. The main thing to solve I guess is the conversion of any of the specific openEHR kinds of ENTRY into a generic ENTRY structure defined by 13606. This can actually be formally specified by an algorithm. It doesn't require that the parent abstract ENTRY become concrete either. I am unclear if there are other reasons to make the ENTRY parent type concrete, to mimic 13606 ENTRY, rather than simply move GENERIC_ENTRY to be a subtype, which seems more obvious to me. Maybe to have the flexibility to define ACTIONS and other entries to have a data attribute of class ITEM_STRUCTURE or HISTORY to track time of events instead of inventing DV_DATE
Suggestion to replace use of generics with inheritence in future RM versions
Hi all, Since this discussion is about how to implement things defined on the openEHR specs, I may suggest this is a topic of implementation technology specification instead of a change request to the specs. I mean, this is one of many things we need to consider when we implement openEHR in a certain technology, and if we can write down all those alternatives for each technology, we could have another layer of specifications, the ITS for Java|Ruby|.Net. E.g. HL7 has ITS specs. Just my 2 cents. -- 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: Thu, 22 Mar 2012 10:47:37 +0900 Subject: Re: Suggestion to replace use of generics with inheritence in future RM versions From: skoba at moss.gr.jp To: openehr-technical at lists.openehr.org Hi Peter, 2012/3/22 Peter Gummer peter.gummer at oceaninformatics.com: Shinji KOBAYASHI wrote: Ruby implementation might be one of the proof for replace of generics. I had much struggled to implement generics and got the conclusion that we do not need it. Ruby doesn't have generics at all, right, Shinji? It is right. I felt generics is very convenient, when I used Java, such as IteratorDvText it = someRmArrayInstance.iterator() But I found it must be cut off by 'Occam's razor' in Ruby. it = some_rm_array.iterator This code looks curious for Java/Eiffel/C# user who are similar to generics, but it is enough for encapsulated object instance. I think this depends on language environment, but nested generics seems complicated codes for me. List Map Integer, String Generics is useful to declare what instance is, but it breaks encapsulation. As regards to Bartrand Meyer's paper, 'a good balance' is a good design. Cheers, Shinji There's a comparison of generics and inheritance in an appendix of Bertrand Meyer's Object Oriented Software Construction, 2nd edition. (http://se.ethz.ch/~meyer/publications/acm/geninh.pdf seems to be the original paper that the appendix is based upon.) Generics can be simulated in a language with inheritance, but there is a cost: * Duplication of code. * Extra verbosity. I don't want to have either forced upon me. If I'm unfortunately forced to use a language that doesn't support generics, then I can always simulate it the generics with inheritance. But I certainly wouldn't want the specs to be obfuscated by hacks like that, thanks very much ;-) Peter ___ 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/20120321/1d0f4dc0/attachment-0001.html
Suggestion to replace use of generics with inheritence in future RM versions
Hi Seref, I understood your point. The fact is that this is a change request to the specs, and IMO things like these could be defined on annexes to the specs, in this case something like if you are implementing things in Java you'll have these problems with generics, so you can do things easier implementing the model this way The problem I see is the specs shouldn't be changed for a technology issue, or maybe yes, if we consider the 4 or 5 big technologies out there, but not only one. My point is: I agree with you no making something to simplify the implementation, I don't agree to do it by changing the model. -- 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: Thu, 22 Mar 2012 09:34:16 + Subject: Re: Suggestion to replace use of generics with inheritence in future RM versions From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org Hi Pablo, I do not want to have a discussion about how to implement specs. That was not my point. Let me try to be more direct: Generics causes problems during implementation of openEHR if Java or XML is involved. Java + XML has a huge user base. Even XML on its own has a huge user base. By making a minor change in OO design options, openEHR can eliminate these problems for everyone using Java and especially XML. This may help openEHR become a spec easier to implement. This is the point I was trying to make. On Thu, Mar 22, 2012 at 2:06 AM, pablo pazos pazospablo at hotmail.com wrote: Hi all, Since this discussion is about how to implement things defined on the openEHR specs, I may suggest this is a topic of implementation technology specification instead of a change request to the specs. I mean, this is one of many things we need to consider when we implement openEHR in a certain technology, and if we can write down all those alternatives for each technology, we could have another layer of specifications, the ITS for Java|Ruby|.Net. E.g. HL7 has ITS specs. Just my 2 cents. -- 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/20120322/7e7dcd3b/attachment.html
Are you doing an academic project using openEHR?
Hi Thomas, we are here: http://www.openehr.org/shared-resources/usage/nonprofit.html -- 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, 19 Mar 2012 00:13:22 + From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: Are you doing an academic project using openEHR? On 18/03/2012 17:45, pablo pazos wrote: Hi Thomas, Armando Prieto and Juan Escalante are students from Venezuela, they took our Open EHRGen framework and improve it to create an EMR for the SOS Telemedicine for Venezuela project. They can give you more information about the project specifics. We don't have an entry for openEHRGen either - thomas ___ 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/20120319/d65a3091/attachment.html
Are you doing an academic project using openEHR?
Hi Thomas, Armando Prieto and Juan Escalante are students from Venezuela, they took our Open EHRGen framework and improve it to create an EMR for the SOS Telemedicine for Venezuela project. They can give you more information about the project specifics. -- 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: Sun, 18 Mar 2012 14:30:28 + From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Are you doing an academic project using openEHR? The academic projects page on the website lists currently known projects. I am sure that there are more today. Please let us know if you have a project, and the details of it, we will post it on this page. - thomas beale ___ 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/20120318/7dcfe0f2/attachment.html
openEHR - Persistence of Data
Hi Randolph, My answer was bounced by the list manager, I tried to send an attachment with the current DB schema :( Anyway, this schema is generated on the startup of the server, so anybody that download and test the framework could generate the schema and see how information is stored, but remember: this is automatically generated by the ORM, so is better to understand the class model first. -- 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: pazospa...@hotmail.com To: openehr-technical at openehr.org Subject: RE: openEHR - Persistence of Data Date: Fri, 24 Feb 2012 07:45:10 -0300 Hi Randolph, I'm on travel but you can see the model.png here http://code.google.com/p/open-ehr-gen-framework/downloads/list to get an idea of the RM classes we implemented.This has changed a little because of bug fixes and added support to other functionalities. Attached is the schema of the current DB. Maybe later I can give you more detail. Thank you for your interest in the project. Date: Thu, 23 Feb 2012 22:09:34 -0500 Subject: Re: openEHR - Persistence of Data From: randy.ne...@veriquant.com To: openehr-technical at openehr.org Thank you, Pablo. I spent some time with your Grail reference. It looks like a very robust tool! Can I ask how complex your schema is? How many tables (or representations of classes) and how complex the relations are? And can you give some indication of the sheer size of your production DB? I'm curious what a Grail schema would look like capable of OpenEHR, and how large the data capacity can be, how well it scales. I will have to review again what is involved with your Reference Model, something I did some years ago, but have forgotten. Ultimately, the actual information described by specific archetypes (which are themselves a kind of class OOP system, right?) must be sent to the database. My understanding was that at that level some, if not most, OpenEHR implementations were using XML or some sort of blob rather than discrete rows and columns. Not so with you and Grail? The more I think about this, the more I'd be interested in your schema. Do you mean to tell me that with your implementation you do not persist the final level of archtyped data in document representations like XML nor do you use BLOBS whose internals cannot be queried directly by the DBMS? If so, this would be dramatically different from what I've understood (perhaps mistakenly) Thomas Beale to describe. Do you really have everything in formal DB rows and columns? You might not want to publicize your schema; it would be enough for me to know whether or not you manage to get everything into DB tables, straight from Grail objects. Thanks again! Randolph Neall On Wed, Feb 22, 2012 at 7:22 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Randolph, OK, what you say is reassuring. One of the things I had admired about OpenEHR was what I thought you were violating with ORM, which, in many contexts does exactly what I described, but evidently not in yours. That depends on each implementation, we decided to implement the RM as close as possible to the specs. The ORM tool does the heavy work managing all the SQL stuff (we don't write SQL we do object-oriented queries using a criteria API http://grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20(GORM).html). The schema is generated when you start the server, so all the process is automatic, and no need to generated or regenerate classes. I don't quite understand why a schema would be generated when the server starts if the schema does not change relative to domain-specific content. But this is a minor point, something I don't need to understand. That's the way the framework works (http://grails.org/). But I must specify that the schema is generated when the server starts when you are in DEVELOPMENT mode. In PRODUCTION mode, this schema generation is done the first time you deploy the application on an application server. But this is just how the tool we choose work... Also, your classes are themselves apparently quite abstract, allowing all kinds of content to be housed in them, thus reducing the number of classes to some maneagable number. Nope, we have RM classes and framework classes that handle all the logic. There is one class implemented in EHRGen by each class on the openEHR RM specs (or at least it should). So, no abstract classes here (abstract in OO has other meaning), only classes straight from the specs, this is a considerable quantity but it's a fixed number (not growing). You can see the classes in our SVN repo. We had around 80+ classes implemented from the openEHR RM specs. Now we don't support classes like EHR, EHR_STATUS, LINK and some others, but we plan to do it. Those are no needed for a small EMR system. Am
openEHR - Persistence of Data
Hi Randolph, I've commented between your lines. -- 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 Hi Pablo, I'm sorry for being so slow responding to your questions. I may not be understanding you fully, nor have I made myself totally clear to you. First, a DLL is a file system file known as a Dynamic Link Library, a unit of compiled machine-executable code, typically invoked from a computer code file with a .EXE extension or from another DLL file, with a .DLL file name extension. These naming conventions are used by Microsoft Windows programs, but may not be used by other platforms, which which I am unfamiliar. Of course, but in these context I rather prefer to give platform independent answers :D The ORM approach, as you describe it (correct me if I'm wrong), involves the creation of specific classes, expressed as compileable source code, and which therefore end up baked into the executable code files (EXE, DLL, or whatever the equivalent is called on your chosen platform). I am not sure how automated this process actually is in your OpenEHR context. Are you, for instance, able to download an archetype from the OpenEHR web site, press one button in your ORM, and thereby generate a class in your source code, which is then compiled into machine code (in something like a DLL)? And then, after that, with another push of a button, does a schema magically materialize, matching your auto-generated classes? If so, that's wonderful. Yes, you can download and configure and archetype in the system and the system will generate the GUI. We don't need to generate classes for these arcehtypes. The openEHR RM is implemented and it's persistent (I mean you don't need more classes than the RM, that's the point of using a reference model). The ORM persists the openEHR RM clases, and a binding component creates RM instances from user input data.So, there is no class generation and no compilation here.The schema is generated when you start the server, so all the process is automatic, and no need to generated or regenerate classes. The only thing that needs (re)generation is the GUI (just html files). But I have a concern that has nothing to do with automation, and which could actually be aggravated by automation. However automated the class or schema generation is or isn't, and no matter which process comes first (generating the classes or generating the schema), and no matter which process is dependent on the other, you still end up with both a schema and compiled code that will expand with each new class that you create. As I explained, that's not the case: no new code needed and no new schema generation needed to support new archetypes. Code and schemas are fixed. (don't take me wrong, I think you are attached to some technology or solution that is completely diferent of what we tried to implement). That's what I mean by hard-wired. You can do a lot of hard-wired stuff very fast via ORM code or schema generation automation. Your DLLs (or whatever your equivalent is) will expand in size and number. Your schema will grow in size and complexity in direct proportion to the number of classes it is trying to persist. You don't feel the pain, however, because the computer did it all (or a lot of it) for you. Nope, no expansion of code here, only explansion of the config file and the knowledge base (archetypes and templates).You can see the code here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen But you're still left with an end product (consisting of schema and compiled code) that will bloat with each new thing it is designed to express, manage, present and store. That process can go on for a very long time, yes, but it can't go on forever. And the human body, with all the things that can go wrong with that body, ultimately requires thousands, maybe tens of thousands, of classes to describe just what can go wrong with the nervous system, to say nothing of the rest. It seems to me that the better solution would be to develop a metadata-based system capable of describing all that must be expressed, allowing both schema and program code to remain unchanged while presenting to the user information of which the compiled code and schema are both essentially ignorant. In other words, neither the program code nor your schema has any awareness of particular structures of medical information. All of that is instead in the metadata, not schema, in the metadata, not classes. That's exactly what we have done! :DI'm sorry if I didn't explain it correctly. The design is based on this principle: none dependency to custom domain information on the system backend, that dependency is only on the GUI side (the only thing we need to generate). My mistake in all this may be that I am mentally
openEHR - Persistence of Data
Hi Randolph, OK, what you say is reassuring. One of the things I had admired about OpenEHR was what I thought you were violating with ORM, which, in many contexts does exactly what I described, but evidently not in yours. That depends on each implementation, we decided to implement the RM as close as possible to the specs. The ORM tool does the heavy work managing all the SQL stuff (we don't write SQL we do object-oriented queries using a criteria API http://grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20(GORM).html). The schema is generated when you start the server, so all the process is automatic, and no need to generated or regenerate classes. I don't quite understand why a schema would be generated when the server starts if the schema does not change relative to domain-specific content. But this is a minor point, something I don't need to understand. That's the way the framework works (http://grails.org/). But I must specify that the schema is generated when the server starts when you are in DEVELOPMENT mode. In PRODUCTION mode, this schema generation is done the first time you deploy the application on an application server. But this is just how the tool we choose work... Also, your classes are themselves apparently quite abstract, allowing all kinds of content to be housed in them, thus reducing the number of classes to some maneagable number. Nope, we have RM classes and framework classes that handle all the logic. There is one class implemented in EHRGen by each class on the openEHR RM specs (or at least it should). So, no abstract classes here (abstract in OO has other meaning), only classes straight from the specs, this is a considerable quantity but it's a fixed number (not growing). You can see the classes in our SVN repo. We had around 80+ classes implemented from the openEHR RM specs. Now we don't support classes like EHR, EHR_STATUS, LINK and some others, but we plan to do it. Those are no needed for a small EMR system. Am I correct that GUI generation, the one thing you say you do generate, is simply a matter of generating html? Yep, just html with forms for data entry, and labels for data display. If you are interested in the project, you could download and try it and you'll see the things I told you here (an image is better than a thousand words :D) Kind regards,Pablo. Thanks very much! Randy Neall On Wed, Feb 22, 2012 at 11:18 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Randolph, I've commented between your lines. -- 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 Hi Pablo, I'm sorry for being so slow responding to your questions. I may not be understanding you fully, nor have I made myself totally clear to you. First, a DLL is a file system file known as a Dynamic Link Library, a unit of compiled machine-executable code, typically invoked from a computer code file with a .EXE extension or from another DLL file, with a .DLL file name extension. These naming conventions are used by Microsoft Windows programs, but may not be used by other platforms, which which I am unfamiliar. Of course, but in these context I rather prefer to give platform independent answers :D The ORM approach, as you describe it (correct me if I'm wrong), involves the creation of specific classes, expressed as compileable source code, and which therefore end up baked into the executable code files (EXE, DLL, or whatever the equivalent is called on your chosen platform). I am not sure how automated this process actually is in your OpenEHR context. Are you, for instance, able to download an archetype from the OpenEHR web site, press one button in your ORM, and thereby generate a class in your source code, which is then compiled into machine code (in something like a DLL)? And then, after that, with another push of a button, does a schema magically materialize, matching your auto-generated classes? If so, that's wonderful. Yes, you can download and configure and archetype in the system and the system will generate the GUI. We don't need to generate classes for these arcehtypes. The openEHR RM is implemented and it's persistent (I mean you don't need more classes than the RM, that's the point of using a reference model). The ORM persists the openEHR RM clases, and a binding component creates RM instances from user input data. So, there is no class generation and no compilation here. The schema is generated when you start the server, so all the process is automatic, and no need to generated or regenerate classes. The only thing that needs (re)generation is the GUI (just html files). But I have a concern that has nothing to do with automation, and which could actually be aggravated by automation. However automated the class or schema generation is or isn't
Meaningful Use and Beyond - O'Reilly press - errata
Hi Fred, The OpenEHR notion, on the other hand, is to create a core substrate within the EHR design itself which facilitates interoperability automatically. (is that right? I am trying to digest what you are saying here). Trying to solve the same problem on the front side as it were. I think that's more acurated, but substrate is a little ambiguous here, I rather say that openEHR propose a generic standarized architecture based on the dual model (separate software from custom domain concepts). That architecture enables/simplifies interoperability later because the information to be interchanged between systems is formally defined (by archetypes: http://www.openehr.org/knowledge/). So any communication protocol and data format could be used for interoperability, and systems could interchange not only data, but the information definition too. The key here is that within an openEHR based system, other standards like HL7, DICOM, SNOMED, MeSH, UMLS, ICD10, ... could be implemented to, each one for it's own task. Hope that helps. -- 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20120218/90d1a760/attachment.html
openEHR - Persistence of Data
Hi Randolph, The problem with ORM systems would ultimately be a rather bloated schema and hard-wired classes to accommodate that schema. Yes and no, it depends on your configuration. One configuration could end up using only on talbe with many columns, other configurations could break up this table to normalize the schema. I don't understand the hard-wired classes to accommodate that schema, the openEHR RM is an Object Oriented model, a programmer should implement the model on the ORM tool and the schema should be generated from those classes, in fact is the schema what accommodates to the classes. So, for new versions of the RM, a new schema could be generated, an mappings between those schemas could be generated to (for data migration, if needed). Yes, ORM lets you automate the creation of DB data structures and classes, but, once created, they become part of the schema and your DLLs, which is fine until you have many hundreds of them (tables and classes defined in autogenerated code, etc.). Yes, you'll end up with a schema, a fixed one, that depends on the RM version you use, if the RM version change, the schema should change too, but the RM version you'll use will be very stable, nd I'm sure that only one version of the RM will be in use at a time. ORM generates the schema for the classes (source code), not the classes for the schema, so we don't have autogenerated code. This is my experience and the way I think this should be done, because the openEHR Reference Model is Object Oriented, so a programmer could easily program those classes and user an ORM tool to generate the database structure. DLLs? Kind regards,Pablo. Randy Neall Veriquant, L.L.C. On Thu, Feb 16, 2012 at 5:26 PM, pablo pazos pazospablo at hotmail.com wrote: Hi M?rcio, There is no standard persistence model, the persistence mechanism is not in the standard scope. There are many ways of storing openEHR RM instances (archetyped data), the only thing to take into account is that the information to store will be highly hierarchical. Said that, in EHRGen [1] we use a relational model with an Object-Relational Mapping [2] tool (GORM from Grails Framework[3]). The advantage of that is that you have a complete and validated RM instance persisted on the DB, and you can query for complete objects or single data ELEMENTS. I've written ORM tools myself [4] and the main problem is the amount of joins you need to load a complete structure, but in my experience you never load a complete structure for a real time interaction with the user, and you alway can cach? some data. This approach is straight forward, because all you need are the classes of the RM, and you delegate DB stuff to the ORM tool. Other models are viable too, like K/V [5] or EAV [6] approaches (mentioned by Bert). This approaches are fast for saving and loading data, the problem is that you need to have some complex logic above that for constructing a complete RM instance on memory, because K/V is a flat representation of a higly hierarchical tree structure. Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Hope that helps. [1] http://code.google.com/p/open-ehr-gen-framework/ [2] http://grails.org/ [3] http://en.wikipedia.org/wiki/Object-relational_mapping [4] http://code.google.com/p/yupp/ [5] http://en.wikipedia.org/wiki/NoSQL [6] http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model -- 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: mdcko...@gmail.com Date: Thu, 16 Feb 2012 16:53:19 -0300 Subject: openEHR - Persistence of Data To: openehr-technical at openehr.org Hello guys, i'm starting a research about the persistence model of Archetype data, that stores the information entered by the user of the system. I would like to know if there is a indication of the openEHR standard for what kind of model schema should be used in DataBase, and if there are researchs in this area. Thanks in advance, M?rcio Costa B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr
openEHR - Persistence of Data
Hi Erik, you are right, the uglyness depends on 1. the queries you want to execute and 2. the programmer background. For 1. the common queries like get all records for this patient in this time window, are not that ugly, but more complex queries could be.For 2. for a XML guy, writing xPath based queries is ok, but for a SQL is a pain in the a55. :D I'm hoping to see that paper on AQL-xQuery soon! I totally agree that inside the system maybe you don't need a complete RM structure to handle data instances, but for the service layer (sharing information with other systems) this is a must. -- 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, 17 Feb 2012 16:21:29 +0100 Subject: Re: openEHR - Persistence of Data From: erik.sundvall at liu.se To: openehr-technical at openehr.org Hi! On Thu, Feb 16, 2012 at 23:26, pablo pazos pazospablo at hotmail.com wrote: Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Not necessarily that ugly... we curently auto-convert AQL to XQuery and execute towards an XML database. Those queries are very readable. Then the question is what kind of client system you are aiming at. For some use cases you don't really need to map things back to openEHR-RM-objects, in web browser based GUIs for example you can keep treating the data as documents, document fragments, fragment lists etc. and use DOM manipulations, jQuery or similar approaches for most data manipulation needs. Good luck with your work M?rcio and please keep us informed! Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/89e04227/attachment.html
Meaningful Use and Beyond - O'Reilly press - errata
Hi Fred, some comments between your lines. Hope we can help you to get the v2.0 of the book soon :D -- 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: fred.trot...@gmail.com Date: Thu, 16 Feb 2012 19:12:13 -0600 Subject: Re: Meaningful Use and Beyond - O'Reilly press - errata To: openehr-technical at openehr.org As Thomas said, openEHR is not about open source, is about an open standard for globally interoperable EHR architecture. ... I also state in the book: OpenGALEN and OpenEHR are both attempts to promote open source ontology con- cepts. Both of the projects have been maturing but some view these as unnecessary additions or alternatives to SNOMED+UMLS. However, they are available under open source licensing terms might make them a better alternative to SNOMED for certain jurisdictions. Then I wrote: OpenEHR is a controversial approach to applying knowledge engineering principles to the entire EHR, including things like the user interfaces. You might think of Open- EHR as an ontology for EHR software design. Many health informaticists disagree on the usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive nature, is the highest level to which formal clinical knowledge managing needs to go. Now, these are complex statements about OpenEHR. I am sure I might have gotten some of the details about OpenEHR wrong here. If I have done that, then please help correct me. I am all ears. The problem here is about context. Comparing adoption for things that are not comparable is not a good thing for any of the SDOs behind the standards and for your readers. People could be really confused about those statements. I agree, and that is a fact, that HL7 RIM is more used than openEHR RM. But what really matters is: what are they used for? Comparing a model that was designed for creating messages with an standard that is more than an information model, as openEHR, is nonsense. Also comparing openEHR vs. SNOMED+UMLS (how an EHR architecture could be compared with a vocabulary?). Again, yes, those other standards are being used more than openEHR, but openEHR was not meant for the area of application of those other standards, in fact openEHR+HL7+SNOMED+UMLS can be implemented all together in the same system to solve different problems. Just an argument to this point: this is like comparing the use level of Ethernet with the use level of HTTP, yes Ethernet is used more because is behind a big part of the network communications, but Eth and HTTP are for different things. Here is the bottom line reality: the Open Source EHR space has matured dramatically in the last 10 years. There are handful of projects that I know of that have literally hundreds of installations worldwide: the VistA variants, OpenMRS, OpenEMR, and ClearHealth. There are some other important projects that have potential, like Tolven, that I know of, but they simply have not garnered hundreds of installations. I would be very happy to be proven wrong here, but as far as I know, there is no Open Source EHR that has been installed at even over 100 sites that has been based on the OpenEHR. openEHR is not about open source: there are openEHR open source EHRs and propietary openEHR EHRs.http://www.openehr.org/shared-resources/usage/commercial.html ... At this point my mental summary for OpenEHR is one of the many technically right but will never be adopted technology ideas. I cannot write a book which is intended to warn IT people about all of the fruitless investments that they should expect to see all over the place in Health IT and give OpenEHR a free pass because I know and like some of the founders. I agree in the idea of giving facts instead of oppinions (likes/dislikes). The problem is that you are giving wrong facts, not on the adoption side of the coin, but on the current definition, scope and goals of openEHR. IMO the way you are describing openEHR now diminishes what openEHR is and what is intented for. The main idea behind giving facts is not to promote or demean a standard, is all about facts. When I talk about standards, and I do talks not only on openEHR, I try to give context on what problems we have on Health IT and how those standars fit to solve each problem. And the public of those talks are not health IT experts. IMHO, if a book is written about health IT and mention standards, those standards should be in a framework of 1. what are the current problems, 2. what standards apply for each problem, that should suffice for general IT professionals (not healthcare specific). About adoption: adoption is a process, and our community is walking forward. Is a fact that TODAY the adption level is poor, but as Thomas said, we need to look for what we'll do tomorrow. Is OpenEHR a relevant technology or an interesting foot note
openEHR - Persistence of Data
Hi M?rcio, There is no standard persistence model, the persistence mechanism is not in the standard scope. There are many ways of storing openEHR RM instances (archetyped data), the only thing to take into account is that the information to store will be highly hierarchical. Said that, in EHRGen [1] we use a relational model with an Object-Relational Mapping [2] tool (GORM from Grails Framework[3]). The advantage of that is that you have a complete and validated RM instance persisted on the DB, and you can query for complete objects or single data ELEMENTS. I've written ORM tools myself [4] and the main problem is the amount of joins you need to load a complete structure, but in my experience you never load a complete structure for a real time interaction with the user, and you alway can cach? some data. This approach is straight forward, because all you need are the classes of the RM, and you delegate DB stuff to the ORM tool. Other models are viable too, like K/V [5] or EAV [6] approaches (mentioned by Bert). This approaches are fast for saving and loading data, the problem is that you need to have some complex logic above that for constructing a complete RM instance on memory, because K/V is a flat representation of a higly hierarchical tree structure. Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Hope that helps. [1] http://code.google.com/p/open-ehr-gen-framework/ [2] http://grails.org/[3] http://en.wikipedia.org/wiki/Object-relational_mapping [4] http://code.google.com/p/yupp/[5] http://en.wikipedia.org/wiki/NoSQL[6] http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model -- 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: mdcko...@gmail.com Date: Thu, 16 Feb 2012 16:53:19 -0300 Subject: openEHR - Persistence of Data To: openehr-technical at openehr.org Hello guys, i'm starting a research about the persistence model of Archetype data, that stores the information entered by the user of the system. I would like to know if there is a indication of the openEHR standard for what kind of model schema should be used in DataBase, and if there are researchs in this area. Thanks in advance, M?rcio Costa B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120216/6351fcf2/attachment.html
Meaningful Use and Beyond - O'Reilly press - errata
Comparing openEHR with SNOMED is plain wrong. Yes, part of the openEHR standard is an ontology of concepts, but this are high level concepts to model generic information structures, in the other hand SNOMED models fine grain concepts, with almost no structure. Certainly here is a place to collaboration since fine grain concepts could be use onside the generic model structures. So, here is no competition, is realy a good collaboration ground. Cheers,Pablo. Secondly, a nonsensical statement about openEHR in the book... p.161OpenGALEN and OpenEHR are both attempts to promote open source ontology con-cepts. Both of the projects have been maturing but some view these as unnecessaryadditions or alternatives to SNOMED+UMLS. However, they are available under open source licensing terms might make them a better alternative to SNOMED for certainjurisdictions. And this, p163... OpenEHR is a controversial approach to applying knowledge engineering principles to the entire EHR, including things like the user interfaces. You might think of Open-EHR as an ontology for EHR software design. Many health informaticists disagree onthe usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive nature, is the highest level to which formal clinical knowledge managing needs to go. I'm beginning to lose all respect for O'Reilly press. It's been all downhill since the camel book. CheersMichael Osborne -- Michael Osborne ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120213/344e2b7f/attachment.html
13606 revisited - list proposal
Hi Thomas, Sorry for the delay, I'm working on several projects right now and have little time to follow discussion here. I'm also thinking about the ENTRY model, to lift up the data/description attributes from all entry subclasses to the ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as ITEM_STRUCTURE or as a HISTORY. We did think about this a long time ago, but it did not seem useful. But I assume you are thinking of doing it because you want to make ENTRY a concrete class which could have 'any' structure. Nope, is because I see a common pattern on concreate ENTRY subclases. In theory doing this breaks a basic modelling rule, which is that a superclass whose descendants define the possible data space should not itself be concrete. I think this is not the case, having a ENTRY.data : DATA_STRUCTURE is in fact a more specific ENTRY class, but is still a generic one that could be specialized in many ways. In my (maybe biased) experience, all subclasses from ENTRY would make use of this attribute since a structure is needed to record information. The argument here I suppose is that we want to build in a 13606-style 'uncommitted' kind of ENTRY. In fact we already have this - it's currently called GENERIC_ENTRY. This doesn't get used at the moment (although it has been there for years), and if we want to make it a subtype of ENTRY, that could be done. The main thing to solve I guess is the conversion of any of the specific openEHR kinds of ENTRY into a generic ENTRY structure defined by 13606. This can actually be formally specified by an algorithm. It doesn't require that the parent abstract ENTRY become concrete either. I am unclear if there are other reasons to make the ENTRY parent type concrete, to mimic 13606 ENTRY, rather than simply move GENERIC_ENTRY to be a subtype, which seems more obvious to me. Maybe to have the flexibility to define ACTIONS and other entries to have a data attribute of class ITEM_STRUCTURE or HISTORY to track time of events instead of inventing DV_DATE/DV_DATETIME ELEMENTs on ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. What do you think? Well then I think we risk making the model ambiguous, and different people will use such flexible structures to do the same thing in different ways, which was the thing we were originally trying to avoid. I disagree here, the model semantics could be defined in the specs. My argument is that we are giving a more flexible IM is adding flexibility (not ambiguity) to archetypes, and giving knowledge modelers more options. Then, when they create a concrete archetype, there is no ambiguity because an archetype models a concept in one way, and if abstract classes are used in archetypes, the archetype needs specialization to make is usable on a real environment (software can't instantiate abstract classes, and could not make the decision between using subclass A or subclass B). The HISTORY class is very nicely designed to represent complex time-series data that has the same protocol and was captured in an uinterrupted series. It does not try to model sequences of different types of data - in that case, you just have multiple observations. I totally agree. It deal well with point values, averaged interval values, max, min, sample compression and a few other things. But it's no good with a succession of different kinds of patient events. Any such timeline for that kind of thing has to be constructed post-hoc, when the actual events have already occurred. That's the model semantics that should be defined on the specs. Knowing that, not misuse should happen. In the other hand, tools should not permit this to happen, and this could be implemented as semantic validation of RM instances (BTW this should be done with the current model also). I can see a theoretical argument to wanting HISTORY in ACTION, instead of just a single point time, but in practice, noone has ever been able to come up with an example where a series of ACTIONs needs to look like a structured series, mainly because ACTIONs usually need to get recorded when they are done. IMO ACTION.time:DV_DATE_TIME could have the same semantics as ACTION.data.events[0].time, if ACTION.data:HISTORY and events[0]:POINT_EVENT. The easier example is a repetitive INSTRUCTION like give 5mg of XXX for 10h every 30m:The ACTION would register the same information structureThe proposed POINT_EVENT of the ACTION could record the information like the current ACTION.time attributeThere is a series of ACTIONS recorded for the same INSTRUCTION (instead of creating one ACTION instance for each XXX
Building software to convert HL7 v2/v3 messaging into archetypes templates
Hi Paulo, If I understand correctly, you need a mapping between the HL7 v2.x PID line and some Person archetype of the demographic model: http://www.openehr.org/knowledge/OKM.html#showarchetype_1013.1.479 -- 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: Thu, 9 Feb 2012 17:12:31 + Subject: RE: Building software to convert HL7 v2/v3 messaging into archetypes templates From: ferreira.rob...@gmail.com To: openehr-technical at openehr.org Hello all,I'm working on my thesis project, which one of the components is EHRstorage in a openEHR repository. Since the input is HL7v2.x messages there isthe necessity of openEHR conversion. I think Heath remembers me, because Heath andChunlan helps me with this issue. I was capable to assemble a small prototypethat includes Mirth, which invokes a Java implementation environment to performthe conversion. The clinical data that that is present in an Unsolicited ObservationResult (ORU^R01) for instance, it?s successfully converted, but withoutdemographic data, neither a patient identification instance. Can you give someclue about this topic? Best Regards,Paulo Ferreira. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120209/6ccb037b/attachment.html
Python / Django experience??
Hi Erik and all, On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote: I don't know if this is crazy talk or if it's seems reasonable to you. Please let me know :D Not crazy, but maybe overly complicated. Maybe I don't present the idea in the best way, but in the end is just some services to advertise/discover artifact repositories/servers, services to do distributed queries, and services for notifications (subscribe/notify). Some of this ideas are in use out there for zillions since Internet born and evoluted. Perhaps it would be a good idea to use a layered approach? 1. An existing distributed version control system (DVCS) like GIT (and an agreed directory structure and naming conventions within it) for storing versioning and distributing archetype source files etc. About using some version control system (VCS), I don't think this is a good solution because the semantics of archetype version are not the same semantics as in plain text versioning (here changing one character will create a new version of the artifact). With VCS you can handle local/internal evolution of an archetype in development, but for a global/public archetype versioning system, IMO this is not the right tool to handle archetype versions (and other artifact versions). I think we need to define the versioning system/semantics/context of an artifact, and then implement this spec on design tools or in each artifact repository. If I'm not mistaken, a discusion about this topic took place a while ago and I don't know if there was consensus on the proposals. Kind regards,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120207/e819e19b/attachment.html
Python / Django experience??
Hi Sam, I agree: we need to consider what are the tools that are needed now to make openEHR more attractive to clinical application developers, and what are the functions of those tools. Here we agreed on the tool chain we need to start openEHR development and promotion. We need a CKM with some special characteristics. The current CKM is great, but we need a completly open source solution to generate confidence from the goverment and institutions. In order to create a good and open CKM, I thought about the minimum functionalities needed (see my email from 2/2/2012), and IMO is better if we could define a common service layer in order to provide this functionality and create a CKM that is capable of interconnecting with other CKMs around the world. The idea of having several CKM instances is to maintain independency, so we don't incur in political issues (having one centralized CKM generates political problems and we end up unable to use available tools). And, if we have several CKM instances (maybe different implementations of the same interfaces and funcionalities) and we want to interconnect them, we need to define some kind of protocol (I don't see another solution). And yes, protocols are tough but we need them. Now I don't see that these problems could be solved by combining some available tools, I think we need to define something new. I hope others can convince otherwise, but this is how I feel right now. -- 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: sam.he...@oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: Python / Django experience?? Date: Wed, 8 Feb 2012 06:29:26 +0930 Hi, We started archetype development in the NHS using Subversion and it got in a real mess very quickly. As Pablo says the version and dependencies are not the same as in code. I think we need to consider what are the tools that are needed now to make openEHR more attractive to clinical application developers, and what are the functions of those tools. Let?s ensure that businesses can thrive working in the openEHR environment and make sure we try and fill the gaps as the first priority. Cheers, Sam -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120207/554bcea7/attachment.html
Python / Django experience??
Hi all, What I've been thinking is to share the same interface/protocol to do simple tasks on distributed CKMs like: Adding an artifact (archetype, template, termset, terminology service, process definition, gui template, etc.), lets think only about archetypes for now.Updating an archetype (with version management)Listing all the archetypesListing all the archetypes for one RM type (i.e. composition, entry, action, etc.)Listing all the archetypes that archetype_id match a regexpListing all the archetypes that match some text (free text search)Retrieve archetype in ADL/XML/JSON/YAML by archetype_id Ian, about the requirements you mention: Basic requirements 1. Query across multiple repositories using multiple criteria, based on something similar to the CKM ontology. For this I think something like DNS protocol will do the job (http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a distributed search by redirecting the query if some server doesn't have the answer. So, if we have a service to register artifacts on CKM servers (service 1. on the list above), with an artifact registered notification protocol, and another protocol for CKM server discovery, we could implement the distributed search. 2. Establish references to remote assets, almost certainly caching the referenced asset locally This would be the a mix of adding and artifact and artifact registered notification protocol. 3. Establish subscriptions to remote assets, to enable change notification etc And this would be included in the CKM server discovery protocol, that could defined like some services provided by the NDP protocol, using messages like RA, NS, NA, ... to discover CKM servers to create a CKM network over Internet: http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch02lev1sec5.html I think some of these services could be found also in the ICMP protocol: http://www.networksorcery.com/enp/protocol/icmp.htm Just to clarify my thoughts, I don't think we need a network protocol!!! I think we could create our protocols to handle artifacts in a distributed way reusing some ideas from those proven protocols that our machines run everyday to connect to the Internet and access distributed resourses. How this stuff could work in reality? We need a set of root CKM servers, always online, that could answer our queries or redirect to some another server that could answer (like DNS).In those servers (could be only one, like openEHR.org CKM), other servers could advertise themselves to form part of the CKM network, this could be done like an ICMP or NDP router advertisement. Those servers could download also a list of servers currently connected to the network, and update the list anytime.The children servers could be not always online, so each entry on the root server registry should have a lifetime, that when reached, the entry is eliminated from the list (like in ICMP http://www.networksorcery.com/enp/protocol/icmp/msg9.htm ). This could trigger a notification to the other members of the network, to update their server list.When an artifact is added to a server, it should notify other servers in the network, so they could know what server has the original copy of the artifact, and maybe they can make a copy of the artifact that sould be read-only on those servers that cache a copy. The cached archetype could have a lifetime, that when reached, a new copy of that archetype should be downloaded from the original server, if the server is still online, or renew the lifetime if the original server is offline.Then a query received by any CKM could be responded or redirected to other server, and all servers in the network could keep up with all the archetypes created worldwide. I don't know if this is crazy talk or if it's seems reasonable to you. Please let me know :D Kind regards,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120202/3d5bc75e/attachment.html
Python / Django experience??
Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that: a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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: Ian.McNicoll at oceaninformatics.com Date: Wed, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/e4138f6c/attachment.html
Python / Django experience??
Hi Ian, it would be nice to share a common API or service layer that both groups can rely on, so we can make our tools compatible in some way.I have an informal list of requirements that this tool should support, maybe we can start sharing our requirements and see if we can agree on a common interface (API/services). -- 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: Ian.McNicoll at oceaninformatics.com Date: Tue, 31 Jan 2012 14:57:20 + Subject: Re: Python / Django experience?? To: openehr-technical at openehr.org Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that: a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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: Ian.McNicoll at oceaninformatics.com Date: Wed, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http
Python / Django experience??
Thanks a lot Roger, it has been corrected, now the working link is: http://4.bp.blogspot.com/-9_P5lrqSaH4/TygHTXUDOnI/E_c/ebyHliBiuaA/s1600/openEHR+Toolchain+ppazos+sm.png The diagram is part of this entry on the outcomes of our first openEHR course in spanish: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html -- 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, 31 Jan 2012 16:05:39 +0100 Subject: Re: Python / Django experience?? From: roger.erens at e-s-c.biz To: openehr-technical at openehr.org This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png Hi Pablo, there's a minor typo in your otherwise great diagram: decision in stead of decition. Cheers, Roger ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/53f657e8/attachment.html
13606 revisited - list proposal
Hi Thomas, I've added a proposal to the page on the wiki http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model I'm also thinking about the ENTRY model, to lift up the data/description attributes from all entry subclasses to the ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as ITEM_STRUCTURE or as a HISTORY. Maybe to have the flexibility to define ACTIONS and other entries to have a data attribute of class ITEM_STRUCTURE or HISTORY to track time of events instead of inventing DV_DATE/DV_DATETIME ELEMENTs on ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. 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: Thu, 15 Dec 2011 15:48:07 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: 13606 revisited - list proposal I have started a wiki page for this 'lower RM' simplification. The top contains the existing models, feel free to add to the 'problem' list (why are we simplifying?). If you have a candidate solution to offer, please put it under a new heading - you will see a 'Candidate B' ready to be used by someone. If we proceed in that fashion, I think we can keep the proposals clear. NOTE: I have only half done my proposal, Candidate A, so don't bother looking at it yet. - thomas On 15/12/2011 14:54, pablo pazos wrote: Hi Erik, I want to implement some simplifications of the item_structure in the EHRGen ( http://code.google.com/p/open-ehr-gen-framework/ ) we talked about this: http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html My focus is on the persistence layer, because we persist data using an ORM (object-relational mapping) component, and the complexity of the relational schema is proportional to the complexity of the object model. BTW, the EHRGen has the complete cicle of information implemented: automatic gui generation (based on archetypes and our gui templates), data validation against archetype constraints, data binding (creation of RM structures from user data input and archetypes), persistence of those structures, and getting data to show on a GUI. Now I'm experimenting with semantic queries (common SQL but based on arcehtype ids and paths). Regards, Pablo. Regarding the RM I know Tom is experimenting with simplified ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other RM-redesign experiments going on anywhere? What is happening in the 13606-world regarding thoughts about practical datatypes? What about (optional) reusable ENTRY subtypes in the 13606 world? (see http://www.openehr.org/mailarchives/openehr-technical/msg05285.html under the heading 2. OBSERVATION et. al. (ISO 13606 CR)) ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/d3898636/attachment.html
ADL reading
Hi M?rcio, The EHRGen tool does just that: goes through a template with several archetypes and generate an user interface (HTML)http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/views/guiGen/create/_generarCreate.gsp Docs and downloads:http://code.google.com/p/open-ehr-gen-framework/w/list http://code.google.com/p/open-ehr-gen-framework/downloads/list -- 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: mdcko...@gmail.com Date: Mon, 30 Jan 2012 11:43:58 -0300 Subject: Re: ADL reading To: openehr-technical at openehr.org Hello guys, after reading the majority of the docs, i tryed to write a very simple app that: 1. Parse a ADL file to AOM 2. Try to build a Imput Form from respective AOM I'm with problems to find some references of how to use the Tree that the Parser gives to me. Is there some reference for the methods, or examples how to use the output of the Parser to build a Interface? If someone have a simple class, it would be very nice for me since i'm getting started :) Thanks in advance, M?rcio Costa B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/7fb561e3/attachment.html
How to get the URL to an archetype on the CKM?
Thanks a lot for your answers! Helped me 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 From: Ian.McNicoll at oceaninformatics.com Date: Thu, 26 Jan 2012 16:00:56 + Subject: Re: How to get the URL to an archetype on the CKM? To: openehr-technical at openehr.org CC: openehr-clinical at openehr.org Hi Pablo, Open the archetype and press the share with colleague button (Envelope icon) this gives you a few options. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120127/c34e786a/attachment.html
How to get the URL to an archetype on the CKM?
Hi, When I want to show an archetype to someone I have to tell him/her to go to the CKM and do some search.Is there any way to get an URL to display one archetype on the CKM? -- 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20120126/23dd030e/attachment.html
ADL reading
Hi M?rcio, As Ian mentioned, we have developed an EHR tool based on openEHR.The EHRGen has a component to load and cache archetypes on memory, that has the code Athanasios mentioned, you can see it here: http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/src/groovy/archetype_repository/ArchetypeManager.groovy See method getArchetype(archetypId). We use the Java Ref Impl to parse ADL files. Hope that helps. -- 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: Ian.McNicoll at oceaninformatics.com Date: Thu, 26 Jan 2012 18:44:38 + Subject: Re: ADL reading To: openehr-technical at openehr.org Hi Marciio, You should also look at http://code.google.com/p/open-ehr-gen-framework/ The author Pablo Pazos is on this list and will no doubt have how own suggestions. Do not despair - openEHR confusion is a normal pre-requisite to eventual enlightenment :-) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120126/7b1fd0c5/attachment.html
pass_through attribute in ADL 1.5
Hi Heath! Just for the record, I think as Diego: I don't have a problem to have the pass_through attr on templates right now, but we have to comment possible issues with this and other attributes to improve templates in the future. The pass_through view constraint is not a GUI directive, it is a data view directive which is consistent with archetypes/templates being definitions of data structures. Just as form generators may use this data definition to lay out a form and bind to a data instance, it may use this pass_through view constraint to collapse a redundant grouping on a screen. Similarly an XML schema or class generator may use this same constraint to collapse a redundant element grouping. This ensures that screen layout and binding are consistent with the XML schema or class it will bind to. If I understand correctly, the pass_through attribute is only for data displaying on a screen (as you mention the use for data grouping or collapsing). If that's right, I don't think that should be part of the generic template structure, because templates are meant to represent other elements than data views/GUI, like messages, reports, etc. As you mention screen layout and binding are consistent with the XML schema or class it will bind to I feel maybe this is a little attached to Oceans implementation, e.g. in our implementaition we don't have binding with XML Schemas . I historically was of the opinion that GUI only directives such as control type or position should be provided separately as these a really implementation specific and have minimal use in shared artefacts such as archetypes and templates. Having said that the view constraint could easily be used for this purpose if desired. I totally agree with you. Having an operative template with all the data structure in it, the last step should be define the GUI Template with controls, position, style, etc., and that should be the artefact consumed by EHR software for clinical data recording and displaying. The XSD for the view constraint is as follows: xs:complexType name=T_VIEW xs:sequencexs:element name=constraints minOccurs=0 maxOccurs=unbounded xs:complexType xs:sequence xs:element name=items maxOccurs=unbounded xs:complexType xs:sequence xs:element name=value type=xs:anySimpleType/ /xs:sequence xs:attribute name=id type=xs:string use=required//xs:complexType /xs:element /xs:sequencexs:attribute name=path type=xs:string use=required/ /xs:complexType/xs:element /xs:sequence/xs:complexType An example use of this is as follows: template xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns=http://schemas.openehr.org/v1; ? viewconstraints path=/content[openEHR-EHR-OBSERVATION.lab_test.v1]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.specimen.v1]/items[at0046] items id=pass_throughvaluetrue/value /items /constraints /view/template Heath Kind regards,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/cb0b6b65/attachment.html
pass_through attribute in ADL 1.5
Hi Thomas, Maybe we should talk about Presentation templates instead of GUI templates, but I definetly we should separate attributes for data related logic and presentation/GUI logic. Regards,Pablo. Date: Wed, 25 Jan 2012 20:09:51 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 If we had a 'GUI template' facility in openEHR, I am not 100% sure that this pass-through setting would go into it. It's not GUI-specific, but I think it probably is 'presentation-specific', i.e. GUI, reports, any rendering of data onto a display device. Not all display devices are active GUIs: a tablet showing a PDF isn't. Maybe another way of understanding this flag is as 'this node can be skipped without loss of meaning'. I would be very interested to know if we should make AQL queries sensitive to this flag. Has anyone thought about that? - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/1ac951cd/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120125/1ac951cd/attachment.jpg
pass_through attribute in ADL 1.5
Hi Heath,Hi Paplo, Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer. In that case, I think we should separate the uses of the directive. IMO is a little anoying to use the same directive to do semantic processing of the structure and to do GUI generation/customization. If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class. I'm afraid I could not see what you mention, I don't have a licence for the TD. The term view was adopted because it is used in both GUI and data oriented contexts. I can provide the XML schema for this AOM extension used by the template designer if people are interested. It would be nice to see the schema and some documentation about the structure and rationale behind it if you have some (just to understand the XML structure). Cheers, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/e7b661d9/attachment.html
pass_through attribute in ADL 1.5
Hi! From: yampeku at gmail.com Date: Wed, 11 Jan 2012 10:12:39 +0100 Subject: Re: pass_through attribute in ADL 1.5 To: openehr-technical at openehr.org If it is really needed for the moment for representing templates then it's OK with me (as long as we agree that this is a temporal thing), but I still feel that having two separated places to rule UI generation is a bad idea. I totally agree with Diego. I think that annotations could work for you (even creating a new specific ADL section would). We currently have all the GUI directives for representation in a documentation file for each reference model (as you can see in this screen capture http://i.imgur.com/tQxRt.png). This could be extended to general templates in similar way to the one that Pablo has posted. on the other hand, EHRFlex uses a complete MVC architecture, in which the intermediate model (which also depends of your RM) is the one responsible to transform archetypes/templates into classes that the 'view' part can then paint. EHRGen also is MVC but we generate HTML forms for creating editing clinical records, and a other HTMLs for showing individual records (documents/compositions). Maybe we could share our current GUI directive formalisms to think about a new/common formal way to express all the things we need to generate GUI. I also want to work on generation of reports with aggregated data, trying to reuse what we could for the GUI generation for clinical recording viewing. Cheers,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/480d646c/attachment.html
Carriage returns in DV_TEXT not allowed
Hi Thomas, In our RM implementation (Open EHRGen Framework), we use DV_TEXT to keep all kinds of non coded text: words, sentences, paragraphs, documents, etc. We don't use DV_PARAGRAPH. -- 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, 10 Jan 2012 14:19:01 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Carriage returns in DV_TEXT not allowed It would be interesting to know how many other implementers agree with this restriction. It was put in (from memory) in the very early days of modelling, based on GEHR, and possibly somewhat on 13606 - nearly 10 years ago! -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/e2eac81a/attachment.html
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi everyone! There are great ideas here, but if we leave them on the list will be forgotten, so I've created a page on the wiki with some ideas from your emails: http://www.openehr.org/wiki/display/edu/Formalizing+education Feel free to edit the page to improve it. 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120106/110763fe/attachment.html
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi Ian, I think we could probably agree the core training requirements quite quickly but the real problem is how any certification process could be policed and funded. Who trains the trainers, who checks that they are delivering the core content? I think we could break down the problem into certification for students (what they have learned) and certification for trainers (who is validated by the foundation to give quality courses). E.g. a not certificated trainer could make a course for students to study for the certification evaluation, and if they pass, they receive a certification (as students). What is certified here is the evaluation process, not the course itself. The course and the evaluation could be different things, like in english courses (here we pay for a course, and if we want the certificate, we pay for the exam). Obviously, a course given by a certified trainer could be more costly than a course given by a not-certified trainer, but students from both courses could be certified because de evaluation process is the same, and is supported by openEHR.org. I totally agree that certification processes should have a fee for the foundation, but I think the current funding model should change in order to do that (I participated in a discussion not so long ago where we discuss about funding and governance http://www.openehr.org/wiki/display/oecom/Community+Governance). In Ocean we certainly have a set of core training materials but these are adapted and amended for every specific customer - the requirements for a clinical audience is somewhat different from a technical audience or mixed audience and time avaialble differs half-day, one day, three day?? ... and again for a vendor client vs. a national organisation. If we have 'certified training', to what extent does that prevent us from adapting content for specific clients and circumstances - I know this is the case for some UK training certification processes. it is one thing to specify the core requirements but quite another to ensure that these are being properly adhered to. I think the only suggestion I would have for your tool chain diagram is that with ADL1.5 I think we will have the same tool for archetypes and semantic templates i.e non-GUI. We will also need mapping tools for mesage integration and requirements integration and an AQL editing tool. About the tool chain, I've joined archetype and template editors (semantic/structural artifacts), looking forward the new specs, and there is another tool for GUI template edition.I totally agree with the inclusion of AQL/a-path/other querying mechanisms/formalisms and message tools should be included on the chain. Kind regards,Pablo. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 5 January 2012 15:38, pablo pazos pazospablo at hotmail.com wrote: Hi Shinji, I think (hope) that trainers could discuss and agree on the core topics of an standard openEHR course, and then create an upper level layer to localize this core topics to the student's profile and the depth level (basic, intermediate, advanced) required by each course. Maybe I'm oversimplifying something really hard to do, but why not give this a chance? IMO having a specific place to discuss training related topics is the very first step to reach consensus. I'd like to discuss tool chains too! Maybe we can agree on general concepts and implement them on different technologies, that would be the best proof that the openEHR approach works and that doesn't matter what technology do you like. I've a very basic requirement list on each tool mentioned on my blog post diagram (http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png). I've not included datawarehousing tools, but they should be part of the ecosystem 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: Wed, 4 Jan 2012 23:23:19 +0900 Subject: Re: Outcomes conclusions of the openEHR course in spanish ( ideas for the future) From: skoba at moss.gr.jp To: openehr-clinical at openehr.org CC: openehr-implementers at openehr.org; openehr-technical at openehr.org Hi Pablo, and all I perfectly agree your idea. I have thought as you mentioned. I am planning my tool-chains on my Ruby implementation, too. Certification criteria are very difficult to evaluate. Training course would
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi Rene, Hi Pablo, The first idea is on standarizing openEHR training, and to think about an openEHR certification. I think this could be very good for the community and for the openEHR organization too. If we reach a standard minimal program for openEHR courses ... From experiences with an another standard (HL7) based training courses I'd say it may be hard to reach consensus as to what the minimum should be - there is a fair amount of difference between various countries, as well as how one structures a (set of) training courses [e.g. 1 long one, an introductory and an advanced], and the target audience [e.g. clinical, hardcore programmers without any clinical knowledge]. I know it will be difficult to reach consensus, but it's not impossible. Firstly, I think we (trainers) need to sit down and talk about what we think and what we want to do in/with our courses, until now I have not seen any discusions about how to standarize openEHR training and I've been in the openEHR community since 2006, and maybe this initiative could have a good outcome and be beneficial to the community. Now we see many demands of the e-health community, from openEHR software tools, to openEHR training (there is place for everyone!), and I think we need to make a smart move as a community, because these are spreading adoption opportunities for openEHR as a standard. In my case, I think a openEHR course should include the core element: the dual model (IM+AM), at an above basic level, something to help students understand the concepts and let them continue investigating after the course ending. To do so, we need to include basic tooling use (I've included the use of the AR, ADLWB and our EHRGen). Maybe that is enough for a clinical modeler profile, but for a developer is not, they need to understand what to implement in software and in wich way. For that I've created a class on how to implement openEHR in an information system, and I included two approaches: the binding approach (used by Opereffa project) and the autogeneration approach (used by the EHRGen framework). An introductory level course could leave out the tooling chapter. In general the most useful thing for all concerned is probably for the standards organization to make a statement like we know that trainer X provides good quality training courses [this aids the trainer in selling the training course, it aids the prospective attendee as a statement of quality, and it aids the standardization body because it has a known list of educators it can refer to]. Determining who provides a good quality training course may not always be that easy to quantify, but in these relatively small standardization communities (whether openEHR, HL7, DICOM, IHE, etcetera) the nomination for approval can be backed up / seconded (or the reverse: thumbed down) by other known active volunteers. For this community this is very difficult to evaluate, e.g. right now I think I'm the only guy doing an spanish openEHR course, and maybe I'm terrible as a trainer, but there's nobody else to compare with. Obviously, I could show the student's evaluation of my performance on the course, but I'm more concerned about giving a better course (and maybe an openEHR certification) to my students than comparing me with other trainers, since I want to collaborate with them to agree on some topics and ways of evaluation. I know that maybe this is not the way of SDOs, but I believe this should be the openEHR way. I really want to get consensus and work on this subject in 2012 with anyone who want's to collabotare to improve openEHR training. Does anyone think that a openehr-trainers mail list would be helpful to focus the discussion on those subjects? Kind regards,Pablo. TTYL, -Rene -- Rene Spronk Cell: +31 (0)655 363 446 Senior ConsultantFax: +31 (0)318 548 090 Ringholm bv The Netherlands http://www.ringholm.com mailto:Rene.Spronk at ringholm.com twitter:@Ringholmskype:rene_ringholm Ringholm is registered at the Amsterdam KvK reg.# 30155695 Ringholm bv - Making Standards Work - Courses and consulting ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/f7d9cc3d/attachment.html
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi Shinji, I think (hope) that trainers could discuss and agree on the core topics of an standard openEHR course, and then create an upper level layer to localize this core topics to the student's profile and the depth level (basic, intermediate, advanced) required by each course. Maybe I'm oversimplifying something really hard to do, but why not give this a chance? IMO having a specific place to discuss training related topics is the very first step to reach consensus. I'd like to discuss tool chains too! Maybe we can agree on general concepts and implement them on different technologies, that would be the best proof that the openEHR approach works and that doesn't matter what technology do you like. I've a very basic requirement list on each tool mentioned on my blog post diagram (http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png). I've not included datawarehousing tools, but they should be part of the ecosystem 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: Wed, 4 Jan 2012 23:23:19 +0900 Subject: Re: Outcomes conclusions of the openEHR course in spanish ( ideas for the future) From: skoba at moss.gr.jp To: openehr-clinical at openehr.org CC: openehr-implementers at openehr.org; openehr-technical at openehr.org Hi Pablo, and all I perfectly agree your idea. I have thought as you mentioned. I am planning my tool-chains on my Ruby implementation, too. Certification criteria are very difficult to evaluate. Training course would be a homework to localize. Shinji Kobayashi 2012/1/4 pablo pazos pazospablo at hotmail.com: Hi everyone, Recently we have ended the first edition of the course with a huge success. And now we are thinking about the next steps to take. Here is a post on my blog about the conclusions and future actions: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html (yo can see it in english by clicking ENGLISH on the top right corner of the blog). I want to share with the community a couple of ideas mentioned there. It would be very nice to know what you think. openEHR certification: The first idea is on standarizing openEHR training, and to think about an openEHR certification. I think this could be very good for the community and for the openEHR organization too. It could be possible to create a mail list for openEHR trainers (openehr-trainers at openehr.org)? So we could discuss about the topics and ways of evaluation, and come out with an standard minimal program to all openEHR courses. If we reach a standard minimal program for openEHR courses, could we get formal support from openEHR.org to issue internationally valid openEHR certificates? (obviously this is a question for the future, but IMO we need to start thinking about it now). 10 projects to adopt openEHR: We thought about 10 projects (or so) in two areas: software and clinical modeling. Because openEHR propose a tool-chain based process of creating EHRs, we need to have each one of the links of that chain in order to adopt and implement openEHR easily. Now there is a little tooling available, and some of it is not open source. In projects at a national level we need to use open source software, because each country will need to make it's own customizations to each tool. In the other hand, we need to model other things that are clinical knowledge too, like processes and rules to enable CDS, in order to support full EHR implementation (e.g. I think we could recommend ways to express rules based on archetype ids and paths, and create software tools to support that specification, but we need to work the openEHR services specs first). There is a diagram on my blog post that shows the tools we propose to 1. develope if there is no tool that support its functionality or it's closed-source, 2. improve the current open source tools. On the clinical modeling side, we have engaged doctors and nurses on the creation and translation of archetypes. Now there are two of our students that already commited archetypes to the CKM: Dr. Domingo Liotta and Dr. Leonardo Der Jachadurian. I hope we could propose to create prototypes of those projects in out local universities and coordinate the projects so we do not overlap each other, with the objective of completing the tool chain with open source developments. 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 ___ openEHR-clinical mailing list openEHR-clinical at openehr.org
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi everyone! I've updated my post adding the students evaluation of the course: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.htmlFor being the first edition, the evaluation was quite positive. But we still have a lot of things to improve! -- 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: pazospa...@hotmail.com To: openehr-clinical at openehr.org; openehr-technical at openehr.org; openehr-implementers at openehr.org Subject: Outcomes conclusions of the openEHR course in spanish ( ideas for the future) Date: Tue, 3 Jan 2012 18:14:41 -0300 Hi everyone, Recently we have ended the first edition of the course with a huge success. And now we are thinking about the next steps to take. Here is a post on my blog about the conclusions and future actions: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html(yo can see it in english by clicking ENGLISH on the top right corner of the blog). I want to share with the community a couple of ideas mentioned there. It would be very nice to know what you think. openEHR certification: The first idea is on standarizing openEHR training, and to think about an openEHR certification. I think this could be very good for the community and for the openEHR organization too. It could be possible to create a mail list for openEHR trainers (openehr-trainers at openehr.org)? So we could discuss about the topics and ways of evaluation, and come out with an standard minimal program to all openEHR courses. If we reach a standard minimal program for openEHR courses, could we get formal support from openEHR.org to issue internationally valid openEHR certificates? (obviously this is a question for the future, but IMO we need to start thinking about it now). 10 projects to adopt openEHR: We thought about 10 projects (or so) in two areas: software and clinical modeling. Because openEHR propose a tool-chain based process of creating EHRs, we need to have each one of the links of that chain in order to adopt and implement openEHR easily. Now there is a little tooling available, and some of it is not open source. In projects at a national level we need to use open source software, because each country will need to make it's own customizations to each tool. In the other hand, we need to model other things that are clinical knowledge too, like processes and rules to enable CDS, in order to support full EHR implementation (e.g. I think we could recommend ways to express rules based on archetype ids and paths, and create software tools to support that specification, but we need to work the openEHR services specs first). There is a diagram on my blog post that shows the tools we propose to 1. develope if there is no tool that support its functionality or it's closed-source, 2. improve the current open source tools. On the clinical modeling side, we have engaged doctors and nurses on the creation and translation of archetypes. Now there are two of our students that already commited archetypes to the CKM: Dr. Domingo Liotta and Dr. Leonardo Der Jachadurian. I hope we could propose to create prototypes of those projects in out local universities and coordinate the projects so we do not overlap each other, with the objective of completing the tool chain with open source developments. 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/9bd61c04/attachment.html
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi everyone, Recently we have ended the first edition of the course with a huge success. And now we are thinking about the next steps to take. Here is a post on my blog about the conclusions and future actions: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html(yo can see it in english by clicking ENGLISH on the top right corner of the blog). I want to share with the community a couple of ideas mentioned there. It would be very nice to know what you think. openEHR certification: The first idea is on standarizing openEHR training, and to think about an openEHR certification. I think this could be very good for the community and for the openEHR organization too. It could be possible to create a mail list for openEHR trainers (openehr-trainers at openehr.org)? So we could discuss about the topics and ways of evaluation, and come out with an standard minimal program to all openEHR courses. If we reach a standard minimal program for openEHR courses, could we get formal support from openEHR.org to issue internationally valid openEHR certificates? (obviously this is a question for the future, but IMO we need to start thinking about it now). 10 projects to adopt openEHR: We thought about 10 projects (or so) in two areas: software and clinical modeling. Because openEHR propose a tool-chain based process of creating EHRs, we need to have each one of the links of that chain in order to adopt and implement openEHR easily. Now there is a little tooling available, and some of it is not open source. In projects at a national level we need to use open source software, because each country will need to make it's own customizations to each tool. In the other hand, we need to model other things that are clinical knowledge too, like processes and rules to enable CDS, in order to support full EHR implementation (e.g. I think we could recommend ways to express rules based on archetype ids and paths, and create software tools to support that specification, but we need to work the openEHR services specs first). There is a diagram on my blog post that shows the tools we propose to 1. develope if there is no tool that support its functionality or it's closed-source, 2. improve the current open source tools. On the clinical modeling side, we have engaged doctors and nurses on the creation and translation of archetypes. Now there are two of our students that already commited archetypes to the CKM: Dr. Domingo Liotta and Dr. Leonardo Der Jachadurian. I hope we could propose to create prototypes of those projects in out local universities and coordinate the projects so we do not overlap each other, with the objective of completing the tool chain with open source developments. 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120103/b31f499a/attachment.html
13606 revisited - list proposal
Great! this will be THE opportunity to think about an IM 2.0, and the first topic on my wishlist is the simplification of ITEM_STRUCTURE children :D -- 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: Thu, 15 Dec 2011 00:49:20 + From: thomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: 13606 revisited - list proposal At the CIMI meeting last week and elsewhere, I have noticed a lot of interest in the ISO 13606 2012 revision, specifically in a) whether the openEHR and 13606 reference models can be brought together for part 1 of the revision and b) in finalising ADL/AOM 1.5 for providing a new snapshot to ISO for part 2. It seems to me that it would be useful to have a dedicated place to discuss this, so I would like to propose a new mailing list, 13606-alignment at openehr.org Does this seem like a useful idea? - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/41c00947/attachment.html
13606 revisited - list proposal
That's the simplification we need to the IM 2.0! :D -- 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: Thu, 15 Dec 2011 08:30:46 +0100 Subject: Re: 13606 revisited - list proposal To: openehr-technical at openehr.org technically speaking, CLUSTER is already simpler in current 13606 model :) 2011/12/15 pablo pazos pazospablo at hotmail.com: Great! this will be THE opportunity to think about an IM 2.0, and the first topic on my wishlist is the simplification of ITEM_STRUCTURE children :D -- 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/242f8ce5/attachment.html
13606 revisited - list proposal
Hi Gerard, is good to know! please publish the link to the wiki discussion when available. -- 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: 13606 revisited - list proposal From: gf...@luna.nl Date: Thu, 15 Dec 2011 11:33:17 +0100 To: openehr-technical at openehr.org Dear Pablos, Internally in the EN13606 Association I started to work on this renewal.The EN13606 Association will start to think about all 5 parts of the standard. With respect to 13606 part 1 - the reference model- I think we will have discussions on topics such as:- scope- Folders- Semantic links- the structure below the Entry Class- the type of relationships between the Composition/section classes used to structure documents and the Entry, Cluster and Element classes that define the clinical content. Possibly other members will have their own topics they want to put on the table.In our EN13606 Association meeting in February in Seville we start the discussions after a consultation phase.openEHR will be part of this consultation phase. Any input from openEHR is welcomed.A WIKI page will be started anytime soon on our website.After these discussions our suggestions will be submitted to CEN/tc251 and ISO/tc215. For more information about the EN13606 Association and the Seville meeting I refer to:www.en13606.orgNon-members that want to participate in this meeting are invited to subscribe. Gerard Freriks+31 620347088gfrer at luna.nl On 15 dec. 2011, at 05:03, pablo pazos wrote:Great! this will be THE opportunity to think about an IM 2.0, and the first topic on my wishlist is the simplification of ITEM_STRUCTURE children :D -- 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-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/b2b20f4b/attachment.html
Questions about the relationship between Instruction, workflow and Action
Hi Heather, You give me a lot to thought about. In my mind I was reserving the creation of actions, observations, instructions and evaluations only for clinical staff, now I see that administrative clerks could also create (directly or indirectly) actions on the clinical record. That will suffice for explaining how to implement all the changes in an instruction's state. Thanks a lot for your patience! -- 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: heather.les...@oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: Questions about the relationship between Instruction, workflowand Action Date: Mon, 12 Dec 2011 15:00:13 +1100 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Sunday, 11 December 2011 8:39 AM To: openehr technical Subject: RE: Questions about the relationship between Instruction, workflow and Action Hi Heather, I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, ...) and them a message is sent to the EHR to tell the Instruction had been scheduled. But: how is that change of the Instruction state recorded on the EHR?[HL] The INSTRUCTION for a procedure remains unchanged, unless the clinician changes the nature of the original order and this is carried out with a revision of the committed INSTRUCTION. The ACTION is recording the progress of activity in carrying out the INSTRUCTION ? ie the procedure is planned, scheduled, performed, completed and at each of these pathway steps the appropriate data is captured eg what procedure is scheduled and the scheduled time; and what/ when was actually finally performed etc. What was actually done/performed/administered may be different to what was originally ordered due to clinical circumstances etc ? the ACTION allows this evolution to be captured. Yet through all this the original instruction/order persists as is. I understood that part and agree 100%: We have the record of the original Instruction untouched, or if it need a change from a clinical point of view, this will be a new version/revision of the previous Instruction. Receiving a message from an external system could trigger the creation of an ACTION? [HL] It could trigger the creation of an ACTION if received from a scheduling system and there had been no ACTION created previously. That same newly created ACTION could then be used to record the data against subsequent pathway steps.OR the message could be used to trigger an entry using the existing ACTION containing the Scheduled data against the Scheduled pathway. That's the problematic point I see on the use of an ACTION to record something that is merely administrative and may have no clinical relevancy.[HL] From my point of view, it may be an administrative detail, but just the fact that something has been scheduled (without necessarily details of the time/date/location) is a valuable part of a clinical record. It does have clinical relevance as it records what has been done in the steps required to carry out at order/INSTRUCTION. While a non-clinical person may have technically carried out the ACTION, it is still critical info in the clinical record, still a ?clinical action? IMO.An ACTION should be ... Used to record a clinical action that has been performed, which may have been ad hoc, or due to the execution of an Activity in an Instruction workflow. Every Action corresponds to a careflow step of some kind or another. (http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 73). I think we could analize this topic through an implementation (I think that's what you and Sam have mentioned) with the solution of having messages triggering ACTION creation or recording data on existing ACTIONs.[HL] It is not at all simple to envisage how the flow of INSTRUCTION and various resulting ACTIONS play out, and I can?t pretend to have it all 100% clear, but with implementations (and Heath Frankel certainly has plenty of recent experience) it is proving to work in practice. But I think we need to revise the openEHR specs, to see if this topic is clear enough, because I don't see a clear solution in the standard itself (maybe others could have better luck than mine).Or maybe this is one of those things that are not defined by the standard, like EHR security or RM persistence, and each implementation could create it's own solution. If that's the case, I think Instruction management is an important issue on EHR development and it should be considered on the specs. And my small contribution on this is that maybe ADMIN ENTRIES could also trigger/record
13606 revisited - list proposal
Hi Erik, I want to implement some simplifications of the item_structure in the EHRGen ( http://code.google.com/p/open-ehr-gen-framework/ ) we talked about this: http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html My focus is on the persistence layer, because we persist data using an ORM (object-relational mapping) component, and the complexity of the relational schema is proportional to the complexity of the object model. BTW, the EHRGen has the complete cicle of information implemented: automatic gui generation (based on archetypes and our gui templates), data validation against archetype constraints, data binding (creation of RM structures from user data input and archetypes), persistence of those structures, and getting data to show on a GUI. Now I'm experimenting with semantic queries (common SQL but based on arcehtype ids and paths). Regards,Pablo. Regarding the RM I know Tom is experimenting with simplified ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other RM-redesign experiments going on anywhere? What is happening in the 13606-world regarding thoughts about practical datatypes? What about (optional) reusable ENTRY subtypes in the 13606 world? (see http://www.openehr.org/mailarchives/openehr-technical/msg05285.html under the heading 2. OBSERVATION et. al. (ISO 13606 CR)) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/428ef9aa/attachment.html
Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5?
Hi, I'm working with archetypes that have DV_CODED_TEXT nodes, and those nodes are always constrained by C_COMPLEX_OBJECT, not by C_CODED_TEXT. And the internal constraint is C_CODE_PHRASE. Is there any case that use the C_CODED_TEXT constraint instead of the combination of C_COMPLEX_OBJECT/C_CODE_PHRASE? Thanks! -- 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/41dea152/attachment.html
Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5?
Thank you Thomas, I was creating some docs for the openEHR course and I missed that aom.pdf annex A was just an example!!! (there is where I saw the C_CODED_TEXT) My bad, sorry for that :D -- 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: Thu, 8 Dec 2011 19:16:55 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5? On 08/12/2011 16:56, pablo pazos wrote: Hi, I'm working with archetypes that have DV_CODED_TEXT nodes, and those nodes are always constrained by C_COMPLEX_OBJECT, not by C_CODED_TEXT. And the internal constraint is C_CODE_PHRASE. Is there any case that use the C_CODED_TEXT constraint instead of the combination of C_COMPLEX_OBJECT/C_CODE_PHRASE? Thanks! -- Hi Pablo, there are three C_xxx special types, that allow CODE_PHRASE, DV_QUANTITY and DV_ORDINAL to be more conveniently constrained than if the standard C_COMPLEX_OBJECT approach were used: C_CODE_PHRASE, C_DV_QUANTITY and C_DV_ORDINAL. These types are described in the openEHR Archetype Profile (There is no C_CODED_TEXT type defined there). Our experience is that these types are used nearly universally because they express the typical semantics much more easily that the standard ADL would. The parent class C_DOMAIN_TYPE is the plug-in point for more such classes. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/695e5aaf/attachment.html
Questions about the relationship between Instruction, workflow and Action
Hi Sam, thanks for the answer... I'm having several hours of bad sleeping, trying to understand this :D Hi Pablo, The design principles are that the Instruction should remain unaltered by people basing actions on this instructions ? as the action and instructions could be disconnected at any moment. For example, the instruction (medication order) should not be changed by anyone just to give a medication etc. Sounds very reasonable. But I think that sometimes administrative entries could also change the state of an Instruction, like when scheduling a procedure. I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, ...) and them a message is sent to the EHR to tell the Instruction had been scheduled. But: how is that change of the Instruction state recorded on the EHR?Receiving a message from an external system could trigger the creation of an ACTION?Is that the way you have implemented that? So the state of the instruction is carried in the record of the action (if appropriate). Is that recorded on ACTION.instruction_details.wf_details? We have decided to name the pathway steps and attach a machine readable state to that step. This makes it much easier for clinicians to model and to see what is going on. You will see an archetype ACTION in the openEHR repository and the careflow_steps are archetyped to provide a name and the current state matches an openEHR code for state. This means that a careflow step being carried out will set the state to a particular machine state. I think I saw that on the ehr_im.pdf as an example for UK GP medicaton order workflow. As I understand it, this can be done by constraining the ACTION.ism_transition attribute, with the Archetype Editor, for all the ACTIONS that will be used to execute ACTIVITIES of the medication order INSTRUCTION. If that's right (?), maybe there's a bug on the specs, because ISM_TRANSITION inherits from PATHABLE, and to be archetyped I think it should inherit from LOCATABLE (see ehr_im.pdf page 53). For the workflow definition, do you use the INSTRUCTION.wf_definition? I can't find an example on how to express a workflow there (maybe something like this could help http://doc.openerp.com/v6.0/developer/3_9_Workflow_Business_Process/index.html). In our openEHR repository we maintain an instruction index ? that is a pointer to all instructions and all actions that relate to that instruction ? and the current state of the instruction. Ok, so at an instance level, we should have all INSTRUCTION instances, the current state of each instruction, and all the ACTIONs executed for each INSTRUCTION/ACTIVITY.That is a great implementation consideration, I'll add that on the openEHR spanish course docs. :D Thanks a lot! Cheers,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/d5cbedfd/attachment.html
Questions about the relationship between Instruction, workflow and Action
Hi everyone! I'm trying to understand how to execute a state machine of a fully structured INSTRUCTION, and I have some questions and thoughts to share with you... The first issue is about archetyping an ACTION that execute and ACTIVITY of an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype the ACTION.ism_transition attribute, but not the ACTION.instruction_details. Both attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS) are specializations of PATHABLE, so those shouldn't be archetypable (see http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 53).Is this a bug in the AE or is an issue in the specs? If the ACTION.instruction_details attribute can't be archetyped in the AE, how could I know what specific structure the ACTION.instruction_details.wf_details attribute will have? Is the ACTION.instruction_details.wf_details attribute related somehow with the ACTIVITY.description attribute? The description of the ACTION.instruction_details.wf_details attribute says: condition that fired to cause this Action to be done (with actual variables substituted),What is the meaning of with actual variables substituted? This makes me think having an ACTIVITY in memory, creating an instance of an ACTION to record the execution of that ACTIVITY, copying the ACTIVITY.description structure into the ACTION.instruction_details.wf_details, and the update the correspondent fields into the wf_details with actual execution data. Does this make any sense? or I'm just to twisted :D The last one!Now only ACTIONs can change a state on the ISM, but I think an ADMIN_ESTRY could change the state also, e.g. to move a planned procedure to the scheduled state, there is an administrative step of coordinating date time, not a clinical action. Again, does this make any sense?! 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111204/c51453b5/attachment.html
Bosphorus web services beta announcement
Thank you Seref impressive work! I'll try the JSON services to do some javascript gui generation. -- 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, 15 Nov 2011 09:45:18 + Subject: Bosphorus web services beta announcement From: serefari...@kurumsalteknoloji.com To: openehr-technical at openehr.org Dear members of the openEHR community, Having reached a point where project Bosphorus has reached a functional state, we have deployed and experimental web service under Opereffa's current server. The web service exposes the archetype parser functionality of Thomas Beale's Eiffel code base with XML and JSON output. There is a simple web application at http://opereffa.chime.ucl.ac.uk/bosphorus/ which uses this web service to display XML and JSON output. The web service is as simple as possible to use: calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslist returns an XML list of the archetypes in repository, and calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype with the archetype name as the parameter such as: http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype?archetypeName=openEHR-EHR-CLUSTER.case_identification.v1 returns the XML output. Simply changing the URLS to http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslistjson and http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypejson allows access to JSON output. There are known issues in the XML output, which we are fixing at the moment, but we felt that the current state of the code is capable enough to share with the community, to demonstrate the idea of turning key openEHR infrastructure functionality into web services. Thanks to functionality of the Eiffel reference implementation, this web service handles the processing of ADL 1.5 specific features and its XML output is valid according to published XML schemas (version 1.0.1). Please note that the XML or JSON output is only data, therefore its content must be placed into an AOM implementation to become a complete parser output, and we look forward to hearing from implementers, especially in the Java space to collaborate on this. In the near future, we are going to be extending the set of services, and we would be glad to hear about your ideas for new web services in the tooling space. The packaging and release of code will follow soon, but it will take time since Bosphorus has a fairly complicated development setup, requiring Java, C/C++ and Eiffel development setups to be configured jointly. The reference deployment of the web service is therefore the most practical way of experimenting with functionality. There are issues related to serialization of various AOM items, and it you notice errors in the XML output, please let us know so that we can fix them. We would like to thank Thomas Beale of Ocean Informatics for providing access to his Eiffel source code and his contributions to this work, which enables us to share our work with the community. Kind regards Seref Arikan Professor David Ingram, UCL, CHIME ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2015/f7fc7e65/attachment.html
Bosphorus web services beta announcement
No problem, I'm sure this could be used to GUI generation, since we already had this implemented, but we need to represent our templates with JSON too to do a 100% javascript GUI generator, now I have translate our XML templates to JSON and do a couple of tests. I'll let you know when I have something to show. -- 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, 15 Nov 2011 15:27:28 + Subject: Re: Bosphorus web services beta announcement From: serefari...@kurumsalteknoloji.com To: openehr-technical at openehr.org Thanks Pablo, I'm going to be updating the service today, and it is not a production service, but if you have any issues do let me know. It would be interesting to see if this can support a gui generation scenario. Please let us know how it goes! Kind regards Seref On Tue, Nov 15, 2011 at 3:19 PM, pablo pazos pazospablo at hotmail.com wrote: Thank you Seref impressive work! I'll try the JSON services to do some javascript gui generation. -- 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, 15 Nov 2011 09:45:18 + Subject: Bosphorus web services beta announcement From: serefari...@kurumsalteknoloji.com To: openehr-technical at openehr.org Dear members of the openEHR community, Having reached a point where project Bosphorus has reached a functional state, we have deployed and experimental web service under Opereffa's current server. The web service exposes the archetype parser functionality of Thomas Beale's Eiffel code base with XML and JSON output. There is a simple web application at http://opereffa.chime.ucl.ac.uk/bosphorus/ which uses this web service to display XML and JSON output. The web service is as simple as possible to use: calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslist returns an XML list of the archetypes in repository, and calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype with the archetype name as the parameter such as: http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype?archetypeName=openEHR-EHR-CLUSTER.case_identification.v1 returns the XML output. Simply changing the URLS to http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslistjson and http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypejson allows access to JSON output. There are known issues in the XML output, which we are fixing at the moment, but we felt that the current state of the code is capable enough to share with the community, to demonstrate the idea of turning key openEHR infrastructure functionality into web services. Thanks to functionality of the Eiffel reference implementation, this web service handles the processing of ADL 1.5 specific features and its XML output is valid according to published XML schemas (version 1.0.1). Please note that the XML or JSON output is only data, therefore its content must be placed into an AOM implementation to become a complete parser output, and we look forward to hearing from implementers, especially in the Java space to collaborate on this. In the near future, we are going to be extending the set of services, and we would be glad to hear about your ideas for new web services in the tooling space. The packaging and release of code will follow soon, but it will take time since Bosphorus has a fairly complicated development setup, requiring Java, C/C++ and Eiffel development setups to be configured jointly. The reference deployment of the web service is therefore the most practical way of experimenting with functionality. There are issues related to serialization of various AOM items, and it you notice errors in the XML output, please let us know so that we can fix them. We would like to thank Thomas Beale of Ocean Informatics for providing access to his Eiffel source code and his contributions to this work, which enables us to share our work with the community. Kind regards Seref Arikan Professor David Ingram, UCL, CHIME ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part
occurrences and cardinality in ADL, XML, JSON
Hi Thomas, do you have some examples of the JSON produced with your P_ classes
from a couple AOM instances? It would be nice to see the results.
I don't see why anyone would dislike not to have each node's type specified in
the serialization form when we are talking about a schema-less format (I mean:
we don't need to put each node's class in every instance of a JSON/YAML
serialization from an AOM instance) and if we could agree a specification of
this format (and the specification will have each nodes type, or a mapping to
an AOM object that has a type defined in the AOM specs).
This is not the issue, but I don't like the name persistence for the package,
because I get the idea this is only for persisting something, but what I realy
want to do is to use the serialization for archetype interchange (between a
server and a web browser).
--
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, 12 Nov 2011 01:04:22 +
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: occurrences and cardinality in ADL, XML, JSON
On 11/11/2011 16:21, pablo pazos wrote:
Hi, I was thinking of this a lot: using a schema-less formats to
represent archetypes and RM instances.
I think if we agree on a common
language/standard/definition, we don't need to define the
types of any node on a JSON/YAML structure, because those
types are defined on the laguage/standard/definition those
structures will follow. And if we define a good serialization
to JSON/YAML of archetypes and RM instances, we don't need a
schema to share instances of those structures, we just need to
implement the serialization definitions, and base the parsing
on the attribute names.
What do you think?
PS: I was thinking of archetypes serialized to JSON because I
want to build a web-based GUI Generation layer completely
implemented with Javascript (JSON objects are javascript
objects), so we can useshare this thin layer to show
archetype-based GUI generation easily, and, if we have a REST
layer that implement EHR-Server services, we can user that GUI
layer to send data input to the server and get information to
show (a complete circle). If anyone want to collaborate on the
JSON format of ADL/AOM please send contact me.
--
Again, I agree with this point of view. But XML people may not
but now I should clarify something...
I should have explained on other thing: what I have done in the
current AOM 1.5 implementation (but not yet documented) is to create
a parallel set of P_XX classes ('P_' means 'persistent') like
P_ARCHETYPE, P_C_OBJECT and so on. These classes formally specify
the serialised form of the archetype so there can be no ambiguity.
It is these classes that current have occurrences, cardinality and
existence defined as String properties. There are a few other
simplifications as well. My proposal is to add these P_XX class
definitions to the specification. It mihgt seem like slight overkill
(and I resisted it for a long time) but once I implemented it, it
seems worthwhile, and it allows us to separate the in-memory
computable version of the AOM from a P_ version whose sole purpose
is serialisation. The Eiffel P_ classes are here;
it is easy to imagine what the Java, Python etc would look like.
So Pablo's argument, applied to the P_ classes would indeed mean
that the serialised form in JSON, YAML (also dADL) is a pure
consequence of the P_AOM classes, and no extra logic is needed. That
is why I built the P_ classes.
- thomas
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2011/2518f9fa/attachment.html
Serialisation of openEHR Models
I still want to see the glass of water half full: this is in fact a validation and the recognition of an emblematic member of HL7 that the openEHR approach is useful and needed to reach true interoperability, the name (archetype, data element, ...) is not the important part, neither who invented it first, but the use of the same concept is the key. -- 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 Nov 2011 15:50:42 + From: thomas.be...@oceaninformatics.com To: openehr-clinical at openehr.org Subject: Re: Serialisation of openEHR Models On 07/11/2011 13:54, pablo pazos wrote: Last week I attended to an Ed Hammond's talk in Argentina, and in his presentation he mention a new concept to reach true interoperability: the data element. Please see page 13-14: http://www.hospitalitaliano.org.ar/archivos/noticias_archivos/11/Jornadas2011/11_11.01-03-Hammond-Interoperability-BuenosAires.pdf I asked him why this sounds so much like openEHR archetypes and why don't reuse this concept instead of creating a new one (or at least renaming it). He told me everyone want his own standard, that was very sad. Besides that, what I see (and many people on that room that know what is an archetype) is a validation of an important figure on HL7 that archetypes work, do the job, and are necessary for interoperability. So, I think HL7 is very interested on archetypes right now. I hope that soon Mr. Hammond could do a presentation on standarization that show the best of the breed instead of reinventing/renaming the wheel. -- With all respect to Ed (and he deserves a great deal), if in sentences like the one you quoted above you replace 'everyone' with 'HL7', the situation today starts to make more sense. - thomas ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2007/8dd12a40/attachment.html
openEHR course in spanish
Hi Sam, That's the idea first an overview and later all the details and all the fun :D I have an introduction from a workshop I made last year that shows how we create software today, and how our way of creating software is a problem in the healthcare domain. I'll use this introduction with some hidden references to key points of openEHR like having all the clinical knowledge outside the software application instead of having it hardcoded on the software. Good point, I'll try to introduce the tools earlier. But I need practice! (my experience with the ADL Workbench is very limited). Thank you Sam. Cheers,Pablo. From: sam.he...@oceaninformatics.com To: openehr-technical at openehr.org; openehr-clinical at openehr.org; openehr-implementers at openehr.org Subject: RE: openEHR course in spanish Date: Thu, 20 Oct 2011 07:34:48 +0930 Hi PabloThis looks excellent. There is some repetition but it is clear that you are providing an overview in the first classes and drilling down in later classes. I would suggest that you might actually introduce some of the tools a little earlier as people will have more fun if they can build or edit some models.Cheers, Sam From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Tuesday, 18 October 2011 7:36 AM To: openehr clinical; openehr technical; openehr implementers2 Subject: openEHR course in spanish Hi, I'm trying to impart a course on openEHR for spanish speakers audiences, here is the agenda for the course: http://informatica-medica.blogspot.com/2011/10/curso-de-openehr-en-espanol.html Please click on the ENGLISH link on the top-right corner to translate the page. This are my 2 cents in spreading openEHR in the latin-american medical informatics communities. It would be nice to have the feedback of the openEHR community on the topics of the course. Any comments, sugestions, references, resources, etc, are very welcome! -- 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-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111019/27ba49b2/attachment.html
Questions about the necessity of ITEM_SINGLE
Hi! Your comments are very interesting, and I think we all converge to the same point. For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package. We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future. Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists. -- 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20111004/7588c5be/attachment.html
Questions about the necessity of ITEM_SINGLE
Hi everyone, I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework). Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it. Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem(). Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility. 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111003/732ac796/attachment.html
New release of the Open EHR-Gen framework v0.6
Hi everyone! I'm very pleased to annouce the new version of our openEHR-based framework. Here is a description of the release (spanish only): http://informatica-medica.blogspot.com/2011/09/nueva-version-de-openehr-gen-framework.html English (automatically translated): http://translate.google.com/translate?sl=estl=enjs=nprev=_thl=esie=UTF-8layout=2eotf=1u=http%3A%2F%2Finformatica-medica.blogspot.com%2F2011%2F09%2Fnueva-version-de-openehr-gen-framework.html Enjoy! -- 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20110926/a10078c2/attachment.html
Tools for collaborative working
I agree with you both: we need to get things done and find reliable tools up to the task. Many opensource projects use cloud based services, and don't need/try to make everything open source at the infrastructure level. Jira is great for issue reporting and bug tracking. http://www.atlassian.com/software/jira/ Nabble is great for mailing lists. http://www.nabble.com/ (one thing that bothers me is the 40KB limit of the openEHR lists emails) SVN or Git area great for version control. -- 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, 16 Sep 2011 14:51:33 +0200 From: sebastian.ga...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Tools for collaborative working I agree with you Thomas, Whether these tools are open source or just free as in beer (for openEHR) - doesn't matter too much...for me it is far more important that the tool does its job. If there are open source tools that really do the job - finevery fine indeed, but if not, I for one, do not want to use tools just because they are open source if we can have better ones that are just free. Not sure where this discussion stems from, but I am reasonably happy with the current Jira, Confluence and SVN approach and do not think that changing this is a huge priority. (It's not like there isn't anything on the foundation's priority list at the moment :-) ) But I may have missed the reasoning why openEHR's current tooling is not sufficient in the first place? Sebastian Am 16.09.2011 14:22, schrieb Thomas Beale: For openEHR, Atlassian hosted solution JiraStudio (not open source) may be worth considering since it solves the problem of physical hosting without (in theory) causing much disruption, since all the tools are the same - Confluence, Jira (particularly) and SVN. Atlassian bitbucket (completely separate from Atlassian mainstream hosted tools) uses Mercurial, a better DVCS than SVN, but its issue tracking etc is minimal. For the price of more disruption, Github would be one place to go, and it is probably the best DVCS there is (it was designed based on the BitKeeper solution we used to use in openEHR). How good the project tracking tools are I don't know, but they are claimed to be good. The main thing that is needed is integrated DVCS, project / issue tracking (with configurable workflows, security etc), wiki, mailing lists and continuous build server. Whether having everything open source is fundamentally important is debatable - in principle it is nicer, but I am more interested in getting work done efficiently, not battling tools that are in early development (certainly my experience with most free issue tracking systems - maybe the Git one is better). - thomas On 16/09/2011 09:29, Ian McNicoll wrote: Hi Tim, Can you give some examples of good open-source tools in this area? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 16 September 2011 00:09, Timothy Cook timothywayne.cook at gmail.com wrote: Well, maybe you should consider real open source tools. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/859386ea/attachment.html
Tools for collaborative working
This would be great! One thing I am missing for the java project is a build server, something like Apach Continuum that can check out the latest code, compile, run all the testcases, and publish reports and successful builds somewhere. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/bd4e6d9d/attachment.html
Tools for collaborative working
Hi Bert, I have participated in a lot of open source projects, for a long time, that make use of software in the cloud as infrastructure. These projects are long lasting and because the infrastructure is in the cloud, we as users doesn't have to bother with backward compatibility issues. Cheers, Pablo. I wouldn't trust software which is not open source. You cannot judge if it does its job well, especcially in long lasting use, like f.e. a database, how do you know if it still works if your table reach the million records and the table is 127 fields wide with on the second field a VARCHAR (127), I have seen many strange things in software products. What happens if a vendor gives up, or isn't interested anymore in the specific product, or is bankrupt What happens if a vendor decides to break backwards compatibility, or he is just clumsy? -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/41a43f2f/attachment.html
openEHR Transition: two procedural and one licensing question
Hi Sam, Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Cheers, Sam Why we need to define a license to stop someone to copyright or charge for a specialized archetype? I think this could be done by defining user terms to the archetypes downloaded from the CKM (and every CKM around the world must have the same use terms. You can include something like this on the user terms: all artefacts (archetypes, templates, term sets, etc) downloaded from *here* are public and free to use and to specialize. All artefacts derived from those, alse must be free. This is a copyleft scheme. If I want to use artefacts from a public CKM, I must follow those rules. Of course, anyone can create its own CKM and create artefacts from scratch and do whatever they want with those artefacts. I think you can charge for the time you invest in specialize artefacts from public CKMs, but not sell the artifact itself. If you create the artefact from scratch its the creators desition to charge or not. What do you think? Regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110912/1cdf546a/attachment.html
openEHR Transition: Web-based tools?
Hi Ian, As I said before: we build web apps because we are web developers. That doesn't mean that web oriented is better than desktop oriented, it depends on the kind of tool you are building. For an editor, maybe desktop is ok. But if you want an editor on the cloud, is ok too (http://phpanywhere.net/). For shared repositores, I think web-based ans with web services (SOAP or REST) is mandatory. I don't think this discussion about web based vs desktop is in the right direction, I prefer to pay atention to our tool chain, and see what approach is best for each link, e.g.: we could have a perfectly integrated ecosystem with the best of both approaches: archetype editor: desktop based (GUI) template editor: desktop based artefact repository: web based EHR backend: desktop based EHR frontend: web based I think our (GUI) template editor will be opensourced soon. I'll let you know. -- 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: Ian.McNicoll at oceaninformatics.com Date: Sun, 11 Sep 2011 09:38:05 +0100 Subject: Re: openEHR Transition: Web-based tools? To: lavanian at vsnl.net; openehr-technical at openehr.org Hi Dr Lavinian, That was what I had in mind, absolutely integrate with repositories via web-services. I could be persuaded by a full web-based tool if someone could convince that me that difficulties of developing a complex UI are offset by other advantages, that it can operate off-line, that it can quickly implement no-cost, multiple temporary working areas, fully integrate with my other desktop applications and not get mangled by browser updates. I am not at all convinced by the deployment/update argument for web-based tools. It really is not at all difficult to manage packaged downloadable installs, including slip-streamed updates with notifications. I have done this myself with as one developer, 3000 users and a decent install program Perhaps the java environment is harder but my consumer experience of Eclipse and other java apps is not one of horrible complexity. Whilst seamless automatic updating of a web-app is generally helpful, there are situations where such updating conflicts with user wishes, so you end up having to replicate an upgrade only on-demand facility as per Google mail, or 'revert to older version'. But for me the UI issue is critical. I know that javascript and HTML5 developments are improving things all the time but web-based apps are still always more clunky and prone to weirdnesses that you simply do not see with desktop apps. As Seref says this is not the place to document actual UI requirements but I think it is fair to position an archetype/template tool with the UI demands of an Eclipse/VS type application, and as THomas says, no-one is using web apps for this kind of scenario. Pablo - is your web-based template tool visible anywhere? Perhaps you could persuade me that I ma wrong :-) Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 11 September 2011 02:25, Dr Lavanian lavanian at vsnl.net wrote: Hi all, Both approaches have their pros and cons. I would suggest a hybrid approach. Have a desktop app with a local Db that updates itself from a web based repository, as per need. This way you could have the security and speed of a desktop app with the 'updatability' of a web model. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com Visit www.medhelp247.com for a life saving medical service Certified HL7 Specialist Executive Member - IAMI Co-Chair, Memberships - HL7 India Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 - Original Message - From: pablo pazos To: openehr technical Sent: Saturday, September 10, 2011 11:01 PM Subject: RE: openEHR Transition: Web-based tools? Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks
openEHR Transition: Web-based tools?
Hi Peter, Web developers can easily tackle those problems, see below: But web based apps bring their own set of problems that desktop apps don't have. Ian has been talking about poor usability. * How do you do keyboard shortcuts in a web application? How do you set keyboard focus to the appropriate widget to maximise ease of use? Both of those can be achieved in a web app, but it's extremely difficult. Just use HTML: http://en.wikipedia.org/wiki/Access_key * How do you recover gracefully when the user's session times out? Imagine you're in the middle of working on an archetype, you spend 20 minutes talking to a colleague or answering emails, and your web session times out. All of your work is gone. There are ways to handle this gracefully, but they are are horribly difficult to program. This problem simply doesn't exist with desktop apps. One way to maintain a session open is to send heartbeats using AJAX: http://en.wikipedia.org/wiki/Ajax_%28programming%29 * How do you design your application so that it performs well without putting half of your business logic into Javascript that is riddled with hacks for handling old browsers? For performance and rich user interaction we have to use AJAX. For compatibility, use standards: http://www.w3.org/ -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/c173aafd/attachment.html
openEHR Transition: Web-based tools?
Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks and web standards and I have very little experience on desktop based tools. Said that, I think desktop based tools have the same value and usability as the web based ones. There are tools that by nature have to be web based, but other tools like the template editor is ok on desktop. I have the dream that one day I open just one program (a web browser) and get free access to all the archetypes and templates available in the cloud (multiple CKMs), and may create, edit and share those artefacts also online. Sometimes I think about something like an openEHR facebook, where archetypes are people, templates are groups, and all are related by slots (friend relationships). This is just a dream... -- 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: Ian.McNicoll at oceaninformatics.com Date: Fri, 9 Sep 2011 16:10:10 +0100 Subject: openEHR Transition: Web-based tools? To: openehr-technical at openehr.org Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository. However, I am much less clear on why we might need web-based primary authoring tools for archetypes and templates. Diego, Pablo and Sam are all keen on this approach but I remain unconvinced that this is really a key requirement, given that archetype authoring is in essence a solitary activity much like any other code development. By all means build in much better integration with repositories and other mechanisms to allow joint working, but even with modern javascript libraries and Flex-style components, HTML-based tooling just feels like it adds a layer of development complexity and probably some usability-clunkiness which is not offset by the benefits. Maybe I am just an old-timer but having waited for may years to get the kind of development environment that Visual Studio, Eclipse and equivalents bring, and that I think is equally required for archetype development, I am loathe for us to get slowed-down by insisting on a 'web-based'. What do others think? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/b1bca7a3/attachment.html
openEHR Transition: Community Knowledge repository
Hi David, I think the current tools are as good as one can imagine for this moment, what I mentioned was of the tools we need to the future, and maybe some ideas to add to the whitepaper. (I wanted to be clear in this point, sometimes my bad english doesn't let me to express my ideas in a clear way, sorry for that). What I meant with freeopen tools was ment for the local and regional CKMs, and with a clear API, we could develope local CKMs that are interoperable with the global CKM (without changing any of the current great work). Thank you David, I'm here to help in any way I can. I'm sure that openEHR is the way to go and I'm sure that we need to move forward together. There are a lot of great professionals in this community and I have learned and grow a lot since the first time I worked with openEHR in 2006. I regret there aren't more coleagues from south america participating on this great community, that's why I insist with the local openEHR communities, to engage this people (and selfishly to don't feel so lonely :D). Cheers, Pablo. -- 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: Wed, 7 Sep 2011 20:39:05 +0100 From: rmhi...@live.ucl.ac.uk To: openehr-clinical at openehr.org Subject: Re: openEHR Transition: Community Knowledge repository Hi Pablo - re- your important observation below. It was a difficult decision to go with a proprietary product to underpin the openEHR CKM, but at the time there was no apparent open source tool to provide the first stage functionality required. It is complex and expensive software to develop and maintain and, through the good offices of Sam and Ocean, we secured a free license to support the CKM repository, which we were thereby enabled to make quickly available for experimental use. Of course, open-source tools are not cost and resource neutral options, but it is certainly easier for many to engage along an open source pathway of development. That said, I believe that going with the proprietary CKM was a sensible decision at the time (it was and had to be Dipak's and mine, I should say, and in no way an Ocean decision). It has certainly been fully vindicated, in my eyes, by the free use that has been made of it, which we can observe day by day, within both the openEHR community and several cognate groupings, all over the world, exploring and working with the archetypes now residing in the public CKM repository that Ocean has generously created and maintained throughout, for the openEHR community. Looking forward, Ian's link with Derek Hoy/Snowcloud and the offer he has made, is interesting and potentially a very useful new thread in the tooling agenda for openEHR. I don't think anyone imagines we are near to an ideal tooling environment to support effective clinical engagement with archetype/template/terminology development and support. The field will undoubtedly benefit from concerted and coordinated efforts to create new and better open source tooling in this area - a goal that is dear to many clinicians' hearts, I know - Tony Shannon and Dipak Kalra, to name but two! Forgive my inquisitiveness, Pablo, but I have just located and read your impressive CV and you seem exactly the right sort of person to join with others discussing here, in taking forward an initiative like that for the openEHR community. Once Sam and the new board (fully operational from October 1st) has given time for its current consultation about future governance to evolve into decisions about next steps, I very much hope there will be a way for you to do so. David I -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/9c69212d/attachment.html
openEHR Transition: two procedural and one licensing question
I agree with you Shinji, well said! -- 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: Wed, 7 Sep 2011 21:15:34 +0900 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org Hi Sam and all Thank you for comments about localisation. First of all, I emphasize LOCALISATION is not ISOLATION. Only to fork and arrange global resource for local usage is isolation. True localisation is to feed back such experience to enrich core implementation. I think endorsement program at page 4 of white book should include localisation as global promotion, and endorsement / promotion program should have a board like other specification / clinical modeling / software engineering. Because local activity management depends on its own domestic situation, local governance should be decided by local community. However, bad localisation disgrace all of our community and makes people unhappy in its area. So I think local activity requirements are, * Keep contact with global community * Implement openEHR clinical models for domestic use. * Provide proper translation, specialised implementation for their domain. * Promote openEHR specification for their domain.(Web/mailing list) * Governance of local community as good status * Feed back localisation experience to global community. I also think two or three of these conditions are enough to be a local activity. These are my requests from Japan(probably from other local activities, too) * Permit to use openEHR name and logo for domestic promotion. * Publish local activity directory for whom need to contact with them on the openEHR.org web. * Disallow to use openEHR name and logo whenf you think we are not worth to use. * Keep contact with local activities. Cheers, Shinji KOBAYASHI 2011/9/7 Sam Heard sam.heard at oceaninformatics.com: Hi Pablo and Shinji Supporting localization both technical and operational needs to be included. The no language primacy principle is a real winner, different written forms of the same language is not covered as yet. How local groups run is another, clearly these can be national or context based. Thanks for the input. Cheers Sam Sent from my phone On 07/09/2011, at 2:38 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Shinji, That's exactly what I tried to point in another mail to the lists: local and regional openEHR organizations should be supported by openEHR and we need to put it into the white paper. -- 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, 6 Sep 2011 19:13:45 +0300 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org Hi All, I have been suffered by sever jet lag after long trip, while I have been thinking about this new white paper and our local activity. I could not find such localisation activity in this white paper, but please consider and mention about such local activity. I would like to show these two proposals. 1) Local activity support. As a global standard, localisation to each country or area is necessary. My three years experience to implementation of the Ruby codes, archetypes and template, we need lots of localisation efforts for Japanese use. I think this experience may be available to localise for other countries. East Asian countries people is keen in openEHR development and their engagements are promising for their health care. 2) Premature artefact repository CKM provides us well-considered archetypes and templates. This is a great knowledge resource for mankind. However, to incubate archetype as a common concept takes long time like vintage wine. On the other hand, I need more agile movement for daily development. I have developed about 50 archetypes and 6 templates. These artefacts are still premature to evaluate on CKM, but I would like to discuss about my artefacts on line with many people. Yes, it will be a 99% junk repository, but 1% diamond would be a precious for our community. As Major league cannot exist without minor leagues, I think CKM needs such minor artefacts groups. I am preparing to share them on GitHub, because anyone can use repository for each use by fork and merge request is useful. I think the licence of this repository would adopt CC-BY-SA, is this OK, Erik and Ian? Cheers, Shinji KOBAYASHI(in Japan, a path of typhoon.) 2011/9/6 Erik Sundvall erik.sundvall at liu.se: Thanks for replying Sam! Erik Wrote (to openEHR-technical at openehr.org
openEHR Transition Announcement (about regional/national openehr organizations)
Hi Ian, So, my question back, is What sort of support would you like to see, given that significant central resourcing is not likely in the short term? I think we (local/regional organizations working with and on openEHR) need formal support from the openEHR fundation. One basic form of support is to recognize the local/regional openEHR organizatons as such. Other is to recognize our contributions to the community, like mentioning our work on presentations, publications and other public communications (I think a public communications strategy should be traced by openEHR foundation). If we think of money, there are ways of money support without giving real money: we need software tools (archetype template editors), we need access to events far away, we need books, educational resources, etc, etc. The foundation should draw yearly general goals, to the openEHR project as a whole, and to the local/regional representatives. And should follow and coordinate the work and evaluate the results. Those goals could be technical, educational, communicational, among other kinds. Here is a related thread with some other ideas: http://www.openehr.org/mailarchives/openehr-implementers/msg00889.html What do you think? Regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110907/e2f181c7/attachment.html
openEHR Transition: two procedural and one licensing question
Hi Shinji, That's exactly what I tried to point in another mail to the lists: local and regional openEHR organizations should be supported by openEHR and we need to put it into the white paper. -- 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, 6 Sep 2011 19:13:45 +0300 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org Hi All, I have been suffered by sever jet lag after long trip, while I have been thinking about this new white paper and our local activity. I could not find such localisation activity in this white paper, but please consider and mention about such local activity. I would like to show these two proposals. 1) Local activity support. As a global standard, localisation to each country or area is necessary. My three years experience to implementation of the Ruby codes, archetypes and template, we need lots of localisation efforts for Japanese use. I think this experience may be available to localise for other countries. East Asian countries people is keen in openEHR development and their engagements are promising for their health care. 2) Premature artefact repository CKM provides us well-considered archetypes and templates. This is a great knowledge resource for mankind. However, to incubate archetype as a common concept takes long time like vintage wine. On the other hand, I need more agile movement for daily development. I have developed about 50 archetypes and 6 templates. These artefacts are still premature to evaluate on CKM, but I would like to discuss about my artefacts on line with many people. Yes, it will be a 99% junk repository, but 1% diamond would be a precious for our community. As Major league cannot exist without minor leagues, I think CKM needs such minor artefacts groups. I am preparing to share them on GitHub, because anyone can use repository for each use by fork and merge request is useful. I think the licence of this repository would adopt CC-BY-SA, is this OK, Erik and Ian? Cheers, Shinji KOBAYASHI(in Japan, a path of typhoon.) 2011/9/6 Erik Sundvall erik.sundvall at liu.se: Thanks for replying Sam! Erik Wrote (to openEHR-technical at openehr.org): Was that whitepaper formally ratified by the new board, or by the old board, or is it's current state just a suggestion by Sam? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] The whitepaper was ratified by the participants in the planning process, the current Board (Profs. Kalra, Ingram and myself) and the new Transitional Board. This is a bit worrying for the period until a broader board can be elected. I was hoping that somebody within the new board would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR?s key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The if organisations embrace these arrangements part is worrying, especially since we already have seen failed attempts at getting buy-in from organisations. Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start no matter if big organisations have made use of the introductory offer of buying a position in the board? If not, we risk having an interim board forever, and we really don't need any more delays in the journey towards community-driven governance. If you get buy-in from the number of big players you want before that absolute end date then there would be nothing stopping you from doing the transition earlier than the latest date. Erik wrote: The thoughts behind the third point in the Principles of licencing
openEHR Transition Announcement (about regional/national openehr organizations)
Great, please let me know if I can help. -- 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: openEHR Transition Announcement (about regional/national openehr organizations) From: sam.he...@oceaninformatics.com Date: Wed, 7 Sep 2011 07:15:26 +1000 To: openehr-technical at openehr.org Hi Pablo It needs to be added. Thanks Sam Sent from my phone On 07/09/2011, at 1:38 AM, pablo pazos pazospablo at hotmail.com wrote: Hi, Not so long ago we have discussed about a governance and organization model to the openEHR community, and we have talked about regional/national openEHR communities (http://www.openehr.org/wiki/display/oecom/Foundation+Organisational+Structure). I can't find this mentioned in the whitepaper. I think if we want to have a global impact on the ehr scene, we need to support those communities also, and define ways to coordinate the work of the community as a whole. 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, 5 Sep 2011 02:00:45 +0100 From: thomas.be...@oceaninformatics.com To: openehr-announce at openehr.org Subject: [openEHR-announce] openEHR Transition Announcement Dear All, I am writing on behalf of the new Transitional Board of openEHR to share our plans to take openEHR to a new level of operations; a new structure, business model and governance. Our vision is the creation of a thriving community that works collaboratively to benefit humanity through efficient and effective electronic health records (EHRs) that support the highest quality health care for the least effort. Until now, the openEHR Foundation has functioned as an owner of intellectual property, governed by University College London and Ocean Informatics, with board members Prof David Ingram (UCL), Prof Dipak Kalra (UCL) and Dr Sam Heard (Ocean). With the support of the considerable community of Members and via engagement of a new category of sponsoring organisational Member known as ?Associates? - Companies, Universities and Governments - the Transitional Board proposes a number of changes: The openEHR Foundation becomes an operational non-profit organisation with paid key staff and resources; The Board (of governance) of the Foundation is extended to up to 10 people with a shift to election by the openEHR Associates; Members who participate are recognised by their peers, may take on decision-making roles, and have the right to commit changes to the key development assets of the Foundation. The Members will participate individually and, through qualification by peer recognition, will control the development within the three Programmes that are building the key assets: The openEHR specifications of the logical health record and attendant services as well as the methods for describing the content using archetypes (Detailed Clinical Models) and templates; and The openEHR archetypes and templates to be used within systems and for message content between systems to achieve interoperability; and The openEHR software projects, to provide open source development of tools to support the uptake and use of the specifications and templates. A group of Members will be needed to bootstrap each of these programmes and determine the working arrangements that are suitable to the products that they are managing at the current stage of development. The Associates will determine who governs the Foundation by nominating and voting on new members of the Board. The Board will appoint key Operational staff and will approve the leader of each of the Programmes. The Programme Leaders will be appointed by Qualified Members working in that Programme, subject to Board approval. We believe this will create the right balance between the ?ground up? creation of openEHR through participation of Members and ?top down? governance. The first step is to share with you a white paper providing more detail on the proposals and to ensure that the Members are reasonably satisfied that this is the right direction to head. Some key
openEHR Transition: two procedural and one licensing question
Hi, I think Diego's point is to change this ... directly interacting with the Clinical Knowledge Manager and equivalent repository and review toolsto something like ... to interact with any Clinical Knowledge Manager through a standard API (to be defined). -- 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, 5 Sep 2011 21:49:01 +0100 Subject: Re: openEHR Transition: two procedural and one licensing question From: ian.mcnic...@oceaninformatics.com To: openehr-technical at openehr.org Hi Diego, I understand from Sebastian that you have been exploring the current CKM web services. Do you think these might form the basis for an open repository API or do you have any other comments or alternative suggestions? Ian On Monday, 5 September 2011, Sam Heard sam.heard at oceaninformatics.com wrote: Thanks Diego [Sam Heard] This would be a step forward and would allow for slim and fat systems to offer the same basic calls. My suggestion is for the this point Begin an open source software project for tools, web-based if possible, to author archetypes, templates and terminology reference sets directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools I agree with the first part (create web-based open source tools), but I think that the second part should be clarified. We should define a basic API to access repositories, to avoid doing ad-hoc implementations for each one of the possible repositories ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110905/d139ddbb/attachment.html
CCR model
Hi Koray, here you can find a simplified CCR model from google health: http://code.google.com/intl/es/apis/health/ccrg_reference.html -- 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: k.atalag at auckland.ac.nz To: openehr-clinical at openehr.org; openehr-technical at openehr.org Subject: CCR model Date: Mon, 11 Jul 2011 01:36:22 + Hi All, I need CCR model ASAP. has anyone worked on this. Possible to share? Cheers, -koray ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110711/631f076c/attachment.html
Regarding the use of the dual model approach and openEHR in clinical trial management software
Hi Athanasios, We have implemented the two level modeling approach in our OpenEHR-Gen project: http://code.google.com/p/open-ehr-gen-framework/ It is a generic system (a framework), so it can handle virtually any kind of archetyped data. If you have any questions, I'll be happy to help. -- 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, 10 Jun 2011 14:00:06 +0100 From: athanasios.anastasiou at plymouth.ac.uk To: openehr-technical at openehr.org; openehr-clinical at chime.ucl.ac.uk Subject: Regarding the use of the dual model approach and openEHR in clinical trial management software Hello everyone I was just wondering if there are any projects out there that have been looking at employing the dual model approach to describe clinical trial data or that are using openEHR at the back-end (?) I may be searching in the literature using the wrong (and obvious) terms but nothing much is coming up so far. Looking forward to hearing from you Athanasios Anastasiou ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110623/08776bb1/attachment.html
I'm looking for opportunities to do my master studies
Hi everyone, I've been around the openEHR community since 2006, when I met the medical informatics domain. I've been facinated with this field since then, and I've been learning all I could about it. Now I've have my degree in computer ingeneering, and I want to continue my studies on medical informatics and the application of standards. This email goes to the openEHR lists because I know there is a lot of academic participation, and I would be glad to know if there are any opportunity to take some courses related to my specialization area to start my master degree studies at your university. If you could drop me a line privately, I'll be grateful. Thanks a lot, Pablo. -- 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20110613/93584f56/attachment.html
Dual Model EHR implementation
I agree with Alan. In OpenEHR-Gen, we have modeled almost all the classes between Folder and Datatypes (Folder, Composition, Section, Entry, Item, DvText, etc) and represented all those concepts in our DB schema. Here you can find our data model: http://code.google.com/p/open-ehr-gen-framework/downloads/detail?name=model.png I think my friend Alan refer to our implementation of the OpenEHR-Gen Framework, that automaticaly generates the DB Schema from the Reference Model classes we programed in Grails Framework (http://www.grails.org/). Grails have a great ORM tool (Object-Relational Mapping, this is diferent to the ORM mentioned by Alan). Through this experience, we have seen that this complex structured model have some shortcomings on performance, but it do not take hours or minutes to complete tasks like data binding and saving or data querying, and this can be boosted by good servers, fast disks and a good DBMS. What we are doing now is redesigning the data model, dividing the classes in two groups, one groups just for structure classes, and the second group for content classes. The first group have the classes that are part of the structure but don't have clinical content, like Section or Cluster. The second group have the clinical/demographic content like Element or Composition. Then can infer the structure classes from an archetype, we may not include them into the persistent model, so we'll model only the content classes, and add some metainfo to help reconstruct the complete RM structure as if it has been persisted on the database. So, in the persistent layer we'll have: archetypes, a reduced persistent RM, and metadata. This will be the next step in our open source project. Hope that helps. -- 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: alandma...@gmail.com To: openehr-technical at openehr.org Subject: RE: Dual Model EHR implementation Date: Fri, 3 Jun 2011 11:24:04 -0300 Hi all. IMHO the best approach (or at least what I have done and feel is reasonable) is to take only some of the classes in the reference model and represent them in the database. I have seen some implementations which adopt an automatic code generation approach, direct from the reference model. But that builds certain structures into the database which are unnecessary and/or may hinder performance. When analyzing the openEHR it seems to me it was not conceived with its database implementation in mind (which is an absolutely reasonable approach). The way information is persisted, I guess, is left to implementators and I believe that is probably Alberto?s issue. To solve the multiple database problem, the structure openEHR database structure could be designed using ORM tools such as that in http://www.ormfoundation.org (again, that is what I have used). I agree that archetypes should pose no performance problem at the database level if care is exercised no to try to represent them in the database. In the final analysis, it seems to me that that is what openEHR is all about: separating (represented, archetyped) knowledge from the (storage) structure From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Alberto Moreno Conde Sent: Friday, June 03, 2011 9:28 AM To: For openEHR technical discussions Subject: Dual Model EHR implementation Dear all, Within the Virgen del Rocio University Hospital we are analysing how to implement a EHR based on Dual Model Approach. When we analysed direct implementation a database based on of either OpenEHR Reference Model or ISO 13606, we have detected that it could have slow performance . Given that we are concerned about this problem, we would like to know possible strategies have been identified by implementers in order to fasten the performance of storage and query. Also the granularity level is one open issue that impacts on the performance, I would like to know if the level of granularity of the archetypes contained within the OpenEHR CKM is able to satisfy the requirements of an EHR with more than 1 million records. Kind Regards AlbertoAlberto Moreno CondeGIT-Grupo de Innovaci?n Tecnol?gica Hospital Universitario Virgen del Roc?o Edif. Centro de Documentaci?n Cl?nica Avanzada Av. Manuel Siurot, s/n. C.P.: 41013SEVILLA ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110607/0ff6d8b8/attachment.html
Dual Model EHR implementation
Randolph Alan, In our approach we will give a shot to store the group of structure classes I mentioned before, directly on a relational DB, in an atomic way (we will have tables and columns to each field, not a blob to store all the structure). With this approach I think we can boost performance about 70%, the big bottleneck in our implementation is de dynamic data binding (put data input from a user in a RM structure), and with this improvements, 1. this logic will be much more simple, 2. the DB schema wil be simpler also. I hope we'll have some results soon. We'll be evaluating performance on MySQL and Postgres DBMSs. The XML approach is our plan B :D This approach is based on some requirements: We need the clinical data on the production DB (that DB is relational, and the clinical data is stores in the content classes I mentioned before.The repository must support querying data at an atomic level without loading a huge amount of data on memory (for example: find all the patients with systolic BP over 130). In the end we need a complete structure: the structure classes can be infered by arcehtypes and metadata (that can be persisted on filesystem, or could be instanced on memory) There are other options too: 1. use an object-oriented dabatase (an ger rid of the Object-Relational Mapping tool), 2. use a document oriented DB: a. a XML native DB or b. a JSON native DB like http://www.mongodb.org/, 3. mix of relational dbs or oo dbs and filesystem (to store documents XML or JSON). Just my 2 cents. -- 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, 7 Jun 2011 16:53:10 -0400 Subject: Re: Dual Model EHR implementation From: randy.ne...@veriquant.com To: openehr-technical at openehr.org Alan, Thanks for clarifying. I thought in your earlier post you had ruled out XML. I was curious what the alternative would be. JSON, as you suggest, would be better. Since writing my post I realized I had not given you credit for one innovation I had not seen before, namely, placing structure classes directly into the DB. That would allow you to keep your JSON content instances relatively small and hence searchable with formal queries, at least to some extent. I could be mistaken, but I think an alternative approach I had heard about on this forum would be to create basically just one blob or just one XML document to contain an entire medical record for a patient, a record that would be extended with each encounter, with the prior instance of the record deleted or at least never referenced again. Again, I will probably be corrected here. Your approach sounds better. Randy On Tue, Jun 7, 2011 at 3:49 PM, Alan March alandmarch at gmail.com wrote: Regarding ?content structures?, these could be persisted as ?objects? in ad hoc field in the database. What kind of objects? And how would any approach of this sort be much better than XML? You'd still have to retrieve, parse or otherwise deserialize the entire blob before you could productively read, or navigate to, the tiniest part of it, taking time and resources. And it would seem that your object would have to be mixed with a lot of instance-level metadata (as in XML), further bloating its size, complexity and internal overhead. And are there non-proprietary ways to do this? I never mentioned blobs. Precisely?XML structures would be one of the best choices (or probably better: a JSON ?object?). If you read on you?ll see that that is precisely what I did in the past. That is why I enclosed the word object with double quotes (meaning to use the concept metaphorically). Serializing (real) runtime objects into XML or JSON ?objects? and storing these ?complex data types? (I should probably have used this terminology) is, to the best of my understanding, the most convenient choice. So I fully agree with your comments. I don't see how the functionality of such objects would greatly exceed that of a PDF text document (possibly including a document-level table of contents), which, at the end of the day, is what a lot of EMR systems essentially amount to. Doctors typically pull up text-based notes often autogenerated from discrete fields never searched upon again and which may even die upon the generation of the note. I understand that one approach is to provide some basic indexed pointers to the blob within the DB, but that does not really overcome the basic problem that blobs pose. Sure. Blobs are ghastly and under no circumstance would I propose their use for storing information of the type we are dealing with here. One could argue that this at least avoids the problems often associated with EAV, but at the expense of easy and efficient access to discrete data elements. If a weight is too heavy to lift one solution is simply not to lift
Dual Model EHR implementation
Hi Alberto, we are working on this subject: http://code.google.com/p/open-ehr-gen-framework/ http://code.google.com/p/open-ehr-gen-framework/wiki/Optimizacion http://code.google.com/p/open-ehr-gen-framework/wiki/EstructurasDeDatos http://www.openehr.org/wiki/display/impl/Playing+with+Pablo%27s+Open+EHR-Gen+Framework -- 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, 3 Jun 2011 14:27:55 +0200 Subject: Dual Model EHR implementation From: albertomorenoco...@gmail.com To: openehr-technical at chime.ucl.ac.uk Dear all, Within the Virgen del Rocio University Hospital we are analysing how to implement a EHR based on Dual Model Approach. When we analysed direct implementation a database based on of either OpenEHR Reference Model or ISO 13606, we have detected that it could have slow performance . Given that we are concerned about this problem, we would like to know possible strategies have been identified by implementers in order to fasten the performance of storage and query. Also the granularity level is one open issue that impacts on the performance, I would like to know if the level of granularity of the archetypes contained within the OpenEHR CKM is able to satisfy the requirements of an EHR with more than 1 million records. Kind Regards Alberto Alberto Moreno Conde GIT-Grupo de Innovaci?n Tecnol?gica Hospital Universitario Virgen del Roc?o Edif. Centro de Documentaci?n Cl?nica Avanzada Av. Manuel Siurot, s/n. C.P.: 41013SEVILLA ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110603/836a5915/attachment.html
Who is using openEHR pages: UPDATES REQUESTED
Hi Thomas, we're developing an open source ehr framework based on openEHR: http://code.google.com/p/open-ehr-gen-framework/ I think this doesn't fall in any category: we started in the academic area, but now we are developing in an independent way. Can you add an opensource category? Thanks. -- 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, 17 May 2011 12:40:36 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org; openehr-clinical at openehr.org Subject: Who is using openEHR pages: UPDATES REQUESTED As the number of organisations using openEHR grows, it would be useful to keep the 'Who is using it' pages up to date. Please review the following pages. commercial orgs government programmes academic organisations non-profit organisations It might be appropriate to move this content to wiki pages, which would enable relevant parties to keep the information up to date themselves - please indicate if this is a preferred approach (note that wiki pages are more susceptible to hacking, and also that organisations need to follow some basic rules of acceptable use, particularly commercial organisations). Alternatively, updates can be made on the web pages by sending email to webmaster at openehr.org. - thomas beale ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110527/dc8a639b/attachment.html
on the possibility of 'one information model' in e-health
Hi Thomas, I agree that the essence of this issue is to detect generic/reusable patters or ontological components, and then derive our information models from these components. Just two thoughts: 1. A marketing issue: If these patterns are directly derived from some existent IM, then we will have the same trouble of defining one common IM: my model is better than yours, so we'll never agree. I think we must represent and present these patterns as ontological components, trying to avoid the copypaste of the pattern from one o the other IM. I know that de openEHR IM is derived from an ontologial analisys of thereality,so we can see it as a concrete ontology for healthcare information, but it is not presented as a concrete ontology, is presented as an IM to be implemented on software. I don't know if I mess up this explanation, just want to tell that we must be careful in the way we present, represent and name things if we want a global agreement. 2. The current openEHR IM is great for dealing with clinical record information and micro clinical processes (Instructions, Activities, Actions and the associated state machine), but not for the macro processes that embrace the micro clinical processes, and for building computerized information systems we need those processes modeled also. For example, if a traumatized patient comes to the ER in an ambulance, and then is derived to an ICU, we have a global process of trauma care, then we have macro processes like prehospitalary care, emergency care, and ICU care. In each of these macro processes we have multiple workflows excecuted in paralel, and different types processes but interdependent like administrative (patient identification, human resource assignation, etc), clinical (observations, actions, evaluation, etc), accounting (resource ussage), and financial (healthcare costs). so, if we model patters or ontological components, I think these must represent (in a generic way) the macro processes, not only the micro-clinical processes. -- 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, 9 May 2011 14:11:07 +0100 From: thomas.be...@oceaninformatics.com To: openehr-clinical at openehr.org Subject: Re: on the possibility of 'one information model' in e-health CC: openehr-technical at openehr.org On 09/05/2011 13:51, pablo pazos wrote: Hi Thomas, I've left a comment in your blog but is not appearing, so I comment your idea here. I don't think today it can be possible to have one information model agreed by all the medical informatics community, but I think if we can agree in a common metamodel like an ontology that represent the more generic concepts in medicine, like people, processes, resources, records, etc, we will be one step closer to a common IM. yes, that's pretty much what I was suggesting. Because if we can agree on that ontology, all the information models in healthcare MUST follow the ontology, so, different information models can live together, but they model the same concepts (semantically speaking). With different models, but semantically equivalent, the point of convergency will be closer. information models, at least abstract ones are in effect an ontology in themselves: they are a description of information that either exists, or we want to exist. So it seems reasonable that a pragmatic UML model, with an appropriate level of abstraction can be used for just this purpose - to describe and agree on key patterns. If this were true, it would mean that the challenges for agreement are: agree on the list of patterns; I have proposed some basic ones; your list above implies another set of candidates to help agreement, some kind of rating system would probably be needed so that at least some 'core' patterns could be agreed, even if some patterns / concepts remained beyond agreement for each pattern, agree its abstract definition. this means defining as much of the pattern in the IM as can be agreed, and not more. An example of one of the patterns, modelled in UML is the 'history of events' one here. Could this or something like it be agreed across e-health for interoperably representing the common concept of a history of events? If sufficient patterns could be agreed, then an 'information model' consisting of these would in effect be a 'common information model' for the medical informatics community - whose scope is interoperable representation of the patterns contained within. It seems to me
openEHR artifact namespace identifiers
Yep, EHR URIs for global operations like referencing a knowledge artifact internal node or in AQL/EQL queries referencing a set of RM nodes are good enough for me. I think our team will start working on querying and reporting in a couple of months when we have a more robust implementation of our openEHR-based tool (http://code.google.com/p/open-ehr-gen-framework/). Then we'll see if the URI approach is enough :D -- 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, 8 Apr 2011 15:19:47 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: openEHR artifact namespace identifiers On 08/04/2011 14:28, pablo pazos wrote: Hi Heath, Just analysing OIDs vs. URIs: Usage: OIDs are in use in health informatics and other areas. URIs are in use everywhere in form of URLs Procesing: OIDs lack internal processing URIs can be processed Compatibility with actual identifiers: Inside archetypes, each node can be identified by a path, so if we use URIs to identify an archetype, just appending the path to the URI we get a valid URI to identify a node inside the archetyp. I go with URIs. if you have a look at the Architecture Overview spec, this is documented in some detail (more is needed... next release ;-). When Tony Shannon and I met a couple of years ago with Tim Berners-Lee, this was almost the only thing he found significant - that we could point to any knowledge model node or data instance node with a proper URI. Of course you can stick an Oid inside a URI, but I am still very unconvinced about Oids. I don't like making things complex when they can be simple. - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110409/caafc24e/attachment.html
openEHR artifact namespace identifiers
Hi Heath, Just analysing OIDs vs. URIs: Usage: OIDs are in use in health informatics and other areas. URIs are in use everywhere in form of URLs Procesing: OIDs lack internal processing URIs can be processed Compatibility with actual identifiers: Inside archetypes, each node can be identified by a path, so if we use URIs to identify an archetype, just appending the path to the URI we get a valid URI to identify a node inside the archetyp. I go with URIs. -- 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: heath.frankel at oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: openEHR artifact namespace identifiers Date: Fri, 8 Apr 2011 10:10:09 +0930 Hi Erik, I was suggesting that we enforce OIDs, in fact my intent was similar to yours, to open up the choice of what is used and not enforce the specially designed ID scheme currently used that requires upgrading to support namespacing making it have the same issues as the standard UID schemes. I like the suggestion of URIs, although I also agree with Tom's later comment that within openEHR implementations we should try to limit the options of the URI schemes used. However, ADL and AOM shouldn't be restricted to this same set, to allow other implementation profiles for other reference models to make their own choices. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Wednesday, 6 April 2011 9:04 PM To: For openEHR technical discussions Subject: Re: openEHR artefact namespace identifiers Hi! On Tue, Apr 5, 2011 at 17:51, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: artefact identification proposals at http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/ am/knowledge_id_system.pdf ... se.skl.epj::openEHR-EHR-EVALUATION.problem.v1 ...Then discussions regarding UUIDs, OIDs etc followed in several messages Is not the simplest thing to just use URIs [ http://en.wikipedia.org/wiki/Uniform_Resource_Identifier ], or even better allowing non-latin characters by using IRIs [ http://tools.ietf.org/html/rfc3987 ]? Then organizations can choose if they want to base IDs on domain-names, UUIDs, OIDs or whatever that fits in a URI (which might be a URN, see list at http://www.iana.org/assignments/urn-namespaces/ ). Some archetype authoring organizations may like names with semantics, some may not, so why enforce any of the views. Now since metadata is going to be well defined inside the file, the need for semantics in identifiers or file names is gone so the main thing left is that we want a _unique_ string. URIs are supposed to be unique. Some URI-examples: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 urn:oid:1.3.6.1.2.1.27 urn:lsid:chemacx.cambridgesoft.com:ACX:CAS967582:1 http://id.skl.se/openEHR/EHR-EVALUATION.problem.v1 http://schema.openehr.org/openEHR/EHR/EVALUATION/problem/v3 urn:nbn:se:liu:diva-38012 I see no point in enforcing usage of OIDs as suggested in some responses. The idea of not changing the ID if/when transferring responsibility of an archetype between authorities sounds very reasonable if the content is unchanged. When I visited Brazil, I noticed that the MLHIM project's development version was using UUIDs for the artifacts (CCDs) that correspond to what is called archetypes in openEHR. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/abd75895/attachment.html
openEHR artefact namespace identifiers
Hi! I like the Erik's idea of having a global and unique URI to reference each archetype (also for templates). This will help to build a global archetype server, and the domain of the URI can act as the namespace of the archetype. And, if those domains really exist (like openehr.org), an archetype URI can be equal to real working URL :D, so we can request any archetype directly from the server via HTTP requests. And it'll be great to build automated archetype tests to check the validity of an archetype against a version of the RM, as Thomas said. It'll be great to have this functionality integrated with the archetype editor. -- 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: Wed, 6 Apr 2011 23:11:42 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: openEHR artefact namespace identifiers On 05/04/2011 19:16, David Moner wrote: Hello, I like that approach regarding namespaces, it will be needed sooner than later. Related to archetype identifiers there is another problem still to be solved. How they deal with RM evolutions? Current openEHR RM release is 1.0.2 but it can change in the future. Nowhere at archetypes is said which RM version was used to define them. This information should go, at least, at the archetype header, but probably should also be represented at the archetype id. Otherwise we will not be able to differentiate between an archetype for one version of the RM and the same archetype (modified if it is the case) for a different one. It should go in the archetype, that is for sure - but it should be understood only as 'the RM version used when this archetype was authored / quality assured etc' - rather than 'the RM version for which this archetype is valid'. The reason is easy to understand: for some particular archetype, authored at RM 1.0.2 let's say, it may be valid for many RM revisions after that, even RM 2.x, and not only that, it might be perfectly valid for prior revisions e.g. 1.0, 1.0.1, even 0.95 - it can depend a lot on what parts of the RM the archetype happens to use. This is the reason I argued against including the RM version in the archetype id, because it doesn't tell us anything about validity. (We had a long discussion about this on the technical list last year or 2009 I forget which). Now.. if the RM changes, let's say to 2.0.0, then we might assume that there are one or two breaking changes, and that a few archetypes could break. The only way I can see to deal with this is: we stick with the rule that minor RM change numbers never break archetypes (or indeed existing data), i..e 1.0.1 - 1.0.2 - 1.0.3 etc is guaranteed safe we say that a major RM version change, i.e. 2.x, 3.x etc that includes breaking changes there has to be a validity test run on all archetypes. any that don't pass, i.e. are compromised by the change need to be marked in some way, maybe a header field with the meaning 'valid up to RM release xxx' or so. such archetypes would themselves then have to be versioned (.v1 = .v2) It should be remembered that we can undertake many innovations and 'fixes' that don't break anything on the RM, and therefore don't require a major release. So openEHR 2.x, 3.x etc are likely to be extremely rare events. - thomas David 2011/4/5 Ian McNicoll Ian.McNicoll at oceaninformatics.com Hi, About a year ago Thomas published a draft of some detailed artefact identification proposals at http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf to help with the rapidly approaching scenario of having to cope with similarly named artefacts being published by different authorities. We are starting to see this scenario emerging in real-world projects and whilst potential collisions can be managed informally for now, we will need a formal mechanism before long. I would like to raise one aspect which I think might need re-thought on the basis of recent IHTSDO proposal for SNOMED covering the same ground. In the pdf Thomas says When an archetype
new openEHR-based framework
Hi everyone! Attached are some screenshots of the new version of the OpenEHR-Gen Framework. In the previous email are some key changes from the previous version of the framework (I thought I send it to the list but I send it only to Ian). -- 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: pazospa...@hotmail.com To: ian.mcnicoll at oceaninformatics.com Subject: RE: new openEHR-based framework Date: Sun, 3 Apr 2011 16:11:57 -0300 Hi Ian, Some key points of this release: 1. We have upgraded to the last version of the underlying framework, now we use Grails 1.3.7. 2. Added: implementation of the Folder class. We use it to model clinical record domains, like emergency, ambulatory, prehospitalary, etc. 3. Improved: GUI generation, now the GUI is more compact. 4. Added: support to the type=smallText GUI directive for templates, that indicates to display a small text input for DvText nodes on the GUI generation (previously all the DvText nodes were displayed as a textarea/memo control). 5. Changed: now closing a clinical record is an explicit action. Before the records were closed when a patient was moved to another location. Now you can move a patient, but you have to close and sign the record explicitly. 6. Added: validation and error reporting of the occurrences constraint on ITEM_SINGLE nodes. This was not implemented before. 7. General code cleaning and small bugs were fixed. Hope that helps :D From: ian.mcnic...@oceaninformatics.com Date: Sun, 3 Apr 2011 19:57:32 +0100 Subject: Re: new openEHR-based framework To: openehr-technical at openehr.org CC: pazospablo at hotmail.com Congratulations Pablo, Would it be possible to get some headline points for this release? Ian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110405/a99c5a46/attachment.html
new openEHR-based framework
Hi Thomas, I've uploaded the screenshots here: http://www.subirfacil.com/files/1BIEYWYQ/capturas_openehr-gen.zip Thank you. -- 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, 5 Apr 2011 12:34:40 +0100 From: thomas.be...@oceaninformatics.com To: openehr-implementers at openehr.org Subject: Re: new openEHR-based framework Pablo, the list does not allow attachments, especially large ones, can you provide URLs to the screenshots instead? thanks - thomas On 05/04/2011 11:49, pablo pazos wrote: Hi everyone! Attached are some screenshots of the new version of the OpenEHR-Gen Framework. In the previous email are some key changes from the previous version of the framework (I thought I send it to the list but I send it only to Ian). From: pazospablo at hotmail.com To: ian.mcnicoll at oceaninformatics.com Subject: RE: new openEHR-based framework Date: Sun, 3 Apr 2011 16:11:57 -0300 Hi Ian, Some key points of this release: 1. We have upgraded to the last version of the underlying framework, now we use Grails 1.3.7. 2. Added: implementation of the Folder class. We use it to model clinical record domains, like emergency, ambulatory, prehospitalary, etc. 3. Improved: GUI generation, now the GUI is more compact. 4. Added: support to the type=smallText GUI directive for templates, that indicates to display a small text input for DvText nodes on the GUI generation (previously all the DvText nodes were displayed as a textarea/memo control). 5. Changed: now closing a clinical record is an explicit action. Before the records were closed when a patient was moved to another location. Now you can move a patient, but you have to close and sign the record explicitly. 6. Added: validation and error reporting of the occurrences constraint on ITEM_SINGLE nodes. This was not implemented before. 7. General code cleaning and small bugs were fixed. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110405/ab106cf5/attachment.html
new openEHR-based framework
Hi everyone! We are happy to announce the release of a improved version of the Open EHR-Gen Framework, available here: http://code.google.com/p/open-ehr-gen-framework/Now we're updating the docs for this new version. -- 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: Ian.McNicoll at oceaninformatics.com Date: Wed, 1 Dec 2010 15:21:22 + Subject: Re: new openEHR-based framework To: openehr-technical at openehr.org Thanks Pablo, I was dealing with some monster requirements documents which were perhaps atypical. Ian Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 15:06, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, it works without copying and pasting chunks. I just uploaded a doc, look for the Tools Translate Document on the menu, and here is the translated template sintax and config: https://docs.google.com/document/pub?id=17-vZ8OElOuWRLTsOXpzOJksW25lw0asQaSq1ZWDr7AU Warning: the automatic translation may break some of the sintax, I have to check it more carefuly. Here is the docs in spanish for gudance: http://code.google.com/p/open-ehr-gen-framework/downloads/list -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Wed, 1 Dec 2010 12:54:55 + Subject: Re: new openEHR-based framework To: openehr-technical at openehr.org Hi Thilo, Having done a load of Slovenian-English translations using Google Docs, I would suggest the following approach. 1. Split the original doc into reasonable size chunks - Google chokes above a certain limit and save as ? MS Word docs or equivalent 2. Upload to Google Docs and open the file 3. Ignore any offer from Google to 'translate this page' , if you have aotmatic trnslation turned on. 4. In Google Docs, Choose Tools-Translate from the top menu. 5. Create the translated doc as a copy and then download to your system. The translation quality is not too bad, although fairly amusing on occasion!! Most of the formatting is retained although Word numberings tend to get lost. Ian Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 12:42, Thilo Schuler thilo.schuler at gmail.com wrote: Hi Pablo thanks for your answers. Good tip with Google translation, hadn't thought of it... I have your app running on my machine now. I can see the login screen. The hardest bit was to convince my macbook to use jdk 1.6 :)... Otherwise a breeze. I like grails! Could you please tell me a login and password I can use to get into your great application. Thanks a lot -thilo On Tue, Nov 30, 2010 at 12:47 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Thilo, The current performance would make it cumbersome to use it in a productive environment, but it will be great as a prototyping and demonstrating tool. Clinicians can judge the value/completeness of archetypes and templates much better, if they see them as a working GUI. Your framework seems to be very suited for that. In fact I used the framework to show the archetype concept, something like archetypes in action. I will try to get a small template running locally on my computer sometime this week. I will report my experience back to the list. Maybe this helps to decide how the community can leverage your work. Great! let me know if you need some help. A couple of questions to start (Cave: Will possibly bug you with more questions in the process): - Does it matter what version of grails I use? Now it works only on Grails 1.1.1, you can read the installation page on the wiki: http://translate.google.com/translate?js=nprev=_thl=esie=UTF-8layout=2eotf=1sl=estl=enu=http%3A%2F%2Fcode.google.com%2Fp%2Fopen-ehr-gen-framework%2Fwiki%2FInstalacion You can use google traductor to translate the spanish pages and docs. - Can I use the in-memory DB HSQLDB for testing? Or should I set it up with MySQL. Yes, you can use HSQLDB, you can
Use Archetypes and ADL file in Java
Hi Alessandro, Think of ADL as a format for plain text files, an ADL file represent an instance of the AOM classes (that's why you have to parse ADL into AOM). For working with the RM, take the blood pressure observation archetype as an example. In our RM implementation (http://code.google.com/p/open-ehr-gen-framework/) you have an Observation class (http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/domain/hce/core/composition/content/entry/Observation.groovy) you have a data attribute of type History (http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/domain/hce/core/datastructure/history/History.groovy), History can have many Event (http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/domain/hce/core/datastructure/history/Event.groovy), and each Event. Event have a data attribute of type ItemStructure. ItemStructure is an abstract class, so only with the RM implementation, you don't know what is the structure and how to set this information, that information is in the instance of the blood pressure archetype, you can find it here: http://www.openehr.org/knowledge/ In this archetype, you'll see that the Event.data is defined as ItemTree, not as ItemStructure, and ItemTree is a concrete class of ItemStructure. The point here is: you have to process the AOM instance to know what is the concrete RM structure that represent your clinical concept, like blood pressure. Then, you create your RM instance and set data values the same way you create an instance of any object oriented model. Hope that helps. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 30 Mar 2011 02:09:04 -0700 From: padiglionestation at gmail.com To: openehr-technical at openehr.org Subject: RE: Use Archetypes and ADL file in Java Pablo Pazos Gutierrez wrote: Hi Alessandro, ADL defines the structure of your clinical data, In practice, ADL defines an instance of the archetype object model (AOM), that instance is the one you can handle from java. But the clinical data values must be set on the reference information model (RM). So, you must have: an implementation of the AOM, an ADLParser that parses ADL to an instance of AOM, and an implementation of the RM, and processing the AOM you can create an empty instance of the RM (empty because you have no clinical data yet). Here you can find a project (my degree thesis) that implements openEHR, and can generate any clinical record (is Java based): http://code.google.com/p/open-ehr-gen-framework/downloads/list -- 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, 29 Mar 2011 06:24:25 -0700 From: padiglionestation at gmail.com To: openehr-technical at openehr.org Subject: Use Archetypes and ADL file in Java Hi everybody I'm Alessandro OpenEhr is I'm working on for my thesis.For the moment I'm using java in the ADLParser file for the openEHR EHRS-. blood_pressure.-OBSERVATION v1.0 adl. I wanted to know, via java objects, how to handle this archetype in java and assign values, such as the systolic pressure. More generally, how can I access the OpenEhr archetypes in java? I attach the file that I have produced so far. Thank you for your attention, good job. Alessandro http://old.nabble.com/file/p31266646/Test_Archetype.java Test_Archetype.java -- View this message in context: http://old.nabble.com/Use-Archetypes-and-ADL-file-in-Java-tp31266646p31266646.html Sent from the openehr-technical mailing list archive at Nabble.com. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical Thanks for your reply and for the documents that I have passed.From what I understood ADL class represents an instance of AOM right?If you would like to know how I can map the archetype on an RM? Let me explain better: how ADL I openEHR-EHR-OBSERVATION. blood_pressure. v1. I like adl access its properties via the RM Observation? You can find some examples in this regard? I apologize but I am beginning with OpenEhr. -- View this message in context: http://old.nabble.com/Use-Archetypes-and-ADL-file-in-Java-tp31266646p31275301.html Sent from the openehr-technical mailing list archive at Nabble.com
