immediate adaptability

Part Four: A Generic Architecture for IA-CIS – Refactoring the EMR Model

This is Part Four of the 4-part series, Immediate Adaptability (IA).

Part One: Immediate Adaptability
Part Two: Objections to Immediate Adaptability
Part Three: Functional Specifications of IA Clinical Information Systems
Part Four: A Generic Architecture for IA-CIS – Refactoring the EMR Model

The IA-CIS model is in some ways a mirror image of the CERP methodology. Over time the CERP methodology has diminished the role of requirements gathering and systems analysis to the point where its serves only to direct system configuration of fixed data structures and concomitant code bases. IA-CIS does the opposite: it treats requirements and design as the primary function of creating a system for the specific needs of the user community, and then generates an implementation from the choices defined in the design, creating dynamic storage structures served by an engineered library of adaptabilities.

The value of CERP engineered systems lies in their capacity to massage large volumes of data for repetitive, little changing processing. The disadvantage is their inability to satisfy the needs for fast-changing and diverse work that needs to adapt practices immediately for any number of social, legislative, or professional reasons. Using an IA-CIS for clinical care systems will reduce the maintenance load on the CERP so they don’t have to be continually adaptable and hence will lower the costs of managing them.

Hence the architecture advocated herein is to repurpose CERP systems for back office functions and take them out of the clinical coalface locations where IA-CIS technology can provide better support for work and better efficiency gains for the relative costs of installing them. Customisation of IA-CIS is the most likely pathway for reducing workarounds, but with the more important positive benefits of increasing data collection completeness, improving patient safety, enabling cultures of continuous patient improvement, and, of course, simplifying training.

An important extension to the IA-CIS is that as a method for creating a single application for one clinical department so that method can be repeated for many clinical departments in the one organisation. Although each department designs their own system as an autonomous community, they all use the same design tool and the same instantiation library, hence the technical implementation can house them all in the same software installation. This is equivalent to providing multiple customised best-of-breed systems in the one software installation. This architecture introduces a different type of interoperability, that is, system to system by means of within-system native interoperability. So while users are operating under the belief they are autonomous, they are actually all working on top of the one infrastructure with a single data management process that enables the direct sharing of data (given the appropriate permissions).

IA-CIS do not of themselves solve the problems of interoperability between different systems supplied by various vendors. Hence, it is unavoidable that a CERP system and an IA-CIS will have to use some external coding standard to share data between each other. Methods for solving this problem are well established by HL7 or direct procedure calls. But within the IA-CIS paradigm the problem is solved at a highly efficient level.

The IA-CIS also has another significant advantage in that it eliminates silos of data and maintenance and support for multiple systems.

In this architecture it is important not to take a stance that assumes all data needs to be available in the one place. Most data needs to usable by the people who collect it, and then appropriately selected pieces passed on to those who have secondary use purposes. Just as the results of every research experiment is not required by the back office so not every action taken by the clinical staff needs to be defined by the back office. Autonomy at the front office with a requirement to deliver the essentials to the back office enhances the efficiency of both communities.

There is an argument in some circles that there needs to be a single source of truth which can only be provided by a CERP. This is a specious need. The extensive dispersion of care into many disciplines with many different technologies has already lead to an irreversible distribution of data across multiple information systems, such as radiology, pathology and pharmacy. Advocates for this position, who already operate multiple systems successfully, use this as an argument to exclude evaluating the value of locally optimised systems. The solution proposed here is to ensure that local systems have appropriate interoperability.

Part Three: Functional Specifications of IA Clinical Information Systems

This is Part Three of the 4-part series, Immediate Adaptability (IA).

Part One: Immediate Adaptability
Part Two: Objections to Immediate Adaptability
Part Three: Functional Specifications of IA Clinical Information Systems
Part Four: A Generic Architecture for IA-CIS – Refactoring the EMR Model

The intrinsic definition of an Immediately Adaptable system is in the name: immediate. We consider this to be a period of hours or days, not weeks, months, or years! However the requirements as defined by the complaints to the professional lists and elsewhere have a wider ranging scope.

The first level of problem is the concept of the EMR which describes a medical record as placed into an electronic storage bin instead of a filing cabinet. Such an EMR fits the CERP model which is focused on collecting content and storing it on a large scale and then processing the data for highly stable requirements, e.g. billing. Furthermore the CERP methodology requires decomposition of data into normalised storage structures of permanent definition and storage representation. As “efficient” storage of data is paramount to the processes of “capturing” the data and then “reusing” the data, that is, moving the data from the context in which it is collected to the contexts in which it is reused, are blighted by the effort and complexity of programming for the internal movement of the data. This involves elaborate methods putting data into fixed data structures and reading data back out whenever it is called for with the storage mechanisms tightly coupled with the data capture and display processes. Modern web technologies enable a significant loosening of this coupling but the CERP developers have been slow to embrace these innovations due to their years of investment in older software engineering methods.

