Fig. 16.1
An architectural diagram of the relationship between clinical care information systems and clinical research systems and registries as part of the ECIS paradigm
IA-CIS do not 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 ODBC direct procedure calls. (ODBC Direct is an alternate mode of Data Access Objects (DAO) that accesses ODBC data sources directly, and taking full advantage of the remote data source’s processing capabilities.) But within the IA-CIS paradigm, the problem is solved at a much more efficient level by native interoperability.
The IA-CIS also has another significant advantage in that it eliminates silos of data, and maintenance and support for multiple systems. In this data architecture, it is important not to take a stance that assumes all data needs to be available in one place. Most data needs to be usable by the people who collect it, and then appropriate selected pieces passed on to those who have secondary use purposes. Just as the results of every research experiment are 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 false assertion when it is claimed. The extensive dispersion of a complex care process delivered by many disciplines with many different technologies has already led to an irreversible distribution of data across multiple information systems, such as surgery, radiology, pathology, and pharmacy. Advocates for this position, who already operate multiple systems successfully, use this as an argument to exclude evaluating the local systems value. The solution proposed here is to ensure that local systems have appropriate interoperability and support.
The imposition of inefficient and burdensome HIT in clinical workers has led to a Stockholm-like syndrome and worse such as:
“It is well understood in psychology that when people repeatedly experience unpleasant events over which they have no control, they will not only experience trauma, but will come to act as if they believe that it is not possible to exercise control over any situation—indeed, that whatever they do is largely futile. Attempts to remedy the operational and social disadvantage of clinicians subjected to inefficient systems depends, fundamentally, on understanding the effects of past trauma and its potentially cumulative effects.” [24]
In summary
Front-line staff productivity will make greater gains from immediate adaptability than interoperability,
Organizations will better protect patients with immediate adaptability technology,
Interoperability , CERP, and best-of-breed systems each represent usability at different types of context, and
ROI needs to be interpreted and assessed at their appropriate context, and efforts to conflate them into alternative competitive solutions is a misunderstanding of their different contributions.
An Architecture That Supports the Levels of HIT Context
A data architecture to satisfy all the requirements of the three levels of health organizations has to have these features :
Feature 1. Immediate adaptability for the Level 1 context so that patient-facing clinicians can work within a paradigm of continuous process improvement. Intra-interoperability with other non-service clinical departments is useful but not essential in that it enables in-hospital information to be provided in a more amenable manner, but the care of patients will continue regardless of its absence.
Feature 2. Intra-interoperability between specialty clinical systems and service clinical departments for the Level 1 context is useful so that the normal operational care of patients can run smoothly with the service disciplines which service many of specialties with the same service functions such as pathology, imaging, and pharmacy. This local intra-interoperability has for the most part been solved by the use of certain standards such as HL7 messaging and DICOM picture standards. Immediate adaptability has not been strongly advocated by the service clinical departments, probably because of the more routine nature of their work and smaller extent to which the information system capabilities effect their work processes.
Feature 3. Analytics is an important function at each of the levels of HIT context, but it is a different type of analytics for each. Clinical care units need analytics to understand the statistical profile of their operational activities, while a health organization needs analytics to understand the trends of activities aggregated over multiple units of activity, that is, what is common between each of their different clinical units. They also have to investigate the relationships between the costing of activities and the resources they put into those activities. Finally, they need to develop models of future activities to support resource planning and allocation.
Feature 4. Inter-interoperability requires the sharing of data within a large Level 3 organization such as a multihospital organization or a state or provincial government with many disparate health services. These organizations are dominated by the effort at getting data it can standardize for predictive analytics and to identify both acute and long-term health trends, in the first case to react to public health scares, and in the latter case to plan the delivery of health resources at a society wide scale. These organizations reduce the health organizations data to a “common data set” of limited dimensions, as it is too difficult to get data from many different types of health organizations to do anything that might be more reliable. The interoperability problem at this level is much greater than at the intra-level because there is a large number of organizations to deal with and so the complexity of the task is exponentially larger than at the intra-level. Adaptability of clinical information systems is of little consequence at this level because they are only dealing with a synthesis of data collected from many diverse settings. Often this is the level at which HIT acquisitions are determined and hence the success of CERP vendors who appeal to the HIT problem at this level.
We are advocating for a new architectural configuration that embodies methods for tackling these problems. The inherent notion is to change the common architecture of the Level 2 context so that it has the benefits of the Level 1 architecture without its drawbacks for Level 2, and the benefits for the Level 2 context without the disadvantages it creates for the Level 1 users. Conceptually, this requires a shift to a new viewpoint of CIS architecture in that it inserts the ideas of immediate adaptability, user-controlled design, native interoperability, and in-built analytics into the debate and aligns those ideas with the established technology of data warehousing.
The Architecture in Practice: Clinical Care Information Systems (CCIS) and Clinical Services Information Systems (CSIS)
We define two classes of health information technology (HIT): Clinical care information systems (CCIS) and clinical services information systems (CSIS). The CSIS are systems required by most of the clinical departments in a hospital setting such as surgery, pathology, radiology, pharmacy, and EMR. The CCIS are the systems required by the clinical specialties that in the past have used best-of-breed solutions but now are being swept into the EMR vortex . Crucially, when they are drawn into an EMR solution, they lose the ability to have the system adapted to their needs, and they are provided with workflows that predominantly make their work less efficient, require more manpower, and lead to much pushback.
Effectively, the work of a data warehouse is being harnessed to serve the work of a dynamic workplace with shifting practices, workforce, and demands on the capacity to adapt and change. The need for a CCIS solution is readily defined in a few criteria: Immediate adaptability (and hence near real-time adaptation), user-controlled design, native (in-built) interoperability, and in-built analytics. The software engineering solution for these criteria produces a very different type of architecture that creates the optimal blending of function of levels 1 and 2 systems while overcoming most of the drawbacks.
The software architecture as explained below has been implemented after a number years of experimentation and has demonstrated the proposed benefits are real. Underneath these four criteria is a key architectural requirement that the means of designing such systems has to be systemized [25]. The architecture has at its kernel a design tool that enables a user to create a design of an information system, this includes screen design, data flow design, and workflow design. The design is maintained internally in a design database in the form of a design language. Adding new design functions requires adding the capability of describing them to the design team and developing a formal method of expressing them in the design language. Then, the library code needs to be written which is invoked on calling the feature in a particular CIS. The data modeling function is managed internally by the software and is not available for the user to be concerned with or to tamper with. It is a basically an object-orientated strategy using relational stores for the management process. The critical objects are the screens or forms into which is embedded the dataflow, workflow, data management, and business rules.
Years of work since the original publication have solved many of the technical problems and demonstrated that a feasible and practicable solution can be achieved. Figure 16.2 displays the basic engineering architecture for creating multiple CISs in the one software environment and the access to the data via APIs, HL7 messaging , and a clinical data analytics language (CLINIDAL).
Fig. 16.2
ECIS architecture supporting a variety of clinical information systems within its own paradigm
There are some interesting emergent properties from this approach that strengthens its merits:
Property 1. Painless expansion and incremental design : Firstly, a system runs by invoking the design which is executed by a library function. A system that is defined entirely by the act of design intrinsically means that only the design has to be changed to create a new function in the CIS. Subsequently, a design can be prepared to cover a minimally necessary amount of workflow and then be added to regularly over time. This in effect enables a system to be not only a mechanism for experimental design with a roll back that can be executed at any time, but also a strategy for incremental development where after completing and operationalizing one subsystem the next most suitable subsystem can be chosen for implementation.
Property 2. Multisystem design on the one software platform : With a functionality to continuously expand one system, it is entirely possible to create a different clinical system on the same platform. There are an unlimited number of CISs that can be created and operate from the one software installation. So although this architecture is a pseudo-best-of-breed technology, it is also a multi-best-of-breed solution, effectively allowing users to create systems as if they are wholly autonomous, but all the while the underlying infrastructure is using the same code and data management strategies behaving like an enterprise architecture.
Property 3. User-controlled design : It is an advancement on user-directed design that enables the user to specify exactly the design they want. It is often the case that users don’t understand what they really want until after they have been disillusioned by being delivered something they thought they wanted. With real-time adaptation, the user can experiment with designs to their own knowledge depth and revert to older designs if new ones are proven to be non-optimum.
Property 4. Rapid prototyping : The ability to modify implementations at will means that prototypes can be built rapidly, tested, adapted, and generally system development be progressed at a faster rate than other technologies.
Property 5. Automatic version control : The design is implemented in such a way that it stores all versions of all designs; this includes screen designs, embedded business rules, data flows, and workflows. Hence, all version control is an in-built feature of the design tool, and reversion back to an earlier version of the system can be achieved by just nominating the version number.
Stay updated, free articles. Join our Telegram channel
Full access? Get Clinical Tree
