Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc

Technical (archive)
61

Thanks for a very timely and provocative debate.

I think the original question came from Dereks reply to my earlier blog posting.
The reasons for slow adoption have been discussed here already and recent discussions on the technical lists highlight the challenges in aligning the health IT standards community in any one direction.

My own perspectives on the challenges include;
Complexity.. we are dealing with a very complex system in healthcare. This is an ecosystem not a machine so none of us has complete control or understanding of the space.
http://frectal.com/book/chaos-complex-complicated-simple-and-cynefin/
Change requires;
-People..people have different backgrounds, agendas, goals etc in this field. They can really struggle for a common language at times (eg datatypes dare i say!). Its easy to say the other guy doesn't quite understand my world. Rather we all need to make an effort to the whole that makes life that little bit easier for everyone else.
Politics is the tricky "process by which groups of people make collective decisions". It seems clear that there are too many SDOs/standards bodies in eHealth with overlapping but unaligned efforts. We need to address that. As Tom mentions the openEHR is in discussion with IHTSDO toward that end. I have invited comments/thoughts on that in recent months..
-Process.. again many folk work differently so joining efforts up is a challenge (again back to joint working needed + more on process anon, w.r.t. progressive developments in Sweden..)
-IT- I agree with many others that we particularly need better tools, shared tools, particularly those that help join the clinical frontline with the international health IT standards space.
(See this story as to where my own efforts in the NHS got stuck..)
http://frectal.com/book/healthcare-change-the-way-forward/healthcare-change-why-“open-source”-is-part-of-the-recipe/
As has been highlighted we need a means to resource that tooling development, which the health community can both contribute to and benefit from.
-Value.. we need to aim to offer value right at the clinical frontline.. that must prove their utility in the wild as Olusegun put it.

As indicated, we await progress on a funding an approach to tackling these key challenges with IHTSDO.... meanwhile please keep up the provocative debate.

Regards,

Tony

Dr Tony Shannon
Consultant in Emergency Medicine, Leeds Teaching Hospitals
Clinical Lead for Informatics, Leeds Teaching Hospitals
Chair, Clinical Review Board, openEHR Foundation
tony.shannon@nhs.net
+44.789.988.5068

62

Hi!

there are zero paid openEHR people, full-time or part-time.

That is not such a useful way of looking at openEHR funding. There are
a lot of people working with openEHR on paid time during working
hours. They are just not funded by the openEHR foundation. This
situation is the same for many open source projects etc.

If you define "openEHR people" as people funded by the foundation you
are automatically excluding most of the community from being "openEHR
people". That might not be the smartest thing to do.

Too often I hear "openEHR needs funding" with the accompanying thought
that the foundation itself needs a lot of money. Yes the foundation
might need a little money for server & maintenance costs (if we don't
want to use "free" services) and for trademark registrations etc. But
the real need is working hours, not money.

Certain organisational behaviours make people and companies donate
working time, while other behaviours do the opposite. Some behaviours
get the time donations ending up within the original project, other
behaviours result in related projects more using and indirectly
contributing to the project via related but organisationally
independent projects.

Many other volunteer organisations understand this difference better
than what the openEHR foundation seems to do, at least judging from
the few signals one can receive from the not-so-community-present
foundation board that has nobody to formally answer to but themselves.
In a volunteer project it can be quite OK with natural self appointed
leaders, often the founders, but it then has to be matched with other
attitudes or safeguards such as...
- being very good at communicating and willing to actively explain and
discuss decisions
- the ability for any participant to branch of and take (a copy) of
invested time (work) with them, if the leadership becomes poor
...and so on.

The people who
currently put some effort into openEHR, such as myself, are working on
exactly the same basis as anyone else in the community. We are just crazy
enough to spend more time on it;-)

There are a lot of completely sane reasons for investing time in
openEHR. I for example believe Ocean Informatics would not at all have
been getting assignments all around the globe if it had not chosen to
invest time in open specifications. Very few would have heard of that
little Australian company. (On the other hand, it could probably have
been an even bigger company if everybody, not just a few, within that
company understood open source business models better.)

To get back to the real issue of "slow" openEHR adoption, I believe
Seref is closest to the problem: a system trying to do everything
openEHR tries to in a well engineered way, really becomes an
"elephant".

It takes time to properly implement an elephant from scratch,
especially including all supporting systems.

