The image associated to this blog post shows two typical (very simplified) structures of an eHealth environment with the same number of clinical systems.
With a big drive in implementing and upgrading Clinical Information Systems, which eHealth integration structure is best for your organisation? Below I’ve outlined a high level overview of the two structures and how they impact on the eHealth environment of your organisation, mainly from a technical point of view.
The first structure is an eHealth “Waterfall”, and is a very typical design of early (and many current) eHealth environments. For the most part, the clinical information systems operate independently from each other with little or no knowledge shared between them. Data tends to flow in a single direction from the patient administration system (PAS) to the clinical information system (CIS) and all roads eventually lead to the final source of truth, the electronic Medical Record (eMR) or electronic Health Record (eHR).
The second structure is an eHealth Web, and is the emerging structure that is organically building as eHealth environments and clinical information systems become more advanced. In this structure, rather than the clinical information systems acting as digital islands from each other, they create connections and share their data, essentially creating multiple minor eMRs with a specialised clinical focus for the department who owns it.
There are pros and cons of implementing each structure, and these should be considered early before your organisation decides the structure for you. Below I discuss some of the key considerations with each design:
eHealth Waterfall Structure:
Pros –
Implementation costs are lower with minor integration requirements (less interfaces to design, configure and test). There is less duplication of data from an organisational perspective, requiring less infrastructure to host and maintain. Change management costs are lower with fewer interfaces to test and maintain lower system outage management requirements.
Risk profile of this structure (technically) is lower (*not necessarily clinically lower) due to the data management of an eHealth waterfall structure being mostly centralised. Also, typically there are 1-2 client facing interfaces for clinical data from a clinical information system, reducing administration requirements. Change management to the clinical information system should only affect one clinician-facing interface (aside from the system itself) requiring review (the eMR/eHR), further reducing risk overheads.
Cons –
Implementing a waterfall structure segregates your data causing a lack of ability to employ powerful automated decision support tools based on other diagnostic service results. The segregation of data also causes a requirement to have multiple applications open and logged in (at least the clinical information system and the eMR/her) for the full patient clinical record. This can be inefficient clinically and frustrating for the user.
eHealth Web Structure:
Pros –
The ability to have Radiology, Pathology and other diagnostic service data available in an Emergency Department Information System (EDIS) can be extremely powerful in the efficient delivery of clinical services via decision support tools. These decision support tools can reduce unnecessary tests (reducing cost to the organisation), create automated smart workflows and reduce risk to patients. Furthermore, the display of diagnostic service results can be configured to provide the most efficient view of the patient for a specific department. I.e. the requirements for layout of pathology and radiology data including what data is displayed will vary from department to department based on their clinical needs and specialty.
Cons –
The unfortunate truth is the more integration involved in an eHealth environment, the more opportunity there is for error to be introduced. The old saying of “measure twice, cut once” applies to eHealth, except it tends to be more like “measure ten times, tentatively cut once…”. The ramifications of data being misinterpreted due to the incorrect configuration of an HL7 feed can be disastrous (and fatal). One of the increasingly difficult factors of an eHealth Administrators role is ensuring the integrity of their systems diagnostic data being displayed in remote systems. The more systems displaying their data, the harder it gets to safely manage this.
An individual diagnostic interaction may not be a large amount of data. However, combine the size of an organisation with a years worth of diagnostic services and you will have hundreds of thousands of interactions (and more if you’re part of a multi-site organisation). If this data is being processed and stored by multiple Clinical Information Systems, the requirements for the ICT infrastructure sky rocket, along with the cost.
Aside from infrastructure costs to host this eHealth structure, your organisation will have increased ongoing management/administration costs for each system. As system upgrades, security patches and configuration changes are made, there may be upwards of a hundred individual tests required to verify the integrity of the clinical data as it’s displayed. If you have six systems displaying diagnostic data from your clinical information system, then your testing requirements have grown six fold. This effectively increases your salaried time costs by six fold for each change to eHealth systems (which may occur on a weekly or monthly basis).
Summary:
So which eHealth structure is best for your organisation?
The truth is… Both.
While it looks like there is a lot of negative impact of an eHealth “Web” structure, the fact is that it is a more complicated beast, but the clinical relevance is extremely important.
Neither one nor the other will provide the best outcome for your organisation. Having strong governance in place to handle a hybrid setup will be the best way forward, ensuring highly technical services have the information they need to effectively support the clinical needs of the patient.
One key factor that will make the process of designing your eHealth environment easier is the implementation of a solid eMR/eHR, but I’ll leave that discussion for another day.