Given their engineering paradigm, ultimately, the greatest limitation of the CERP approach is the effort, cost, and risk associated with changing the structures by which the data is defined and stored when a new data element needs to be inserted into a design, or changing the semantic meaning of an existing data item. This requires changing the underlying storage design and creating the code to store that data element and to retrieve it at all the points where it is reused without disrupting anything of the existing processings. With due cause, the large vendors, whose systems have thousands of data tables that are beyond the scope of any one person or even small team to comprehend, are aware that their data management is brittle where even a single accident in a new design or coding can bring down their house of cards. This is one of the crucial reasons for resisting modifications to CERP systems.

The process of separating the capturing data in one context, storing it in a rigid data structure, and then moving it for reuse into another context is fundamental to moving away from the idea of an EMR towards one of a Clinical Information System (CIS). A CIS is a software technology that is integrated into the processes of the users so as to support their work in the most active manner possible. Crucially it is NOT a system that cements in the processes of data collection and dissemination as found in a CERP EMR system. A CIS matches the users requirements for both the flow of data from one context to another, and their movement through activities of work that the users have to perform. A CIS supports both dataflow and workflow for the user. The third part of the triumvirate of a CIS is screen layout and design. The optimal design of a CIS is a dominant part of clinical usability research, but, due to the nature of the CERP methodology, usability discoveries have, at best, a slow journey in seeping into such systems.

An IA-CIS has to be easily and readily changeable, that is accept real-time change (or nearly so). An underlying architectural consequence of real time changeability is that it has to have dynamic data structures along with revision control that does not affect the previous versions of storage organisation or access to previously recorded data so that real-time use is uninterrupted.

We have named the data flow requirement of IA-CIS: native interoperability. This is the idea that data created or input at one point in a data flow can be referred to by its name wherever it needs to be reused. There should be no need to write code to read tables to transfer such data, but rather it should behave more like a link. Thus, when you invoke the name of the data at a time for its reuse in a new context, it appears at that point of invocation, without needing to do anything else. This introduces interesting questions about the protocols for naming data but stable solutions are available to solve them.

IA implies real-time design, which requires a design toolkit for specifying all the requirements of the user including, data definition, screen layout and behaviours, business rules, data flow, and workflow. Underlying these design utilities needs to be a design language universal to all CIS designs that become the specification of the operational system. This has an important consequence: the design of the users’ system is independent of the software that manages their data. The benefit is that design can be changed without affecting software code, and code be changed without necessarily effecting designs. Software maintenance is done independently of any CIS design processes. This radically simplifies the nature of system maintenance as their is no enmeshment of a given system design and the program code required to implement it.

Furthermore it opens the door for usability research to be directly incorporated into an operational system. To support usability research the only software engineering requirement is to have a library function that performs according to the usability task being investigated. If the feature to be investigated is not available in the design tool kit then the only software engineering task is to enhance the design tool to carry the function as an element of the design toolkit. To create an executable instantiation of the design as defined in the design language there needs to be libraries for all design functions and auto generation of data structures that are invoked at the point of real-time system generation.

While not an absolute requirement for an IA-CIS, built-in analytics are needed to achieve the user demands for being able to operationalise Continuous Process Improvement. The role of using a CIS for direct operational workflow is fundamental to its conception. However optimising the CIS over time requires the analysis of the behaviour of the CIS and the users as an integrated entity. This analysis is best achieved by having analytical tools built into the CIS that can actively monitor the CIS and its users to establish the value of changes as they are implemented. Omitting analytics functionality as an intrinsic part of the CIS will severely limit the ability of the user team to identify behaviours of the system (technology + staff) that warrant change and later measures those changes.

Part Two: Objections to Immediate Adaptability

This is Part Two of the 4-part series, Immediate Adaptability (IA).

Part One: Immediate Adaptability
Part Two: Objections to Immediate Adaptability
Part Three: Functional Specifications of IA Clinical Information Systems
Part Four: A Generic Architecture for IA-CIS – Refactoring the EMR Model

EMR systems built by large vendors have code development operations similar to Enterprise Resource Planning (ERP) ventures similar to SAP, arguably the most successful ERP provider globally. So I will label big vendor technology Clinical ERP or CERP. Smaller but older vendors no doubt have similar models. Only recent vendors appearing in the last 10 years are likely to have different approaches.

The problems with IA for CERP are that it ostensibly requires the vendor to:

1. Give control of the design of their CERP to the user community.
2. Have highly qualified programmers on call to respond when users require changes.
3. Have built-in mechanisms to manage automatic version control, including roll back.
4. Have built-in mechanisms to manage data such that data collected before a given change remains available after the change.
5. Change their interoperability functions on-demand to send and receive data from dynamically changing EMRs.
6. Have confidence that their technology can undergo continuous changes.

These criteria would not just increase the cost to maintain CERP technology, but also raise protests from vendors that maintaining large systems cannot be sustained intellectually as the systems are too complex to change rapidly to not create unexpected consequences. This protest would seem to be entirely valid. It is this very scale and complexity that inhibits changes to “usability” beyond the minimum, not to mention to support IA. The best-of-breed system vendors have done a better job with usability because they do not suffer the same complexity problem and their aim is to deliver a smaller range of functionality, however IA would still be a difficult concern for them.

The technical difficulty in delivering IA can be discerned from the process of creating a CERP system in the first place. The process is a sequence of tasks consisting of requirements gathering, systems analysis, data modelling, code writing, systems testing, and deployment. The CERP providers have escaped part of this process be removing the first two steps on the basis that they have built so many systems they know the generalisations of requirements and analysis. Indeed they have built large code repositories relying on these generalisations and are unwilling to change them because changes will affect so many of their customers. Moreover, the code bases are so large that they are unwilling to risk a large number of unexpected consequences of changes.

The CERP approach was state-of-the-art in the general IT industry of the 1980s but is out-dated for most modern purposes. The method suits large volume data transactions with stable patterns of work and processing, which may be acceptable for back office work, including health organisations. This does not suit the needs of dynamic workplaces where workflow is as important as data capture, data volumes are relatively low, local data flow and analytics are crucial for efficiency, and staff need to run continuous process improvement. In fact imposing immutable CERPs on patient-facing clinical operations blocks processes to create clinical efficiencies and productivity, as is frequently testified in the protests from clinicians in many fora.

The professional lists have many discussions about how multiple systems need more cross-consistency, because as staff move from one site to another, they have an extra cognitive load to learn how to use the many different systems. Training for CERP systems is both high cost and difficult, hence the complaints. A system optimised for IA will be customised for its community of use and so someone working across multiple communities will need to train on different IA systems. Would the same objection apply? Most likely not:

CERP “solutions” that fit the local workflow poorly will need significant workarounds in addition to the standard training that still has to be learnt by migratory workers;
Claims that the same technology from the same vendor have the same workflow and functions are often spurious – there are cases where two systems ostensibly the same cannot even communicate with each other;
Locally designed systems are truly optimal for the local workflow and so training on them is about learning how the local community actually works, surely a necessary criteria for successful health care;
Training on locally designed systems has little training costs for local users and modest costs for new users;
Senior staff responsible for the training of junior staff use the system to train them in the processes of work. It is often the case that a CERP system is training staff in processes that are considered undesirable, whereas an IA system would enable the senior staff to create an ideal training system. This overtime would lead to better standardised work practices where appropriate, and easier adoption of these better practices as they are defined by the professional community, because the IT behaviour is immediately adaptable.

Part One: Immediate Adaptability (IA)

This is Part One of the 4-part series, Immediate Adaptability.

Part One: Immediate Adaptability
Part Two: Objections to Immediate Adaptability
Part Three: Functional Specifications of IA Clinical Information Systems
Part Four: A Generic Architecture for IA-CIS – Refactoring the EMR Model

One of the major themes on the AMIA Implementation List is the need for better user interfaces, often couched in calls for more Usability research. There is much reference to the academic usability research and its failure to impact delivered products rolled out by the vendors. The vendors themselves are variously reported as claiming it is not needed, too subjective, too theoretic, already achieved by customer feedback, or they are doing it anyway.

A major debate at ACMI focused on academic research in usability. It was agreed that academic usability research has paltry penetration into vendor products. Furthermore usability research at one point in time can become moribund or irrelevant because technology itself moves on or the context of use of the vendor product changes while it is in situ, e.g. work practice changes due to new medical practices, government legislation, new medications, changing populations and disease profiles …. The Implementation List is replete with examples of complaints from physicians that they cannot get requested/required changes to their user interfaces because the vendor will not accept the changes or it will take inordinate amounts of time to make the change (IV excepted, because he has control of his interfaces since he works with the VA system).

We all understand that vendors are reluctant to make changes because it increases their cost of maintenance, potentially increases the complexity of their product, and the financial reward to them is insufficient to motivate them.

Complaints about the usability of interfaces on the Implementation List don’t address the functional behaviour required of the software needed to resolve these complaints, that is, the software isn’t:

1. Adaptable, and,
2. that adaptations can’t be made immediately, that is within the next few hours, days or weeks, but not months or years.

In its most simple and direct incarnation they are asking for “Immediate Adaptability” of the software.