The two organisations that could have provided a real working open
implementation of that elephant first would probably have been UCL and
Ocean Informatics. Now, instead of joining forces on that, they have
both been running their own competing commercial closed source
implementation projects (OK UCLs were probably more 13606 than
openEHR, but you get the point). They are of course both fully
entitled to do so, and it's great that the specifications themselves
are open, but I believe it has delayed the arrival of an open
demonstrator platform that people can use to try openEHR ideas on and
are willing to invest time in. On the other hand it has left the field
completely open for both competing commercial and open source efforts,
which in the long run, after this delay, might show to be beneficial
for the world at large (but probably less beneficial for Ocean and UCL
than it could have been). UCL by the help of Seref and whoever
supports him, now seem to be getting the point of an open
demonstrator, so things seem to be changing there.

One should not deny that there might be a similar competition between
open source efforts, but I believe cross-pollination of ideas between
such projects can be pretty fruitful and efficient (look at Archetype
editors for example), and thus less effort might be wasted than in
commercial competition. (To add to the open source confusion some of
us are thinking of alternative ways (http REST) to slice the elephant
implementation and let smaller parts cooperate (or compete if you
wish) in implementations - but that should be a separate post later.)

I hope this mail did not sound too complaining, I more aimed at
explaining (from my particular point of view). I like both UCL- and
Ocean-people, that's one reason to try and be honest with them. :slight_smile:

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

63

Hi Erik,

Hi!

there are zero paid openEHR people, full-time or part-time.

That is not such a useful way of looking at openEHR funding. There are
a lot of people working with openEHR on paid time during working
hours. They are just not funded by the openEHR foundation. This
situation is the same for many open source projects etc.

Also, there are a lot of people working with openEHR with no payment at all, and the difficulties of having to study the specs, and little tooling and open projects that are not updated with some frequency. That was the whole point of the discution.

There were a lot of people that start working with openEHR, but the cost of understand the specifications, trying software (incomplete or not updated), and the complexity of building something based on openEHR that realy works, just discourages people. And we need to do something to change this reality (if we want openEHR be widely adopted).

If you define “openEHR people” as people funded by the foundation you
are automatically excluding most of the community from being “openEHR
people”. That might not be the smartest thing to do.

Is just people (like us) that works with openEHR.

Too often I hear “openEHR needs funding” with the accompanying thought
that the foundation itself needs a lot of money. Yes the foundation
might need a little money for server & maintenance costs (if we don’t
want to use “free” services) and for trademark registrations etc. But
the real need is working hours, not money.

We need people that update the tools and software projects with some regularity. Yes, it’s working hours, that must be payed some way… not everyone works on a university that pays people to investigate on openEHR.

Certain organisational behaviours make people and companies donate
working time, while other behaviours do the opposite. Some behaviours
get the time donations ending up within the original project, other
behaviours result in related projects more using and indirectly
contributing to the project via related but organisationally
independent projects.

Not every organization can do this. The reality in here in South America is very diferent to the one you mention. There are things that simply cannot be made without funding, in the other hand, we can’t wait to see when openEHR is got to be widely adopted, so I start this discution to see: 1. where are we going? 2. is it worth to invest my free time in this standard or I have to look elsewhere?

Many other volunteer organisations understand this difference better
than what the openEHR foundation seems to do, at least judging from
the few signals one can receive from the not-so-community-present
foundation board that has nobody to formally answer to but themselves.
In a volunteer project it can be quite OK with natural self appointed
leaders, often the founders, but it then has to be matched with other
attitudes or safeguards such as…

  • being very good at communicating and willing to actively explain and
    discuss decisions
  • the ability for any participant to branch of and take (a copy) of
    invested time (work) with them, if the leadership becomes poor
    …and so on.

I agree.

The people who
currently put some effort into openEHR, such as myself, are working on
exactly the same basis as anyone else in the community. We are just crazy
enough to spend more time on it;-)

There are a lot of completely sane reasons for investing time in
openEHR. I for example believe Ocean Informatics would not at all have
been getting assignments all around the globe if it had not chosen to
invest time in open specifications. Very few would have heard of that
little Australian company. (On the other hand, it could probably have
been an even bigger company if everybody, not just a few, within that
company understood open source business models better.)

Not everyone that is investing free time on openER works in a company that can made some kind of profit.

