Innovation and Openness --- Is There Room for Both

This article is also available as a PDF file.

Abstract
Introduction
Drivers for Innovation in Health IT
How to Engage End Users?
openEHR Two Level Modelling Approach
The Hand-Over Paradigm
Why We Need Openness?
Discussion and Conclusions
References

Abstract
Focusing on people in healthcare delivery needs to be backed up by streamlined flow of health information at the point of care. Thus semantic coherence of health information now becomes a must rather than a mere option. Health IT is not delivering what is expected. We argue that this is in part due to the limitations in the communication between clinicians and IT professionals resulting from the inevitable “cultural” mismatch. This paper explores new opportunities and challenges from both business and technical perspectives in the wake of Medicine 2.0 and presents new directions in the domain of information architectures and software development. openEHR prescribes an innovative development methodology which we propose will serve as an effective means to tackle communication problems. It is envisaged that the road to success is paved by innovation and openness (in a broader sense including open standards, a cultural change and appropriate roles for open source paradigm).

1.    Introduction
Person centred care implies empowering patients and their environment in all steps of care delivery. If the care is now expected to take into consideration the very different aspects of individuals, then health IT should also take into consideration some new data, information and security requirements. From an IT perspective this means that a new user class with significantly different requirements comes into play. The clinicians with clinical user roles will inevitably have to perform substantial amount of person user actions on behalf of their patients. In other words the clinicians will become proxies for the subjects of care and their environment, and act as a gateway to the health record. Accordingly, from an IT development perspective, the clinicians will eventually take the role to define a considerable amount of functional requirements of applications which they will use to gather and store clinical data.

Now overloaded with many health IT requirements, putting clinicians into driver's seat is a necessity. Not only must we provide them with flexible and user friendly applications, but also address the many other IT requirements such as safety and interoperability. Mainstream software development methods all depend on a critical requirements collection phase where practically domain knowledge is elicited from users. This is the phase where the cost and quality of any software product is greatly affected [1]. Put simple any HIS can only be as good as the clinicians’ contribution and the ability for the clinical requirements to be actively and effectively passed to the technical development.

There is a practical limit of cognitive exchange in the clinician-developer communications during requirements collection. This is in part due to the essential difficulties of human communication; but in healthcare the depth, breadth and complexity of the domain severely pull down this limit.

2.    Drivers for Innovation in Health IT
Currently most large scale health information systems (HIS) tend to be monolithic applications built upon the limited set of requirements that were available at the time of software design. These systems had one abiding feature – a closed system development mentality – which has led to a silo effect of systems deployment and an inability to adapt to changing requirements. The missing and/or wrong requirements at the outset combined with rapid changes thereafter due to high rate of change in medical knowledge and processes result in “big ball of mud” systems which are expensive to maintain, difficult to integrate and marked with low user satisfaction [2].

From a business perspective the penetration of IT into the healthcare market is not at the expected level. The “provider” centric market is already saturated and everyone is in a wait-and-see mode therefore avoiding big investments. The ultimate market is the large scale “patient” or “community” centred one, but many vendors and their standards certainly could not deliver. It is expected that health information exchange will bring on the real benefits of health IT and set forth clear examples of return on investment to businesses and the community [3,4].

The theory is that open environments, more specifically the effective use of open standards would increase the ability of systems to better exchange information. However, experience has demonstrated that without sufficiently strong governance, standards end up replicating the issues of non-standards compliant implementations. In healthcare this can be seen in the variations of HL7 v2 for example.

Currently there is an inherent semiotic dissonance within machine to machine communications in healthcare. A lifelong, longitudinal, secure and shared electronic health record (EHR) for all is seen by many as the enabler for next generation eHealth systems. It is argued that while messaging is essential for interconnectivity, the EHR cannot be realised by simply collation of messages [5]. This is supported by the adoption of new approaches by the ISO in the 13606 standard very recently [6].

3.    How to Engage End Users?
If the software requirements of HIS cannot be gathered at the outset (due to the aforementioned limitations), then a straightforward approach would be to follow an approach in which the requirements can be later added or modified without going through the costly recoding and testing phases again. This is why we need to put the clinicians permanently into the whole software development process and provide them with certain abilities to tailor the blueprint of clinical information. This blueprint consists of structure and semantics, dictated by some medical knowledge from which the clinical information are captured and persisted.

