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... On Wed, Dec 1, 2010 at 14:29: > [The following from prof. David Ingram, UCL] ... > We have adopted a low profile, to avoid being drawn into the > multiple vortices afflicting the field. We have thereby retained > flexibility to focus on requirements and implementation issues, > making no pretence of democratic process. Has this changed and is there now real interest in figuring out what a more meritocratic or democratic formal openEHR organisation would look like? If so I'd suggest reading through http://www.apache.org/foundation/how-it-works.html thoroughly and reflect on it's content. Seriously, read that link before going on reading this long mail. That document captures many years of experience in a lot better way than my ramblings below. Also if you believe Apache is only about web servers, have a look at the nearly 150 projects and initiatives at http://projects.apache.org/indexes/quick.html and http://incubator.apache.org/ before going on. Sometimes the openEHR foundation to some has sounded like having a commercial startup company mentality saying: "We've been working very, very, hard (and late in the evenings) investing lots of resources in openEHR (even though we have jobs/departments/companies to run) and we now want somebody with good finances to either buy us out or help us scale up our venture to keep doing things pretty much the same way we have done so far (but at a larger scale)." I guess there is now a sense that openEHR is no longer in startup mode, but an uncertainty if there is any other option than a resource rich buy-out after the IHTSDO approach failed. Please understand that many comments (e.g. previously on the technical list) were not asking anybody to work harder, but rather asking the foundation work in a smarter, less individual dependent way, reducing risks and enabling distributed workload and decision making. Do take a close look at what the Apache foundation has figured out over the years. The suggestion is instead to reflect over things like "sharpening the saw" or?"we're too busy mopping the floor to shut the faucet.", see... http://c2.com/cgi/wiki?SharpenTheSaw http://www.codinghorror.com/blog/2009/03/sharpening-the-saw.html ...i.e. work smarter and allow distributed helpfulness, coordination and decision making - not only look for more money to keep doing things as usual, only more and faster (even though money would be helpful).?Getting stakeholders to invest working time might be both easier and more important than large monetary contributions if done in the right way. Do read about "agency costs" on page 6 in http://web.mit.edu/evhippel/www/books/DI/Chapter1.pdf Several Apache projects certainly get a lot of time investment from big stakeholders that at the same time are users. (IHTSDO is also depending on members contributing large amounts of non-IHTSDO-reimbursed working time in addition to fees.) When discussing future openEHR organisation with peers I know that some of them strongly disagree with me and rather than Apache-inspiration opt more for an IHTSDO-inspired organisation style based on commitment from tax-based national authorities and a high degree of synchronous physical or telephone meetings to get things done. So the Apache-style angle is my personal point of view, not necessarily my employer's or research group's view. I agree that an IHTSDO-like approach would be better than the present openEHR situation. The IHTSDO-style of organisation is easier to understand by national authorities then the Apache-style. If there is a strong sense that there is plenty of financial and national support just waiting to start an IHTSDO-styled organisation for openEHR, then it will probably work. If there is not any such support, then shifting over to something Apache-like delivering standard suggestions to other SDOs might work better. Many organisation styles do have some kind of member based highest decision making general-assembly function that I believe openEHR is lacking now. The difference is in how that assembly is elected e.g.: - pay the fee (IHTSDO, The EN13606 Association, HL7?) - anybody can join free (OHT) - be helpful, work, and get recommended (Apache) - be/start a nation (CEN, ISO) All have their pros and cons, and it comes down to what kind of thing(s) openEHR wants to be and how it will interact with other organisations. Perhaps different parts of the openEHR ecosystem needs different organisation types? Maybe an official openEHR archetype repository could be governed in a different way than RM-specification development? What tool development actually needs to be under the same umbrella as the specs or the archetypes? In Apache different projects organize themselves differently. For decisions that affect a nation one could reasonably argue that the elected bodies of a nation should have some influence over and responsibility for the process. So the specifications from an Apache style (meritocratic) organisation should not become national standards without passing a national or international SDO like CEN, ISO or IHTSDO. I believe one problem for Apache-style organisations in the health care area is if the nations (preferably the real problem owners, like organisations running health information systems) are not enough involved during development but only later during synchronous relatively fast SDO-negotiations where they twist and change the technical specs in untested manners. Developing specifications in an Apache style organisation without good national involvement and trust would thus not work very well, thus getting broad trust and involvement would be central to an Apache-styled organisation in this field. In IHTSDO the committees deciding on actual technical and clinical work are appointed by and pretty much trusted by the general assembly so things don't get twisted too much in the approval process. Also the mailing lists and meetings are open to anybody in the world who cares to join (presence, not voting). Below some things to reflect over when reading about Apache that could be useful for no matter what organisational style openEHR selects: 1. Making sure core assets (e.g. specifications, important tools and archetypes) are technically and legally "patchable" and that there are enough independent trusted people with rights and possibilities to apply patches to the (sub)project (called committers in the Apache document). A "patch" in a software meaning of the word is a file or set of files that?improves or corrects a file or document. Via tools the patch can be easily inspected and applied to the targets. This means that workload can be shifted over to people/organisations that have a desire to fix something that they consider important (or easy) to fix, provided that the community agrees by not putting in any veto and counter suggestions. This can be done even when "core developers" are busy tending to more urgent matters. A problem today in openEHR is that many small matters need to go through people that really need to focus on other things. In openEHR I'd say the Java implementation despite it's state has a lot of resemblance with Apache thinking. Patches are being exchanged and there are committers within at least three independent organisations. If the project leader, Rong Chen, would shift interests, change employer or just need a long break, the?Java implementation would probably slow down, but it can still be updated and kept alive.?OSHIP seems to have similar goals. The ADL Workbench and the (now old) LiU Archetype editor are examples of projects that have good licences, available source and are technically patchable, but where there is no wide developer community, so they would currently probably not go past incubation stage according to Apache community criteria. The community situation for the very nice LinkEHR editor might be similar - I don't know since I didn't see a public code repository there last time I looked. The archetype development within the CKM seems to have a good community. Perhaps someone else could say if there are people from at least three independent organisations that have commit/publish rights and what would happen to openEHR hosted archetype development if Ocean Informatics would go bankrupt e.g. because of getting sued by some angry American patient. :-) Archetype development could of course still go on using other community tools, so this is not a burning issue for the openEHR community. Discussion groups and a versioned file repository would do much of the work. Regarding archetypes, the more important issue is to switch license for openEHR-hosted archetypes to CC-BY, Apache 2, or something else without a contagious SA-clause, in order to gain trust from commercial actors wanting to base systems on openEHR-hosted archetypes. (See http://www.openehr.org/wiki/x/HACt ) Currently only Ocean Informatics and UCL can feel really safe putting such archetypes to use in closed source systems. My interpretation is that since the Ocean+UCL based foundation board trust themselves to always be nice to everybody, they will never see the practical trust problem for someone else betting their company/region/nation on the use of openEHR hosted archetypes. (That's a perspective a general assembly with broader base hopefully could change. Mailing list & wiki comments obviously have no impact.) If not changed, the likely impact is that an alternative global archetype forum with better licencing will surface and gain a lot more momentum than it would have otherwise. That would be a waste of efforts and would reduce interoperability. Another less important issue is that the CKM tool itself is not patchable due to license issues?etc?(yes we have understood the historic reasons) and if?Sebastian Garde or Ocean Informatics would lose interest in or lose resources for development it's unclear what happens. Thus it's important that the openEHR community in the long run either creates and shifts tooling, or keeps some really good public backups of everything that happens within the CKM, including archetype revisions and all discussions, so that experiences don't get lost. (That's why I've been speaking of complete logical DB backups rather than just a zip of the archetypes. Again, if you are on the inside of the organisation you might not see the trust problem.) Regarding the openEHR specifications I don't know if the entire Architecture Review Board has "committer" rights or if it's limited to less than three independent people/organisations. Technically?I believe the specifications are only practically patchable if one buys a licence for FrameMaker. Last time we discussed this, in the long thread named "Documentation Desperation" starting at http://www.openehr.org/mailarchives/openehr-technical/msg04592.html parts of the (friendly and understandable) responses were similar to "Too busy sawing by myself with my excellent personal hand saw to change to another sawing system allowing more workers, besides that, how do we know if anybody else would help?". Now when MLHIM has actually done the work of converting parts of the openEHR specifications (https://launchpad.net/mlhim-specs) then perhaps this issue could be reconsidered, possibly combined with changing license to a more well known CC-BY style. 2. Can the Apache way of decision making via slow discussions and consensus voting (http://www.apache.org/foundation/voting.html) via mailing lists, including veto mechanisms, be a way to avoid some of the problems with voting by a limited group of volunteer persons present in physical meetings (that have been described, e.g. by Tom, as a problem of some current SDOs)? 3. Would it be important to openEHR engagement that there was an outspoken path similar to the Apache path of: user -> developer -> committer -> voting member. Would that be interesting both for companies/organisations and individuals? (Consider the Apache claim "What is interesting to note is that the process scaled very well without creating friction, because unlike in other situations where power is a scarce and conservative resource, in the apache group newcomers were seen as volunteers that wanted to help, rather than people that wanted to steal a position.") 4. Would the Apache way of having personal rather than organisational project membership be useful in openEHR? (Apache financial sponsoring is mostly from organisations, but project membership stays with the person even when a person changes employer.) 5. Why do you think a company like Google submitted it's Google Wave research investment to Apache, see http://googlewavedev.blogspot.com/2010/12/introducing-apache-wave.html when they could have kept control over the project organisation themselves and still faithfully be called an open source project? I hope that those points above are somewhat helpful when considering the future of openEHR. One last thing: In the board announcement it said "We would like to invite initial discussions on organising this meeting on the openEHR lists, which Sam Heard will moderate." - It might be helpful if you let somebody not being CEO of a very openEHR-intertwined business moderate discussions, at least _during_ that meeting. Tony together with somebody from the technical ARB might do that well. That way it would be easier for Sam and others to separate foundation perspectives and business perspectives and he would be free to speak as a CEO not having to balance this with moderator neutrality. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 P.s. If going for an Apache-style meritocracy, for parts of or for the entire openEHR foundation, then one of several options for creating the first general assembly needed for bootstrapping could be to take the union of the Architecture and Clinical Review Boards complemented with some national openEHR-savvy representatives from presently underrepresented but interested countries. I guess such a decision is presently completely in the hands of the current openEHR foundation board. That assembly could then discuss how to broaden it's base in an open but controlled manner. > -------- Original Message -------- > Subject: ? ? ? ?[openEHR-announce] Announcement concerning progress with > IHTSDO and future directions > Date: ? Tue, 21 Dec 2010 16:26:21 +0000 > From: ? Thomas Beale <thomas.beale at oceaninformatics.com> > To: ? ? openehr-announce <openehr-announce at openehr.org> > > > At its October meeting in Toronto, the General Assembly of the IHTSDO > received and discussed a proposal, submitted by its Management Board, to > support, develop and maintain the IP in openEHR, within a broader > framework of IHTSDO governance for clinical content of the electronic > health record. > > *IHTSDO Decision* > > The openEHR Foundation Board has now heard from the IHTSDO Management > Board, saying that, whilst the objective of the proposal was considered > by the GA to be within the scope of the organisation and that it > represented a pressing issue for their governments, it was unable to > reach consensus that going forward with openEHR in this way is the > right choice, at this time. > > It confirmed its wish to continue a pathway of harmonisation with > openEHR and expressed considerable appreciation for the work done in > setting out the proposal, by the working group of Foundation and IHTSDO > members. The pathway forward that they have chosen is the creation of an > IHTSDO Task Force, to review the requirements for clinical content > standardisation, afresh, and then proceed towards an open process for > meeting those requirements, in which openEHR would be invited to > participate. > > This is disappointing from our perspective as we believed that the > IHTSDO was a good organisation with which to partner, to provide the > broader governance for developing and maintaining the openEHR > specifications and related tooling that we have been seeking. We have > been encouraged, in successive stages over two years, to actively engage > in this dialogue to seek greater harmonisation between eHealth standards > bodies. It is a time of financial hardship and the openEHR Foundation > did seek a significant injection of funds into the specifications and > tooling: this may have been a contributing factor in the decision. It > was critical to the Board that this move did involve an injection of > capital. > > We much appreciate our close working links with many staff and members > of IHTSDO, formed in the process of working with them to generate the > proposal that has not, sadly, found favour at this time. A number have > been long-standing and loyal advocates for what we are trying to > achieve. These will, we hope, be maintained in the future, despite our > pressing need to move forward independently. Despite the apparently > negative outcome at this stage, we are minded to now look at the > opportunities that are on offer to take the specifications forward. > > > *The Future* > The Foundation now needs to find a smarter way forward which continues > to build the momentum behind openEHR and develops opportunities for > members individually and collectively. We believe there is no doubt that > the momentum for enabling eHealth platforms such as openEHR > is growing: more people are realising the importance of a standard, > tool-based approach to content definition and the distributed electronic > health record. The health record is becoming an important asset for each > citizen, for every provider and for the good of society. > > The Foundation?s view is that standardisation of a knowledge-enabled EHR > computing platform is a critically important step to support > international efforts of healthcare reform; a step that will lead to > genuine diversity of applications, empowerment of individuals and > beneficial health outcomes. Health systems are under pressure, and a > properly engineered, cost-effective and flexible platform is necessary. > > The Foundation wishes to acknowledge that the future success of > openEHR now clearly lies in the hands of the openEHR community > itself. The Foundation is therefore seeking support for an international > meeting to define and establish a new way of working. The meeting will > discuss ideas about how to progress the work of openEHR and ensure that > more people benefit from it. We would like to invite initial discussions > on organising this meeting on the openEHR lists, which Sam Heard will > moderate. > > We sense there are a number of central requirements for moving forward > and wish to seek the community?s opinion on next steps. These include: > > ? 1. The potential for a new Consortium that owns and provides suitable > ? ? ?governance for the oversight, IP and other assets of the > ? ? ?Foundation ? this might comprise professional organisations, > ? ? ?universities and industry; > ? 2. Resources to ensure that information about openEHR continues to > ? ? ?grow, specifications are maintained and the business of creating a > ? ? ?standard health record platform that works continues; > ? 3. A collaborative ?refresh? and focussing of the aims and ambitions > ? ? ?of the openEHR community; > ? 4. Practical engagement with clinical groups, through the Foundation > ? ? ?and all its participants to ensure that the improvements sought by > ? ? ?health services are supported by openEHR efforts; > ? 5. Maintenance of a lean and agile engineering approach that avoids > ? ? ?expending time and effort without practical and incremental gain > ? ? ?for the community; > ? 6. Alignment of the efforts of academia and industry around > ? ? ?production of open source software tooling to support greater > ? ? ?international collaboration and increased uptake of openEHR; and > ? 7. A roadmap to ensure that open/EHR becomes a universal EHR ? the > ? ? ?record that can accept information from all current systems and > ? ? ?can be implemented using the latest technological approaches. > > Thank you for your patience during this extended period of uncertainty. > We apologise for any difficulties and tensions this has created. We all > have choices and we appreciate you may choose you to invest your energy > and effort elsewhere. Rather, we hope that the aspirations and energy > this community shares will drive us all forward to support and deliver > the paradigm shift that is required in eHealth. We appreciate your > support at this time. > > December 2010 > David Ingram, Sam Heard and Dipak Kalra for the openEHR Foundation >
