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: [email protected]
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101122/2e834d87/attachment.html>