64

Erik,

a few points informally (I am not on any boards of any organisations, so these are my own thoughts):

  • any organisation like openEHR needs some core paid people to execute key functions, and to maintain continuity. There is an ‘officers’ level, which runs any organisations, including admin and other support staff, and there is an operational level.

  • for the operational level, there are typically posts like CTO, CMO, infrastructure management, project coordination, and so on. If the organisation is to do properly what its members want - typically 2 things: a) manage specifications/standards, including member involvement in this, and b) manage open source projects, potentially largely staffed by volunteers - then it has to have a few dedicated posts. Otherwise it becomes no-one’s responsibility to actually coordinate things, keep infrastructure running etc.

  • currently openEHR Foundation pays no-one. Therefore, all attempts at the above work are performed by people on the payrolls of other organisations, each having their own raison d’être and agenda. Compare this with IHTSDO, HL7, CEN, OASIS, Linux.org, Apache.org etc - they all have core paid posts to enable the organisation to do its work.

  • if we say that openEHR (for some odd reason) should not try to get funding for such posts, but it would be ok to get time instead, then all we are saying is that some other organisation(s) should essentially loan people to the Foundation to do this work and pick up the cost. This is equivalent to them just paying that amount of money into the organisation. There may be tax benefits, but otherwise the basic argument does not change.

  • If on the other hand, other orgs provide some of their people, some of the time, for limited periods, to do specific tasks on projects, this is inevitably because it is in that organisation’s interest to do so. Many orgs, like the NHS, VHA, as well as universities, do this already. But these people aren’t performing core Foundation work, they are trying to execute some project on their own agenda. So this doesn’t actually help the Foundation get more organised.

  • as far as I can see, the wide experience in non-profit orgs of any kind shows that core paid posts (whether by direct funding or other means) are essential for good functioning.

The only thing to understand about Ocean is that (10 years ago) it didn’t decide to work in the Java space, which is the natural environment of open source these days. In the ICT industry today, there might be 1/3 of all companies oriented to Java (1/3 .Net, 1/3 everything else), and of that fraction, maybe 10-20% making their source code openly available. Ocean doesn’t happen to be in that demographic, along with probably 80% of all companies in ICT (and health ICT). Ocean’s mission is therefore not to build open source Java implementations of anything. Nevertheless, Ocean has donated significant time to openEHR specification projects, open sourced/ing its subsequent specification work, and open sourced 2 key tools (which incidentally attract no external coder activity, proving the point that if it isn’t Java, PHP, Python etc, it is not seen as open source). I don’t think there are any commercial archetype editors at all.

If we look at where the main implementation work that has been done open source, and in Java, the bulk came from Rong’s original (small!) company A-code, and since then Cambio has financed his further efforts. This work, like the specification work, was significant, and as far as I know, never reimbursed - it was done because the relevant people thought it was a useful thing to do. Significant additions have since been done to the EHR Java code base, including by Zilics, a Brazilian company with a commercial openEHR implementation, other Brazilian companies, Ocean, as well as many universities, including CHIME, Linköping, and many others (the proper list visible on SVN of course). Likewise to the Java tool base, including Linköping’s archetype editor, no longer currently maintained.

I can’t answer for CHIME specifically, but universities are of course 100% welcome to put as much time as they want in some openEHR-related activity, and that is certainly happening. The CHIME Opereffa project is specifically an open source reference implementation built on Rong’s earlier platform. With more resources, this project could certainly make faster progress. But with everyone working on their own main job (PhD, company project, lecturing etc), today it is done just with little pieces of time as they are available. There is really no avoiding the problem of funding here: no matter whether it is done on the openEHR side, or by some other organisation, it just costs money for dedicated analyst/architect/developer time.

The blockers are, in my view: the unfunded central posts (preventing efficient organisation, management and maintenance), and the dire e-health standards situation, where none of the official standards adequately address the EHR space, but adopters in general feel unable to easily embrace non de jure work like openEHR (preventing more widespread ‘customer’ uptake).

The openEHR/IHTSDO dialogue is partly to address these questions. We can hope that it produces a result, since it is clear that the industry is not happy with the status quo.

  • thomas
(attachments)

OceanInformaticsl.JPG

65

One further point I omitted - a key activity that has to be done by orgs
like openEHR is education, dissemination and communication. This is also
normally related to one or more paid posts in such organisations,
because it is so critical.

