Hi Thomas, I read your email and I would like to comment on the three main topics you touched. First I believe that people in openEHR project have contributed a lot in all three areas of health informatics as you mentioned in your email and congratulations to all for leading innovative work. Nevertheless in my opinion what makes openEHR to excel in the domain of health informatics and where I certainly place my bet for the future is the design of archetypes and especially templates. This is THE bridge between health professionals and software developers. You can find tons of specifications from all the organizations you referred to and you can also find a lot of open source software tools and applications in the health domain but the simplicity of archetypes and templates and the tools to design them is unique in your project. Nevertheless the last two years I have been pondering a lot on the state of the art regarding the design of graphical user interfaces, the design of the data model and the trend to support distributed systems with web services. This is certainly not the place to get into great depth about the technical details on all these but I am more than happy to present you my research plan and perhaps you can provide me with answers or directions on the OPEN design principles that you followed in your project in order to cope with the following issues:
1. Data model (I am referring to your UML RM model) - Archetypes and templates a. What database model are you using for the permanent storage of your entities, is that implemented on a popular DBMS, is it open ? b.How do you connect the database model with the programming data model and your ADL structures, what kind of OR mapping are you using c. Why are you using ADL and not standard XML-XSD to describe your archetypes, templates ? d. Have you explored the path on how your knowledge representation is linked to popular W3 technologies such as ontology, linked data, RDFs, especially the application of these on media information management ? 2. Design of user interfaces, how is openEHR linked to the following a. What principle you follow when you bind your data to the GUI component ? b.Is there a particular model you are following on the design of applications (e.g. MVC ?) c. Have you considered to support popular document formats such as Office Open XML and Open Document Format ? d. How easy is it for a developer to embody openEHR technology with popular frameworks (Adobe Flex, Microsoft .NET) ? 4. Distributed systems and services a. Considering the major acceptance of the standard clinical documents (CCR, CDA) in the health domain and the impact they have on the interchange of data information, how do you match or implement those in openEHR ? b.Is there an open demo of a complete prototype that one can explore to see openEHR in action (common scenario includes a clinic with doctors and patients where the user can explore health records for each one of them as well as services provided by the system) ? I am sure that you have explored all these but I think it makes sense to see how exactly openEHR is going to fit with the big trends of information technology (i.e. databases, user interface modeling, web services - semantic web). Best luck with your efforts Athanassios Hatzis http://medilig.org http://athanassios.gr PS: I do not read the technical list of openEHR as I do not have the time to get into great depth of details for openEHR implementation. But I am very keen on the architecture design principles and plans you have for the future. From: openehr-clinical-boun...@openehr.org [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Wednesday, February 02, 2011 10:05 PM To: openehr-clinical at openehr.org Cc: Openehr-Technical Subject: Re: openEHR future directions This just reminded me to put a few points down as well before I forget them. I think openEHR is doing 3 different things, which make it hard to understand for some organisations: * a standards function: developing, publishing and maintaining specifications * a knowledge engineering function: facilitating the building of archetypes, via a community of clinical and health informatics professionals * NB: similarly to IHTSDO / SNOMED CT, this could be looked on as a kind of standards function, since the idea is to get everyone to use the archetypes * an (open source) software development function: building OS tools, components, systems that implement the specifications and consumer the archetypes The first function has historically been performed by Standards Development Orgs (SDOs) like CEN, HL7, ASTM, ISO etc; the second by WHO, WONCA, and now IHTSDO; the third has historically been done by all kinds of groups and companies. In Health, some SDOs, notably IHTSDO, and HL7 realised they needed tools to make their standards work, so they have built some software as well. It may be that the 3 functions of openEHR need to be more separated - into distinct orgs? Or perhaps into better delineated (and separately governed?) part of openEHR? On the general future direction: I think meritocracy is a fine concept. However, democracy / consensus on design is not - it doesn't work. My contention is that there is no escape from the analysis and design functions of software engineering, and these are necessarily limited to 1 or 2 people at a time. Fred Brooks has written a whole book <http://www.amazon.co.uk/Design-Essays-Computer-Scientist/dp/0201362988/ref= sr_1_1?ie=UTF8&qid=1296663690&sr=8-1> on this, on which I commented in my blog <http://wolandscat.net/2010/12/19/design-in-ehealth/> . The real question is not one of meritocracy, it is of how to practically design and build specifications and software, in a world where the individuals are all over the place. You can vote on what priorities should be, and you can vote on a design that someone has produced, but you can't produce the design by voting. You can produce very poor specifications by voting, aka 'design by committee', and the results in e-health are there for all to see. We should not go that way. I don't think this is very hard to achieve: a few face-to-face meetings of relevant project groups would do it, and help people to get to know each other as well. Nevertheless, as long as a sensible approach to engineering and maintaining things is adopted, I do think a more Apache-like community would be good, at least for the software part of openEHR - i.e. let's just get moving and build some nice software. However - doing so means maintaining and continuing to develop the standards that everyone agrees to, and this is where we need some governance. Currently the standards in e-health are in a desperate mess, and the customers (governments and vendors) do not seem to know what to do. In my mind, there is no escaping the need for a new kind of organisation to create 'standards' in e-health - an org that runs on a largely open source community and tools mentality, which however does not fall for the design by committee trap. More on this in my blog <http://wolandscat.net/2009/10/18/the-crisis-in-e-health-standards-iii-solut ions/> . Another observation: I had some involvement of the open source health software community over the last 10 years, and although some nice tools have been built, they don't interoperate. Open source doesn't help interoperability generally - that takes a further, special effort. Secondly, because health IT is so specific, the ability to attract distant developers to a new tool is very low - too much context and specific knowledge is generally required. Maybe this could change with better communications, but with the sector so fragmented, I think it will still be a challenge. I think the main issue with openEHR is that if it has value, then those who get the value need to put some resources toward it. I think it has achieved quite a lot so far: * a pretty decent health information reference model, including data types, EHR, EHR Extract, and demographics * a pretty clean formalism for expressing content models: Archetype Definition Language and Object Model * a formalism for portable querying based on the archetype formalism (AQL, a-path) * a growing library of archetypes * tools which which are not far off enabling full cycle development, i.e. archetype development => templates => operational template => downstream conversions, including message schemas, code APIs, document schemas etc * emerging service models A lot has been learned from implementation over the last couple of years, and the Jira trackers show a number of small but important change requests waiting to be done. These represent real maturity: such change requests are things that nobody could have guessed at the outset. So openEHR today provides a practical platform for health computing both on the tooling side and the EHR systems and messaging side. If this is seen as valuable, or can be turned into practical value, then the only problem is one of organising the community to support the ongoing work. Solving the three-headed Hydra problem may be the start. - thomas beale On 02/02/2011 15:30, Erik Sundvall wrote: On Tue, Dec 21, 2010 at 17:44, Tony Shannon <mailto:tony.shannon at nhs.net> <tony.shannon at nhs.net> wrote: Please see the announcement below for your attention. Your views on the future direction of openEHR are especially important at this time. Please feedback any/all views to this list to generate the discussion we need. Hi Tony! Thanks for inviting comments in an open way. Organisational issues have been touched upon earlier (see previous discussions on the technical list). I believe some of us would like to know what will happen to the feedback this time. Some previous discussion responses (and partly an interest in implementation rather than organisation) have made me keep a version of this message in draft for several weeks instead of finishing and sending it. My hope is that this message helps more than it hurts. Previously parts of a board announcement said... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110317/e10a94dd/attachment.html>