The openEHR two-level modelling formalism, which is adopted by both ISO and CEN, introduces stable reference models (RM) which define generic and healthcare specific information elements, and Archetypes for modelling the semantics and structure of clinical information [7]. While the former is of concern to IT professionals, the latter is targeted to clinicians. By using this approach software development based on stable requirements can proceed independently from volatile domain specific requirements. This has the potential to generate more initial development which could lead to an initial greater capital cost of development, but at the same time leave systems developed in this manner more versatile and adaptable/extensible. There is not impediment, bar policy, to incorporating open source software derived services into a commercially delivered application.

4.    openEHR Two Level Modelling Approach
openEHR Archetypes are defined by a formal domain specific language called Archetype Definition Language (ADL). During modelling, relevant classes defined in the RM are used as building blocks to assemble meaningful clinical concepts (such as blood pressure or a full radiology report) by means of formal constraints using ADL.  A good analogy to understand how RM and Archetypes relate to each other is to look at using standard LEGO® bricks to build some well-known structures (Figure 1).

RM consists of a small set of object oriented classes which depict generic characteristics of health records and necessary information items to meet ethical, medico-legal and provenance requirements. These carefully engineered classes can faithfully capture results of all medical entries; in other words it is guaranteed to store any type of current or future data. RM also includes ability for versioning of medical transactions and managing change-sets to handle input errors, simultaneous multi-user read/write access to the record, provides necessary information infrastructure for confidentiality and security.

During modelling Archetypes constrain selected RM classes and form a computer processable model. It is possible to define labels, data structures, data types, prescribed value ranges and values for some of the context attributes. In addition to the implicit knowledge, Archetypes can also be linked to external terminology/ontology systems and bibliographic databases. By doing so, they complement the knowledge in medical terminologies (some in the form of comprehensive semantic nets like SNOMED CT) and ontologies by providing key knowledge such as bindings to other knowledge sources, valid value ranges, existence, cardinality and occurrence of terms, and also their interrelations (i.e. mutual exclusivity or conditional existence). This ensures complete and non-ambiguous expression of domain knowledge by expert clinicians which is ready for consumption in the technical development environment.

 
Figure 1 - Analogy to the relationship between RM and Archetypes

This methodology also provides the ability to tailor the models to meet specific needs without breaking original semantics by a method called archetype specialization. Here, modifications that would result in more strict constraints than the original or additions are allowed [8].

A third component of the methodology is the openEHR Template, which assembles archetypes into larger structures like a screen form, document, report or message, and further constrain them for local use. They may add further local constraints on archetypes, including removing or mandating optional sections, and may define default values.

5.    The Hand-Over Paradigm
Any information system can be seen as a model of reality put together in a computable form to deliver specific functions for which it is designed for. Its behaviour and appearance, which define user experience, is depicted mainly by the very knowledge as well as certain technological factors. This comprises both domain specific and technical aspects; however assuming that the technical rigour is not changing from one area to another, it is the transformation of domain specific knowledge that is the critical step which determines the quality of software. It is more pronounced in complex areas such as healthcare where there is a marked cultural mismatch between healthcare and IT professionals. We can mention about “hand-over” of knowledge, somehow bidirectional, during the initial requirements elicitation phase in any software development project. Clinicians, without much idea about the technologic limitations or possibilities, express their needs verbally and often in writing. IT professionals on the other hand, without much background in biomedical and clinical sciences, try to comprehend these requirements and at times give feedback about the technical or administrative aspects – such as if this can be done within given budget and timeline.

It is extremely difficult to quantify but there is little doubt that this hand-over is far from perfect and that there is room for improvement. The openEHR two-level modelling is an innovative approach which can potentially tackle this by dramatically reducing the essential domain specific knowledge transfer between healthcare and IT professionals.

Archetypes can be authored by non-technical healthcare professionals by using free and open source editors with intuitive and easy to use graphical user interfaces (Figure 2). This leads to user empowerment and confidence, instead of alienation which typically happens and result in non-acceptance of HIS.

 Figure 2 - Blood Pressure Archetype in the openEHR Archetype Editor