- thomas

66

Hi All

The adoption of all health standards is very slow; and it is universally so.
Government eHealth programs have embraced HL7v3 or CDA or openEHR or 13606 -
at great cost. Still things go slowly. The fact is that until people want a
shared logical model of the actual EHR (rather than a message or a document)
openEHR will not be centre stage.

Why have openEHR at the centre of a national program? There are a number of
reasons that are potentially persuasive.

1. The core platform as implemented does not describe clinical information.
This allows changes to clinical information to take place in the world of
archetypes (the 99% of standardisation that is yet to be carried out!). The
corollary is that only when there are enough high quality archetypes freely
available does the argument for this separation is compelling. There are
close to 300 archetypes of good quality now available and we are going to
see a rush of validation coming soon.

2. Adopting an EHR service allows applications to come and go without
losing/changing/adapting the health records. For patients, hospitals and
major providers this is a massive benefit - you can keep your health records
for a lifetime. It does, on the other hand, require enough high quality
applications to be available to provide solutions for providers. There is a
growing number - nursing, paediatric hospital, field hospital, infection
control, cancer research - but there is still some way to go.

3. The recording model in openEHR fits with the business process of
healthcare. A lot of things work out of the box from a medico-legal
perspective in a distributed environment. The coherent management of
workflow over a range of applications and services is the next step in this
process and the one that Ocean is concentrating on.

Even if the first argument is only accepted as a logical model for EHR
services, the tooling available now makes it possible to produce different
artefacts for different systems. On this basis people are becoming more
willing to invest resources in developing archetypes through open
collaboration on the internet. The second and third arguments are bringing
some institutions and software vendors along.

Seref is doing a wonderful job and Ocean has some experience in real
implementations to which Seref is party - so he does not make the same
mistakes! Where simplification is beneficial let's do it.

The reality is that openEHR proposes a massive shift in emphasis - from the
message to the EHR. More than 7000 vendors in the USA have invested in their
own data model - which they maintain. Until it is quicker, cheaper and
easier to build a system using openEHR, uptake will be slow. But I guarantee
you, the alternatives will get slower and more expensive by the day. That is
why we should continue: health information is highly complex AND 'you ain't
seen nothing yet'.

Cheers, Sam

67

Hi Tom,

a few points informally (I am not on any boards of any organisations,
so these are my own thoughts):
      * any organisation like openEHR needs some core paid people to
        execute key functions, and to maintain continuity. There is an
        'officers' level, which runs any organisations, including
        admin and other support staff, and there is an operational
        level.
      * for the operational level, there are typically posts like CTO,
        CMO, infrastructure management, project coordination, and so
        on. If the organisation is to do properly what its members
        want - typically 2 things: a) manage specifications/standards,
        including member involvement in this, and b) manage open
        source projects, potentially largely staffed by volunteers -
        then it has to have a few dedicated posts. Otherwise it
        becomes no-one's responsibility to actually coordinate things,
        keep infrastructure running etc.

If these are the thoughts of, whom I consider to be, the most open
source/content aware person within the openEHR Foundation. Then I
*highly* recommend:

Hippel, Eric von.
Democratizing innovation / Eric von Hippel.
ISBN 0-262-00274-4

(available in PDF via a CC license; btw)

Also, you may want to re-visit your comments about Linux.org and
Apache.org. The history of how they became organizations is more
important than the fact that they exist today.

I hope you find this useful.

Regards,
Tim

68

Greetings,
I can see a specific pattern emerging in the recent mails of this thread, to which I’d like to response, and contribute.
I will repeat my point I’ve made some time ago in this discussion, and by doing so I will insist on it. To deliver what openEHR is capable of, there is a significant requirement for time and money.
Therefore I agree with Tom’s points about posts and funding, and disagree with Erik and Tim, if I’m getting what they’ve been saying right.

There is a consensus one can identify, about what is actually demanded from the openEHR standard. All the names heavily involved in this domain have discussed these requirements in time, some seeing a larger set of requirements than the others. At a very simplistic level, hours is what we need indeed. But there is a threshold for the amount of hours me, you, or anybody else needs to put into openEHR to deliver what is clearly demanded.
With such a complex problem, we need lots and lots of hours, and the threshold which turns the required work into a full time position is reached very quickly with openEHR.

