Hi Pablo Wow, I am soooo impressed! Your project artfully - in a way I couldn't ever have done it, after all I am a MD and poor programmer - combines three of my (past) projects and interests:
- With one other person I programmed a PHP framework that generates clinical forms based on a proprietary (no archetyypes) form definition language (http://www.ncbi.nlm.nih.gov/pubmed/17911755) - I have had a look at Grails a while ago and liked it for its clean implementation of the MVC pattern and the conciseness of groovy without loosing the possibility to whatever Java offers (any java code can be used). I created a simple application (gift registry for my own wedding), but would have never dreamed of being able to implement the whole RM with groovy. - I have been involved in archetyping for several years 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. 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. I think we should discuss how we can get the maximum leverage out of this great work and to make it accessible to as many interested as possible: e.g. translation, tutorials (setup etc), background info, online demonstrator,... Thank you Pablo for sharing this! Cheers, Thilo 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 system > - ArchetypeManager 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 technology > - Grails framework to build our Opeh EHR-Gen Framework with > MVC+Services, and a great ORM for persistence > - it 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 <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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101129/60bc63e0/attachment.html>