6.    Why We Need Openness?
While the above approach looks promising in building individual applications, giving all that flexibility may seem to violate many of the requirements for interoperability. This is exactly where openness comes into play: no standardisation body, company or governmental agency is capable of defining one standard model for all. This requires a collaborative environment in which healthcare users and technical people discuss and create industry strength open standards and engineering specifications [9]. This is typically a community based effort where contributions are voluntary. An Open Source model used for core clinical tools and components may help in spreading the methodology to a wider community and better adoption. Another aspect often overlooked is the availability of the service and interface descriptions and the data itself. The structure and semantics of the data involved should also be made accessible. This is how we can achieve truly open systems (read interoperable!). However we do realise that Open Source model is based on an IT development mandate and may not necessarily mitigate the issue of Clinician-Developer communications; conversely, the clinical aspects of HIT delivery could benefit from the methodologies employed by Open Source model.

7.    Discussion and Conclusions
We have argued that getting most of the requirements at the outset during HIS development is hard and that there is a practical limit in communication when working with domain experts which we defined as the hand-over paradigm. We then pointed out to a solution by engaging main users, the clinicians, into the whole development lifecycle by allowing them to manage volatile clinical concepts and processes without depending on technical people. Experience has shown that developing clinical models in the form of archetypes using high level visual tools proved to be straightforward and understandable by even the non IT skilled clinicians [personal experience].

Incomplete or wrong requirements due to hand-over are not the only problems during requirements elicitation; one must also tackle unknown and changing requirements during the whole development lifecycle. openEHR two-level modelling approach also provides the means to alter software without going through the costly redesign, coding and testing phases. Software can be driven in the runtime by the underlying domain knowledge in the form of Archetypes.

The importance of an open collaborative environment and open systems has been emphasized in order not to compromise interoperability. Introduced by the openEHR Foundation [10] and now adopted by ISO and CEN, the innovative two level modelling and development methodology is now attracting considerable interest. As the success of the approach largely depends on the quality of content models produced by the collaboration of many experts from over 70 countries, the governance of the organisation is very important and now presents itself as a big challenge.

Just defining standards is useless without enforcement. This is why we see the proliferation of “standards” rather than harmonisation and convergence. Now the big question is how to attract vendors to this equation and create a sustainable business ecosystem. It is envisaged that, in the whole big world of “interconnected” health IT, a diverse set of services and products will symbiotically coexist on the sole basis of openness.

Having a good track record in health IT, New Zealand also has active policies and initiatives towards open systems. It is not unrealistic to expect a giant leap forward if we can leverage the high level of involvement of clinicians with computer based systems and years of experience by putting them into the “driver’s seat”.

8.    References
[1]    Sommerville, I. Software Engineering, 6th Edition. 2000. USA: Addison Wesley.
[2]    Foote B and Yoder JW. Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97). Monticello, Illinois, September 1997. Technical report #wucs-97-34, Dept. of Computer Science, Washington University Department of Computer Science, September 1997.
[3]    Walker, J., Pan, E., Johnston, D., Adler-Milstein, J., Bates, D. W. and Middleton, B. (2005) The Value Of Health Care Information Exchange and Interoperability. Health Affairs, 24, W10 – W18.
[4]    Girosi F, Meili R, Scoville R. Extrapolating Evidence of Health Information Technology Savings and Costs [Internet].  RAND Corporation; 2005.
[5]    SemanticHEALTH Report: Semantic Interoperability for Better Health and Safer Healthcare. Deployment and Research Roadmap for Europe. Brussels: European Comission - Information Society and Media; 2009 Jan. ISBN-13: 978-92-79-11139-6, DOI: 10.2759/38514. Available from: http://ec.europa.eu/information_society/activities/health/docs/publications/2009/ 2009semantic-health-report.pdf
[6]    ISO 13606 [standard]. ISO-TC215 13606 Parts 1-3. Health informatics - Electronic health record communication. International Standards Organization (ISO), Geneva, Switzerland.
[7]    Beale T. Archetypes: Constraint-based domain models for future-proof information systems. In K. Baclawski & H. Kilov. (Eds.), Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer, Seattle, Washington, USA, November 4, 2002, (pp. 16-32). Boston: Northeastern University Press.
[8]    openEHR Architecture Overview. Available from: http://www.openehr.org/releases/1.0.2/architecture/overview.pdf
[9]    Frequently Asked Questions (FAQ) for Open Systems [Internet]. Software Engineering Institute, Carnegie Melon University. [updated 2008 Jul 22; cited 2009 May 20 ]. Available from: http://www.sei.cmu.edu/opensystems/faq.html
[10]    openEHR [homepage on the Internet]. openEHR Foundation; c2007 [updated 2009 Jan 28; cited 2009 Jan 29]. Available from: http://www.openehr.org.