The perception of this cost is different for everyone. Going back to the anology I’ve used, everyone is asking for what they need, which is way smaller than the total demand, and this is mostly likely to be the reason for people to say “how hard can it be?, I’m just asking for XYZ!” Delivering what a party asks for, without breaking the consistency of the solution (which makes it a solution in the first place), requires a lot of work and coordination. As in many things in life, people (including me) are only interested in what they’re looking for, and if it is not there, than it does not matter to them if there is huge amount of work and promise out there. I do the very same thing every day.

But there is also another side to this fact: when you contribute, your contribution does not necessarily solve a lot of others’ problems. You may think that individuals each committing a limited amount of time into the solution may develop what we all ask for, but you simply can not. You need to set priorities of tasks, based on the actual impact of the outcome of the tasks, and unless everybody who puts input in any way knows absolutely everything about everybody else’s requirement, you can not do this.

So often I see this necessity either neglected, or its very existence not accepted. Many of the other works so often referred to are similar in one way or another to our project(s) here, but in my opinion that similarity is not strong enough to suggest that what has worked in other foundations, projects would also work with openEHR. Size and scope of the task at hand, the problem domain, the commercial space around the domain all matter in success or failure of initiatives like openEHR, and just looking at outcomes and only including one or two of the factors which led to those outcomes do not produce meaningful examples.

Just like many other groups out there, openEHR is suffering from an asymetry. The input regarding the requirements and what should exist is gigantic, compared to input to deliver the results. Also, the cost of making a request is much lower than actually responding to that request.. This is not a bad thing, not a complain or rant, this is just a fact of this kind of organization. It is just that you need to acknowledge this situation to solve the problem, and develop a way to solve the problem with this picture in mind.

Whereever we are with openEHR, this is where we are now. This is the solution we have in our hands, which reached this point as a result of whatever happened in the past, which will never ever change. openEHR was born in its own way, grew its own way, and due to million things effecting its domain, ended up where it is now. Looking at the history of other works won’t change this. Their evolution brought them to where they are, better or worse, and openEHR’s brought us here.

Let me specialize Tom’s argument: as far as I know, no member of the openEHR community who is putting his/her work out there for others to used freely, is getting paid just for doing so. To tackle the tasks I’ve outlined above, there should be people who are funded to perform these tasks. People’s work on openEHR in their own companies, environments are not relevant unless they end up being available to the rest of the community, and there are very few instututions who let their intangible assets go into public domain.

We need to do a huge amount of work, and I personally don’t see this work being done in any other way than a properly funded, planned, and managed approach. You can’t break down all tasks and diffuse it into some good intention based completely democratic virtual work force. openEHR has lots of tasks with this nature at hand, and many things which has worked in other scenarios won’t work here because of this.

Best Regards
Seref

69

Tim,

this is an interesting looking book, I downloaded it. However, as I and I imagine others won’t get through 220 pages instantly, do you want to summarise what you see as the lessons from it, while this discussion is still warm?

  • thomas
(attachments)

OceanInformaticsl.JPG

70

Hi Tom,

Tim,

this is an interesting looking book, I downloaded it. However, as I
and I imagine others won't get through 220 pages instantly,

Well, that is all a matter of personal cost/benefit; isn't? :slight_smile:

do you want to summarise what you see as the lessons from it, while
this discussion is still warm?

Nope, not on my todo list nor in a consulting contract. I only offered
the information there for those that think it might be helpful. Reading
a book is a context sensitive thing anyway.

Cheers,
Tim

71

Let me specialize Tom's argument: as far as I know, no member of the openEHR
community who is putting his/her work out there for others to used freely,
is getting paid just for doing so.

We don't get any extra up front payment for putting things out freely,
but certainly many of us (probably including you and Tom) have had
some kind funding that at times allows us to do openEHR related stuff
on paid time. It's actually easier to get certain kinds of funding if
you let your work out freely, sometimes it's more or less a
requirement. (I don't say that it's easier to get _private_ investor
money for open source, but enough of the big openEHR end users will be
governments and public health care providers in the long run.)

In cases when openEHR work is funded by taxpayer money (like EU- and
national projects) then I personally think it's bad manners not giving
results away for free, but I know others that probably will disagree.

People's work
on openEHR in their own companies, environments are not relevant unless they
end up being available to the rest of the community,

