Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

Clinical (archive)
21

Yes – there must be some kind of misunderstanding. The intention have never been that end-user should do the important and challenging work on developing clinicial information models (archetypes). The idea have been that this gives the clinical community an opportunity to influent and co-operate in this work.

I think all agree that the development and deployment of ICT solutions for healthcare is a large socio-organizational-technical challenge. The work done by domain experts is only a (important and essential) part of that problem domain.

22

The great advantage of OpenEHR, and possible other 2 level modeling software is not that it is easy for non technical people to use or develop with. Users should never develop systems. And for using, it does not matter which storage is behind a system. I sometime notice that it is hard to find good reasons why an organization like an hospital should switch to OpenEHR, and sometimes you see solutions to not really existing problems mentioned as an advantage. For me the most important advantage of OpenEHR is its flexibility and that it can change information-schemes without having a lot of heritage to carry. I explained it before, I don’t remember if it was on this list, but if so, excuse me. What I have seen are medical information-systems which keep on growing in complexity and that during 20 years. A hospital information system I know has grown to 7000 tables in 20 years (350 new tables every year, two new tables every working day, no kidding) A GP information system has grown to 1000 tables in 10 years (100 new tables every year). There will always be changes, new medical cures, organizational changes, other medical professionals doing something, etc. All the time when new functionality is needed new tables are created, old tables are never removed or changed, no-one dares to touch them, and every year less programmers understand the semantics. Documentation does not help much, because the documentation also often refers to situations from the past. One natural thing of documentation is that it diverge from reality, this happens so often that famous developer-guru’s say that it is better not to document a system. A system which needs documentation is not a good system. Code to the tables becomes spaghetti, people come and go, and test-frameworks keep the thing running, but not many people really understand what the system does. I have seen such systems quite a few times, not only in healthcare Just for fun: This one is famous: The burden of maintaining or expanding or changing such a system gets higher every year , until the point is reached where the price of maintaining is higher then the price of a big reset A new system will be bought, a team of experts will need a year or so to determine which data still have understandable semantics, and of course, the important data, like birthday, insurance and name of patients mostly will survive the transitions. And after some years, the new system will develop the exact same flaws as the previous system. Many people do not realize the cost of the data-tangles which exist, or they think that professional system-maintenance can avoid this, and thus, it will not happen to them. But it will, I have seen very professional environments, academical hospitals, a team of highly qualified technicians working full days, maintaining the system (how much does that cost?) which have fallen into this trap. Complexity is the enemy. In a OpenEHR system you never create new tables, you always store in the same tables, because the semantics are not in the storage, but in the archetypes, which only need a limited structure to store and never changes. This can be an Object Oriented storage solution, or XML, or relational, that is not important for this point. So, the system has limited complexity, and the complexity will remain limited. Companies, also hospitals, try new things, a new product-line, a new medical cure-project, create archetypes for that, run it a time, adjust it a few times. But the system will not become more complex. The semantics of the storage are in the archetypes, not in the storage itself. Archetypes are easier to understand because they are not a web of tables related to each other, and related to tables outside the project, they are self explaining and have quite simple structure.

23

Hi all,

I’ve been a long-time lurker in the lists while doing my PhD and I still try to keep tabs with what openEHR is doing. I wanted to react and take part in this discussion particularly because their paper resonated with me in some points (and not in others). I think the paper has merit and I’m interested (and quite jealous of too) that they did what I had wanted to do eventually with openEHR had time been kinder: to look and compare the global openEHR and the local openEHR(s).

The paper’s finding that you cannot separate social issues from technology is not new; and there is an inherent tension between a computer system that is based on simplification and closure (determinate states), from desires of freedom and flexibility usually associated with the social (yet, has anyone not felt the functional-driven approach set by bureaucracy without the need of any technology). So, although their point on the illusion of separation between the social and technical is correct; it is also true for every information system there is, past, present, and no doubt, future. This includes the accounting books from the middle-ages which tried to settle down some concepts (money in; money out), while giving flexibility to other concepts (varying prices of cereals; intangible assets, etc.).

When I researched the global openEHR (in contrast to implementing ones), I found that the project had harnessed open source in ways which made the modelling of ambiguous requirements possible precisely because there was no concept of determinacy. I remember a long series of discussion (Nov 2010?) between Thomas and Ed regarding openEHR’s way of thinking about requirements, contrasting it with the notion of design by committee behind (relatively) closed doors. The public space that open source affords openEHR is not just a trendy word, but it can create what Chris Kelty refers as ‘recursive commons’, a sort of space that respects certain values and logics (in his study, Free software) that can function with relative independence from competing logics that threaten its own existence (in his study, closed software).

As an open source project, openEHR is quite special in what it does. Whereas open source usually puts the ability for local populations (schools, architects, etc.) to collaboratively ‘own’ methods of productions (otherwise in the hands of those who have the key to closed software). openEHR creates this ownership ability at a conceptual level, necessarily removed (but never quite so) from local contexts. I remember a discussion between Heather and Ian (in 2010?) on an allergen-related archetype with a doctor who was particularly concerned for personal reasons and what constituted a ‘good’ archetype relative to templates and local concerns (thus taking local concerns into account at this global level).

What ‘good’ means is extremely ambiguous in all cases, but that’s the point and openEHR’s greatest contribution and greatest challenge: the global project has purposefully put the definition of ‘good’ in that very public space of the open source world, and I don’t think it would be inaccurate to say that openEHR has thought this through already (e.g. governance change) and will continue to do so (e.g. local ambassadors). In this sense, I don’t see at all that openEHR is technologically deterministic, on the contrary. Yet the implementation side requires some forms of simplifications and closures (Luhmann’s concepts, not mine), not necessarily at odds. The question I think, becomes one of building bridges between the diverse communities involved (whether level—national, or context—small clinic, etc.) in processes of community engagement. How this can take place is extremely challenging involving both strategic and tactical thinking. Strategic: how to create a coherent whole (e.g. that openEHR’s mission is shared and adapted by the various levels), and tactical: how to involve clinicians more easily (e.g. the use of soft systems methodologies to understand local worlds).

By the way Thomas, I’m really interested in what you have to say regarding the ABD. There are theories in information systems regarding activity theory and I’m curious to see if there are any connections with that.

Daniel

24

Hi Daniel,

I read most of your thesis, it is fascinating (it’s one of those things that requires contemplation, so I have not read it straight through). I recommend others to have a look.

One thing that I think we can say about efforts like openEHR, and indeed any large-ish ecosystem project (including SDOs like HL7 etc): there is the intended / understood sociological analysis on the part of the builders (we who make something in openEHR) and then there is reality. How we think it should work in the real world can easily be wrong-footed by sociopolitical realities, and these latter are ill-defined. Thus, if we are naive (we almost certainly have been in some ways), we get some things wrong and then are surprised when the world doesn’t work in what we consider the most rational way (it rarely does). This is what happens around ‘adoption’ - things get twisted by shifting government policies, changing funding programmes, enterprise amnesia and many other phenomena. The world is always more complicated than we think it should be, and than our abstractions would imply…

Regarding ABD, I won’t report too much just yet because I need to be sure of what the group leads want to do in terms of presenting their thinking over time, i.e. not jump the gun. When I am able, I’ll post something.

  • thomas