Hi Pablo, Your project is very interesting and I think needs more discussion, outside the context of this thread on the ISO datatypes. Perhaps you should re-post it on a new thread or on the 'openEHR adoption' thread, as it might give some useful pointers as to how we can best share from and support open source projects like yours and Koray's. There are also some interesting discussion to be had about how to share the archetype you have developed, or at least feed your ideas into broader developments.
Would you mind re-posting in a different/new thread? 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 22 November 2010 17:29, pablo pazos <pazospablo at hotmail.com> wrote: > 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 > > > > ________________________________ > From: k.atalag at auckland.ac.nz > To: openehr-technical at openehr.org > Date: Mon, 22 Nov 2010 00:35:08 +1300 > Subject: RE: More on ISO 21090 complexity > > Hi All, what a discussion J > > > > Just a few points: we have developed an endoscopy reporting application > based on a very comprehensive domain model (some of you already know ? I am > obsessed with this model!) using openEHR specifications. There were many > obstacles ? including data types (for example a quantity data type with two > alternate units of which one was not in the list of selectable units defined > in a small terminology) but a solution could always be found. I can say that > it has worked for us and in a few weeks time we will release the code as > open source. There was a mention of GUI with data types; indeed I must say > that they almost always dictate the type of widget on screen ? that?s our > experience. Rest of the GUI definition comes from what we call ?GUI > ?Directives? inserted into Templates as annotations. I suggest that we > define a specific entry for GUI for each node at template level. > > > > There relevance of this message to this thread is that, I have repeated this > argument several times before, I suggest working on some concrete examples > when discussing about pros and cons of different standards. So I?d be very > interested to see some examples (caution not to use ?use case? here ;) where > one standard data type works and the other doesn?t and vice versa. Perhaps a > wiki page where the ordinary readers like me could understand fully and > appreciate the many arguments thrown so far. It?s a pity that we are using > so little of the available e-collaboration tools effectively while calling > ourselves as (health) informaticians ;) > > > > I personally think we, health informaticians, make life a lot more > complicated than it should be. I am pretty confident that the solution of >>90% of problems is a no brainer and that we need more of it for the > remaining. My gut feeling is that the chances of getting something working > out there are higher if we start with simple and generic data types. Based > on the needs during ?real-world? implementations (not well thought use > cases) I think they can evolve ?incrementally?. I must admit that I may just > be too simplistic here but this is my approach to solve problems. > > > > There were also a few mentions about ?maintainability? and ?software > quality?. Well I know a little bit about this (indeed my research is all > about this topic!). Maintainability, according to the well accepted ISO/IEC > 9216 and 25000 series standards quality model, is a quality characteristic ? > a very important one because it has a dramatic effect on software cost. The > rule of thumb is to avoid complexity ? in code, design artefacts, process > etc. The preliminary results of our research shows that it takes seven times > less time to implement changes and the complexity is nine times less in the > openEHR based application compared to a ?typical? > object-procedural/relational DB application. One next research question now > in my mind is to build a third application using HL7 based on exactly the > same requirements. I?d be very keen to collaborate if you find the idea > interesting and worth investigating. I guess this should then be the > ?Evidence based health informatics? ?? > > > > Cheers, > > > > -koray > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
