Hi Thilo, Thanks for your words.
We have some things in common. I have a small project called miniClin, in wich I defined CDA templates based in the CDA structure, and ideas borrowed from openEHR archetypes (like node codes, paths and node occurrences). I've developed a small proof of concept PHP/MySQL app that worked fine (with limitations), and I use the Yupp PHP Framework to build this app (Yupp is an MVC/ORM framework with some ideas borrowed from Grails framework, I developed). Now miniClin is just a paper (sorry, spanish only). In miniClin, the GUI is generated from these CDA templates, the data binder create CDA documents in memory from the template and the data, and a seralizer create the CDA XML file on disk from the memory structure (this project has a lot in common with the EHR-Gen Framework). Some links: http://code.google.com/p/miniclin/downloads/listhttp://code.google.com/p/yupp/ Did I understand correctly that you have domain classes for most RM classes that get persisted via Grails ORM mechanism? Thus, it uses a generic stable schema (as long as the RM does not change) and binds the generated RM structure that is created in memory from templates/archetypes/user input to it. This design is opposed to persisting the variable generated RM structures directly via ORM. Yes, we implement the openEHR RM classes as Grails persistent classes. You can find them here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/grails-app/domain/hce/core Yes, the DB schema is autogenerated from the domain model classes, so the schema is very generic and doesn't change if you add new archetypes or templates to your app. This generic approach obviously has a side effect on performace, but is also a boost on development time. I think this could become a big step for the openEHR community. This will make it possible to author a template/archetypes and create an small clinical application from it relatively quickly. Our big goal is to build a tools chain, so anyone can define some archetypes, add them in a template, deploy the archetypes and templates into the Open EHR-Gen Framework, and you will have a complete application for clinical recording. Over this application, anyone can build their own plugins, so you can add integration with other systems, conversion to/from other information models, etc. I didn't say this before, but this project could never be done without the re-use of Rong's work. The base of all are the AOM implementaion and the ADL-parser from the java-ref-impl. You can see what libs we reuse here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/lib Thank you Pablo for sharing this! Cheers, Thilo Thank you Thilo. Keep in touch, Pablo. On Mon, Nov 29, 2010 at 7:51 AM, pablo pazos <pazospablo at hot mail.com> wrote: Hi, I think I must add some context to this email. Architecture: http://www.slideshare.net/pablitox/open-ehrgen-un-framework-para-crear-historias-clnicas-electrnicas, page 18 GuiGen:is a GUI generator based on archetypes, our own XML templates (with GUI directives), i18n config files, and RM structures.the GUI is all HTML (the framework is for building web ehr apps) the GUI is generated in real time (we also thought an offline generation of static GUI can be better to reach good performance, but the real time generation could help on testing things more quickly).the GuiGen can handle structured data and multiple occurrences of archetype nodes. here are some screenshots: https://docs.google.com/leaf?id=0B27lX-sxkymfYzI5YzBjMWEtZGI5My00NGNiLThmNmQtOGNhZmE0ZWEwNDll&hl=en here you can find the templates: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/templates/hce/trauma and the referenced archetypes: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/archetypes/ehr Data Binder:this component creates RM structures from plain data from user's input, archetypes, templates and terminology.in the process of creating the structures, it also validates data against archetypes constraints. it creates structured data from plain data, and create multiple instances for archetype nodes with multiple occurrences.it doesn't handle the whole datatype package, but it supports the more common datatypes like text, coded text, quantities, count, ordinal, dates, boolean, and a few more. all the binding and validation is done on the fly.CKM integration:we have our local CKM in file systemArchetypeManager and TemplateManager load archetypes and templates on demand, and cache them on memory. RM:we implement our groovy based openEHR RM in order to get automatic persistence capabilities from Grails framework.CDR:our clinical data repository is just a MySQL dbms, with an autogeneratd schema from the groovy RM with Grails framework Technology: http://www.slideshare.net/pablitox/open-ehrgen-un-framework-para-crear-historias-clnicas-electrnicas, page 21 Java technologyGrails framework to build our Opeh EHR-Gen Framework with MVC+Services, and a great ORM for persistenceit uses the Groovy PL (is a dynamic, java-based, PL) We want to add some features, like plugin support in order to add functionality to the apps created with the framework, like PIX-PDQ integration, DICOM query-retrieve integration (we have developed some hardcoded integration with both), etc. I hope this can serve to better understanding of our project. -- 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, 24 Nov 2010 16:28:04 +0100 > Subject: Re: new openEHR-based framework > From: rong.acode at gmail.com > To: openehr-technical at openehr.org > > Hi Pablo, > > I was about to ask you to make a proper announcement on the list. Ian > beat me on this ;-) > > Thanks for the excellent work and commitment to the open source > community!! I will send you some specific questions later on. > > Cheers, > Rong > > On 24 November 2010 16:20, pablo pazos <pazospablo at hotmail.com> wrote: > > Hi, > > > > > > I have send this same email to the last 21090 discussion, and Ian ask me if > > I can send it again in another thread, here it is. > > Just yto give some context, this was written in response to Koray who asks > > for real-world implementations, and who is studying the complexity/time of > > building openEHR-based systems. > > > > I should clarify that the framework is the core of the system, but not the > > whole system. The whole trauma application has also DICOM integration, > > external MPI integration via IHE PDQ, the "generate CDA feature" (we leave > > this on the framework too, but is not a part of the core), and the > > calculation of quality of care indicators. > > > > Ian ask me if I can publish the archetypes we use, archetypes, (our own) > > templates, the code, etc, are all here: > > http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen > > > > > > Cheers, > > Pablo. > > > > -------------------- > > Hi Koray, > > > > As an example of a "real-world implementation", we have build an EHR for > > trauma care. Our project was developed in one year and four months. > > The core of the development is an openEHR-based framework, wich takes > > archetypes and our own templates (with GUI directives), and generate GUI, > > data binding with RM structures, validation of data against archetypes > > contraints, and persistence of the RM structures. BTW, this framework has > > been open sourced: http://code.google.com/p/open-ehr-gen-framework/ (sorry > > docs in spanish only). > > > > I've estimated that this particular project without the "openEHR overhead" > > could be finished in 6 months. > > But if I have other project like this today (same size, same complexity, > > etc), I think we can finish the development en 3 months, using our > > openEHR-based framework. > > > > So, if we have 10 projects this are the numbers: > > > > * Without openEHR tools: total of 160 months (13.3 years) > > * With openEHR tools: total of 56 months (16 months for the first > > development, 4 months for the rest 9 projects, that's 4,7 years!!!) > > > > > > If we can improve the tools, these times could be improved, and the final > > solutions have the advantage of separating the knowledge from the software, > > and we can share and reuse archetypes between diferent projects, that's just > > great! :D > > > > Hope this experience can help you. > > ------------- > > > > > > -- > > 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 > > > > > > _______________________________________________ > > 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 -- Thilo Schuler +61 406 113 740 _______________________________________________ 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/20101128/62012aee/attachment.html>