True.

I tried to use similar thoughts as an explanation of how things go a
bit slower when that road is taken. Any wider dissemination of
implementation experiences will then depend on the goodwill and
available time of the people in such companies. Even if the goodwill
is there, then there is still a dissemination bandwidth problem when
doing research and development primarily in closed instead of open
environments. We all understand that there are other more pressing
needs in a company, needs that must be prioritized over documenting
and sharing your implementation findings with the general public. That
is a reason to aim for shared open research and development if speed
is an issue and if any good business model allows it.

and there are very few
instututions who let their intangible assets go into public domain.

Not true.

http://developers.facebook.com/opensource/
http://developer.yahoo.com/hadoop/
http://code.google.com/hosting/search?q=label:google
http://code.google.com/webtoolkit/overview.html
http://developer.apple.com/opensource/ (e.g. http://webkit.org/)
http://oss.oracle.com/
http://www.ibm.com/developerworks/opensource/newto/#9
(While at IBM, some might like the heading "Open Standards Are Not
Born; They Evolve" at
http://www.ibm.com/ibm/governmentalprograms/ipos.html )

Why do you think these giants often cooperate in open projects? One
reason is that open source is a very clever way to share risks and
talent. Would it really be better for the Yahoo and Facebook
brainshare in e.g. the hadoop project to just fund the Apache
foundation to employ some hadoop developers and maintainers rather
than having their own Yahoo and Facebook employed engineers actively
contribute?

Yahoo and Facebook surely do sponsor the Apache foundation in general,
but the invested time is a lot bigger sponsoring. See who sponsors...
http://www.apache.org/foundation/thanks.html
...plus the amounts, _and what the money is used for_...
http://www.apache.org/foundation/sponsorship.html
...it isn't really for research and development costs is it?

We need to do a huge amount of work, and I personally don't see this work
being done in any other way than a properly funded, planned, and managed
approach.

One of the best things that can happen to open source projects (and
probably also to open specification projects) is that a big
financially strong users (preferably more than one) start using it and
invest time and engagement.(See e.g. the Hadoop story at
http://cutting.wordpress.com/2009/08/10/joining-cloudera/ ) In the
case of openEHR such users could be national health IT-programs and
local health care providers with their own IT staff.

Probably openEHR interest will remain a bit low until there are more
and better free demo systems though, and until then risks are that
funding will be at the same low levels as now. (I hope to be proven
wrong about the difficulty in getting monetary funding directly to the
foundation in it's current form.) So perhaps I really should try to
shut up and code+publish instead to speed up my part of demo
development.

Just one more try with the most urgent openEHR problem before I stop:

[...] the world of
archetypes (the 99% of standardisation that is yet to be carried out!). The
corollary is that only when there are enough high quality archetypes freely
available does the argument for this separation is compelling.

I agree with Sam that most of the interoperability work, the archetype
development, is still left to do (and agree with most other things
said in that well formulated mail). That's why I and many others (e.g.
Thomas Beale, Andrew Patterson, Martin van der Meer) have tried to be
very clear on the risks of not opening up the licence of the
archetypes to CC-BY rather than the current infectious CC-BY-SA. See:
http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal

With CC-BY the big players (NHS et al) can let their clinicians
cooperate in global archetype development on paid time, and they won't
have to even bother about the potential risk that the hard to grip
openEHR-foundation central decision process does anything stupid to
lock in their invested work. They can leave whenever they please and
take a copy of their invested work with them. That freedom then
becomes a reason to actually stay. (Even Google knows this, see
http://www.dataliberation.org/ )

I think the openEHR foundation board still has miserably failed to
communicate their reasons for stopping or delaying a licence change of
openEHR hosted archetypes from CC-BY-SA to CC-BY. Some of us have
seriously started discussing archetyping of data sent from medical
devices, including proprietary ones. Should device people come begging
the foundation to liberate certain archetypes from the SA bondage
every time they find use for one (and how long would that take) or
would they be forced to go the anti-interoperable way and start
archetyping such things from scratch in a track separate from the
openEHR CKM archetypes?

I have even heard people say that copyright issues is a potential
reason not to use international openEHR hosted archetypes as a basis
for national eHealth work. Why not simply eliminate such an argument
with CC-BY?

Couldn't somebody else than Sam from the foundation board try to
explain their reasoning this time to see if they can explain better?

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

72

Hi Erik,
This bit:

and there are very few
instututions who let their intangible assets go into public domain.

is written in the context of openEHR.

openEHR may end up in a relationship with big vendors, similar to some of the examples you have provided.
For this to happen, what we have out there has to pass a certain threshold, and this is where we are having the trouble. In order to convince strong supporters, we have to provide actual working software, which proves at least our key points, and with openEHR this is a big task.

This is where we absolutely agree: we need implementations freely available, and we are pushing for that as hard as we can. As you can see from the comments, this is not enough, and even with lots of effort, we are facing a chicken and egg problem here. Here is how it goes:

Capable, open source demonstrator is required to gather interest and support, but this is a big work item, so we fail to develop it to the extend it would help us prove the point, people say it is not there yet, and we go back to starting position. At CHIME, we are trying to break this with the incremental approach, and I’d say it works quite good, but still not good enough to demonstrate every key capability the specs provide.

I personally see this big bootstrapping requirement as a unique problem of this domain, and that’s why I’ve been suggesting the things I’ve been writing.
I know that there are many paths an open source initiative and business model can take, but I’d like to have that discussion with clear suggestions/list for work items, and people who will be responsible with it.

Best Regards
Seref

73

Compared to creating your own world class web server in the mid 1990's?

RE: http://www.apache.org/foundation/how-it-works.html

74

Tim,

a few points by way of response:

  1. the NCSA web server (which I used to administer in one company) was built by normal paid engineers in jobs where they were directed to build that tool - i.e. dedicated paid time.

  2. there has been no barrier that I am aware of to people wanting to come and work on any openEHR project, indeed it is and has always been highly encouraged. If you think there is some barrier, please let us know.

  3. with respect to Sam, you are doing him a disservice. Sam is a medical doctor, and people technical here sometimes forget that the main game in the real world for doctors is giving care: seeing patients individually; improving methods of care; sometimes working at policy level to change health care systems. From that point of view, the ideology of software is pretty uninteresting; people in this position are heavily oriented toward solving the problem. As a GP familiar with computers, Sam was using Windows to built desk-top tools 20 years ago, and even 10 years ago, it was the only realistic way to built desktop applications. There was no way for small companies to easily build a desktop app out of C++ or other such engineering languages. So the choice of using (today) .Net has nothing to do with the ideology of open source or otherwise; it was just about using tools that were available to solve the problem.

As it happens, Sam is very interested in open source, and the Archetype Editor was open source since day 1. It turns out that the world at large is not interested in helping write even this tool. It may be that unless something is written in Java, Python, PHP etc, it is not seen as open source. For the other tools built by Ocean, the priority was always to build something economically that solved the problem most efficiently.

  1. There is nothing stopping other companies being particularly open source oriented. Indeed, Zilics did it some years ago, building on Rong’s original Java openEHR code. This also didn’t magically make hoards of programmers come on board (in fact only the programmers from their company worked on it). The same thing can be said about the CHIME Opereffa project. As Seref said, this is largely because any such project that actually is open sourced, is not perceived to be sufficiently relevant to other parties in solving their problems that they should start work on it. So they don’t, the write some other software of their own. This in my view is an indicator not of the bloody-mindedness of people, but of the massive complexity and diversity of the field. Its needs just can be solved by building a single tool like an Apache server.

  2. One key difference between the kind of solutions being built in this domain and Apache is that Apache is ubiquitously useful - to everyone. It’s like running water - everyone wants it. So of course it is easy to get bazaar-style open source taking off in that situation. Same with Linux. In the e-health area, it is much much harder, and that’s what history shows. The various attempts to set up and run communities, cannot be said to have succeeded - even with hundreds of individuals available and apparently motivated to make something happen. Yet, no real open source EHR solution has appeared. I suggest that this is because:

  • it is intellectually hard, and is not a problem that can be solved by jumping into code before doing some serious design work
  • many people have different, incompatible ideas of what an EHR is, and therefore don’t agree on what to build anyway
  • it requires interoperability as a key feature, and interoperability requires agreement. It is extremely hard to get meaningful agreement on technical standards for e-health, and the poor results of the official bodies (using completely the wrong algorithm and business model) are evidence of this. Open source, as a movement, has made practically no useful contribution to interoperability, so clearly, it is a problem that has to be solved elsewhere - in my view, as you know, by a dedicated engineering/development group.

In hindsight, what was probably needed was an IBM to spend $30m developing an EHR stack and then giving it away through Eclipse or so. Nevertheless, progress is happening, and it will not be long before more open source tools are available.

  • thomas
75

Hi!

Democratizing innovation / Eric von Hippel. ISBN 0-262-00274-4

this is an interesting looking book, I downloaded it.
However, as I and I imagine others won't get through 220 pages instantly,
do you want to summarise what you see as the lessons from it,
while this discussion is still warm?

The first chapter, 17 pages of easily-read book text, actually seems
to be a summary of the book, offered by the author.
Chapter 1 pdf: http://web.mit.edu/evhippel/www/books/DI/Chapter1.pdf

Under the title "Users’ Innovate-or-Buy Decisions" on page 6 in the
chapter-pdf above one gets some hints regarding "agent costs" that
might explain why most apache-hosted project contributors are working
at real "user"-companies and are not agents for the end users funded
by the foundation.

Regarding the need for funded development, I think there is a
misunderstanding in this list discussion - I don't think anybody has
said that developers don't need funding for a project at the scale of
openEHR, neither has anybody said that full-time position for
developers would be bad. The underlying issue is rather
future-proofing the role of a foundation in this puzzle in order to
allow larger entities to trust it and a proper community thinking to
evolve. I won't go into details over again but you can probably get
some hints by re-reading the discussion and the links with this in
mind.

I personally see this big bootstrapping requirement as a unique problem of
this domain [...]

Seref, calling it a "bootstrapping" problem was a good way to put it,
I think it (for techies at least) describes the present openEHR
situation in an excellent way.

If e.g. IHTSDO now has seen this problem and wants to help out with
the initial bootstrapping, then perhaps they can temporarily
themselves employ people like Tom for a while to work on open source
tooling and documentation according to IHTSDOs requirements and at the
same time inspire the foundation to transition into a more open and
sustainable form in order to survive the changed requirements that
will likely become even more apparent when the bootstrapping phase is
over. I don't know if that's what the openEHR-IHTSDO talks are about,
they seem to be pretty secret and cut of from any community
discussion.

Back to the book, links to all chapters and the entire book:
http://web.mit.edu/evhippel/www/democ1.htm

What I have read so far is very interesting, and it seems to avoid
becoming yet another political pamphlet, rather it seems to be a
theoretical framework based on empirical findings, so thanks for the
book recommendation. I think the openEHR approach in the long run can
inspire and allow a lot of end user innovation (as described in the
book) without loosing interoperability and transcending into total
chaos.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

76

I should have added earlier that the openEHR Java project is a pretty good example of the meritocracy Tim wants to see. It has 16 committers, and the list remains as active as ever, with a large number of subscribers. Although currently under-resourced, it works in exactly the way it should, not only that, its history is typical. The original core of code was written by Rong Chen and his small company, as part of a system to deploy at Karolinska Institute in Stockholm. Like everything else, the core initial code needed to be built by a very small number of people, with a very clear and complete idea of openEHR, and what they wanted to build. Large additions have been done by the people at Zilics, Seref at UCL, and various others. Many other programmers are using the code and constantly improving it. None of them do so unless it aids them in solving a problem they are working on.

There is nothing stopping more people joining either. The limitation that I would say this project has is not lack of volunteers or enthusiasm, it is dedicated paid time to:

  • do proper architecting of large changes / enhancements

  • do better project management (admittedly, this could be improved today for free by making better use of the openEHR Jira issue tracking system)

  • get together physically and meet.
    It is hard to do some of this stuff well with no financial sponsors. Nevertheless what has been achieved is an excellent piece of work, and it continues to grow. One day I believe it will be as indispensable as Apache to those that need an EHR.

  • thomas

77

Hi Seref,
Have you published this interesting document somewhere except your weblog? I want to cite this in an article.

Best Regards
Pariya

MSc; PhD Candidate
Department of Computing Science and Engineering
Chalmers University of Technology
http://www.chalmers.se/cse/EN/people/kashfi-hajar

78

No I did not. Honestly, it requires corrections and even after that, it would probably only go under wiki. I’m not sure if this could be a publication :slight_smile:

Best Regards
Seref