Hy! There is a lot of wisdom in these observations. The 3-headed hydra feels like a realistic description of the challenges.
Greetings from Vienna, Stefan Sauermann Acting Program Director Biomedical Engineering Sciences (Master) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: +43 1 333 40 77 - 988 M: +43 664 6192555 E: stefan.sauermann at technikum-wien.at I: www.technikum-wien.at/mbe I: www.healthy-interoperability.at Thomas Beale schrieb: > > 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 > o 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-solutions/>. > > 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 <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... >> >> > > * > * > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
