Technology in Health Care: Building an Integrated Infrastructure
Introduction
Public health care systems are impeded by a lack of online information. In particular, important patient information is often not electronically recorded and therefore cannot seamlessly flow to where it is needed — the point of care. A modern information, communication, and technology (ICT) infrastructure would enable a coordinated view of patient information. This will reduce costs and have an enormous impact on patient care.
Most health care ICT infrastructures are a mix of different technologies and systems that have been developed over a long period of time, and some are still based on mainframe technology. There are also different "stovepipe" systems used in many different departments, each with different information on patients. This creates a problem in how to develop new solutions to deliver more modern services.
There are two approaches to evolving this type of existing infrastructure to a new architecture. You can either design a new system from the ground up or build an integration layer over the top of the existing systems.
To design and implement a new distributed system from the ground up to meet the current and future requirements and the internal operational and decision-support needs required by health care staff is a huge task. It would have to be designed so that it could be logically and modularly extended to meet future requirements. Data in the original systems would need to be extracted, cleaned up, and moved to this new system. However, this is a high-risk strategy because the effort required is enormous and the timescale very long. The difficulty is compounded if some existing (older) systems are not well-understood or documented. However, the major issue is the very dramatic internal upheaval that this redesign would cause. All departments would need to synchronize their efforts and be willing to embrace radical change.
An alternative approach is to build an integration layer over the top of the existing systems. This integration layer would interface directly to the existing system's data and manage interaction between front-end applications and the existing back-end databases. This would allow new applications to be developed in new standards that are not tied to any constraints of existing back-end systems.
A key requirement for this integration layer would be to ensure that the data is written back to the existing systems in the correct format for each. There is likely to be duplicate information in these different systems, which could be stored in different formats. For example, in one system the patient name format could be in a single field (first name, last name) but in another could be in two fields (last name, first name). The integration layer would then have to understand these differences and translate data from a front-end application into the correct format for each back-end database. This means that new functionality can be added by changing the integration layer interfaces and not the back-end systems.
The Integration Layer Architecture
An enabling technology for this integration layer is extensible markup language (XML). XML technology has the ability to easily create this type of data integration layer. In XML the structure of data is sent along with the actual data over standard Internet protocols (HTML). An XML-based language schema consists of a set of tags — the vocabulary — and the way tags can be used — the grammar. In addition, many XML-based languages have been, or are being, defined through collaborative ventures by standards bodies, groups of companies in a particular vertical market, and governments. Adoption of such XML standards, where available, will make interoperability easier.
Workflow and Business Process Automation
The XML integration layer enables the development of new applications and functionality based around XML-driven workflows.
This means health care staffs interact with XML data-driven applications through clearly defined business rules or business processes. For example, suppose that a business process, such as patient booking, consists of three sequential manual operator tasks. When the receptionist fills in the patient's details, a workflow could be designed to create a hospital visit case linked to the patient's medical history records. Based on symptoms, the application could prioritize this patient with respect to others in the waiting area. The first-line hospital staff could be notified on their systems that this person is waiting, and they can update the system when they take on the responsibility of first-line medical diagnosis/treatment. This record is updated based on the diagnosis/treatments required, and if the patient is checked out without requiring further treatment the visit is closed. If the patient is kept in and sent to a ward, the system notifies the ward of the pending patient, their status/treatment needs, and so on until the patient is released.
These different tasks in the workflow could involve not just different staff but different departments. Since the integration layer transcends multiple departments, this is easily possible. Commonly required functionality could be incorporated into standard building blocks that sit on top of the XML layer and could be made generally available for use by workflows. These components could be implemented through Web Services — programmable application components that are platform-independent and are not tied to particular hardware or operating systems. They can be accessed securely from anywhere on the network and are based on standard Internet protocols. They offer an open XML-based solution for distributed computing environments. The simple object access protocol (SOAP) specifies the encoding of an HTTP (hypertext transport protocol) header and an XML-based document that enables a program in one computer to "call" a program in another computer, pass it information (parameters), and receive results back. This approach can offer a number of key benefits:
- It directly supports and automates business processes to achieve an end-to-end solution that extends across health care departments and employees.
- The 'status' of all cases can be easily recorded. The workflow could be designed to be proactive and regularly report the case status back to the user.
- Since a workflow maps directly to a business process, which is what the user is directly interested in, it is the right place to measure typical service level agreements (SLAs) and key performance indicators (KPIs).
- It drives more efficiency into these business processes, delivering greater levels of service with the resources available.
- It enables an improved level of automation. For example, parts of forms can be pre-filled, which in turn allows staff to focus on more valuable activities.
- It is highly flexible and allows workflows to be added or modified as required, thus introducing new functionality easily.
The Multi-Channel Portal Interface
Another key enabling element to this infrastructure would be the user interface. By using a customer relationship management (CRM)-type portal, you can introduce greater benefits to both the internal users/departments and the patients. This CRM portal would provide the interface through which users access online services. The principal feature of such a portal is that the information provided can be filtered and personalized for the user. The services available to a staff nurse may be different from that of a pharmacist. The personalization capability of the portal application allows for the delivery of different applications or workflows to different users through the same interface mechanism.
It should be designed to support devices with different levels of capability and intelligence, ranging from standard browsers to devices running "rich client" (or productive) applications that allow work to be performed offline or in an occasionally connected mode. The portal would support standard browser clients, like Microsoft Internet Explorer and Netscape Navigator, and microbrowsers found in PDAs and handheld devices, as well as wireless application protocol (WAP) and i-mode wireless browsers. Also since the portal is a separate layer it could readily be extended to support devices with other formats and new standard protocols as they emerge.
The capabilities of a device or browser could be determined dynamically as it connects to the portal, and the interaction optimized accordingly. For example, patient monitoring statistics could be sent via XML to the specialist directly into Microsoft Excel so the specialist can use this data within another application or systems. There are also options for downloading code to run within the browser to provide an additional level of sophistication; however, this depends on the capabilities of the particular browser or device and its security settings.
Alternatively, rich applications can easily be developed that access the information via XML and perform local processing. A Windows application can be used instead of the browser interface. Such applications offer the user the full capabilities of the hardware and the operating system. This would be more appropriate for fixed positions within a hospital that require access to more rich information, such as X-rays and statistical analysis information.
The New Architecture
Once you have put these layers in place you then have an infrastructure that looks like Figure 1.
Figure 1 Example of an XML Integration Layer
The other advantage of using this method is that you can then modernize each departmental system on its own without significant impact to other systems. Essentially you could then look at creating a standardized back-end database solution across all departmental systems, and by upgrading one system at a time you can consolidate your back-end infrastructure over time, while still allowing the new functionality to work. The switch over to a new back-end system is more straightforward and likely to have much less impact to the ongoing service delivery.
Mobility and Occasionally Connected Computing
Wireless LANs, based on the 802.11x standards, popularly known as Wi-Fi (wireless fidelity), and wireless WAN cellular technology like GPRS connectivity options are an important development and enabler. Overall there is a pronounced trend to use mobile wireless computing devices. The key benefits are the reduced wiring infrastructure costs and the ability to be "always connected" in defined areas such as hospitals. Security is an issue, but there are software-based encryption and authentication solutions available, and new security standards are being developed.
Increased use of mobility-based devices, such as smart phones and new wireless LAN- or WAN-enabled notebook or tablet PCs, drive a different application architecture need. This is what can be termed "occasionally connected," where there is a need for client-side processing when there is no connectivity available or not enough bandwidth.
For highly mobile workers such as hospital doctors, nurses, and general practitioners who need a small and very portable intelligent device and are willing to sacrifice the rich capabilities of the notebook or tablet PC, then a PDA/handheld device is ideal.
Framework for Patient Care
Online information and diagnostic systems will increasingly provide a first point of contact for non-emergency health care. It will also provide an opportunity to promote a healthier lifestyle that, in the long run, will benefit everyone.
However, it is the creation and maintenance of a patient medical record, called a longitudinal health record (LHR), an electronic health record, or a health care record, that will be the centerpiece of the health information infrastructure (Figure 2). The LHR would start at birth (or whenever an existing patient next contacts the health system). Throughout a patient's life this information would accumulate in a structured manner; doctor's visits, prescribed medicines, medical tests, allergies, blood type, X-rays, physical injuries, operations, hospitalization, and family history would be recorded. It is this full information that will allow medical staff, or automatic program assistants, to quickly and accurately assess a patient's health care requirements.
Figure 2: Longitudinal Health Record (LHR)
A patient's LHR must be accessible by a user from anywhere. Therefore, the health infrastructure will support a range of wired or wireless devices. Mobile wireless-notebook and tablet PCs are particularly useful since they offer a large screen to display detailed information or graphics such as X-rays. In the situation where reception is poor, an "occasionally connected computing" approach will be necessary. For example, a doctor visiting patients at home might routinely download these patients' LHRs to his notebook PC. If during a visit a patient's LHR needs to be updated, the changes will be stored on the local notebook PC for synchronization with the master copy of the LHR at a later time.
People will be able to view their own LHR and that of their dependents once they supply the appropriate authentication credentials. Similarly, biometrics and role-based access codes would prevent unauthorized personnel from viewing or changing sensitive, protected health information.
The centralized LHR would provide a "virtual" treasure-trove of data that could be mined "anonymously" for many purposes, including clinical trials, research, and, in cases of a national emergency, to help identify possible bioterrorism outbreaks. The databases could be used for epidemiological purposes to track illnesses, national wellness programs, and to monitor outcomes of disease-specific, nationwide educational programs.
Rather than replacing the many existing "autonomous" health care systems to support a new centralized LHR database, an XML integration layer could be used to provide access to patient's virtual LHRs, leaving these existing systems largely unchanged. This would involve adding a layer of distributed processing servers that interface with these standalone health care systems and that communicate with each other to provide the elements of a patient's LHR as requested by the client. This enables you to create an LHR database and still maintain the integrity of existing systems, thus allowing a very fast way to enhance functionality and capability.
Point of Care
How might this new distributed infrastructure supporting coordinated access to patient LHR information work?
A person uses the public online diagnostic service in an attempt to identify the cause of a health problem their child is experiencing. The symptoms direct them to call a health service number and speak to a health professional, who immediately records personal information and symptoms and then, with the aid of a sophisticated decision support system (DSS), decides that the child (patient) is potentially an emergency case, so they directly dispatch an ambulance to the patient's home. The information that has been recorded would be linked to the patient's LHR and forwarded through a wireless network to the ambulance so the attendants can be prepared on arrival. The emergency personnel would record the treatments given in the field on a wireless tablet PC, which would again be linked to the patient's LHR. The patient would now be either monitored/treated at home by the emergency personnel or transported to the hospital.
Upon admission to the hospital, an enterprise-wide wireless environment would make mobile point-of-care (POC) health care computing a reality. Personnel using a wireless tablet PC would admit the patient; records for medications, allergies, past history, treatments to date, and so on would be instantly available to the emergency and recovery doctors. Using a handheld mobile device, doctors could order tests and medication electronically through computerized physician order entry (CPOE) — which checks for drug interaction, allergy, or overdose — and view pathology results instantly. Radiology images would become available over wireless networks, eliminating the need to handle film X-rays, and test results could "follow" acute patients from the ER to the operating room (OR), eliminating potentially life- threatening delays in treatment. Online DSS could recommend "best practice" treatment algorithms to staff.
Doctors will dictate into mobile devices, and their voices (and subsequent transcribed text) would become part of the new acute-care records and eventually the LHR. Dictation at point of care would help ensure that information regarding ongoing care is available in clear and legible form to all who are participating in the patient's care.
To reduce medication dispensing errors, a nurse would use a wireless handheld device to scan both the patient's bar-coded wristband and the bar code on the medication. The central pharmacy system would confirm that the medication is correct. Additionally, uniform care protocols that were monitored and followed would help ensure improved quality outcomes. Pathology data and radiology reports that were linked into expert treatment algorithms would help to prevent mistakes from occurring. For instance, suppose a lab report came back showing a high serum creatinine. The system would also notify the doctor that an imaging study that involved contrast media had also been ordered, which could now be potentially harmful to the patient's kidneys. These interactions would occur seamlessly in the background of an integrated system, while the physician had more time to spend on direct patient care, not on information gathering and collating.
A wireless hospital environment could also have operational benefits. Wireless patient monitoring equipment would remain "connected" as the patient is moved around the hospital. In areas where wired networks are not traditionally available (like the OR and recovery room), automated processes to monitor patients could more easily be established. As devices became "smarter" (like the ventilator that would be centrally monitored and programmed), the need to upgrade expensive wired networks would be obviated. Wireless networks would also allow hospitals and clinics to improve inventory and supply chain management. The same devices that can scan a patient's bar code can scan product bar codes. This can monitor inventory, avoid out of stock situations, and allow for vendor-assisted supply chain replenishment.
Lastly, the in-house electronic medical record (EMR) system would be linked to all parts of the hospital: the hospital information system (HIS), laboratory information system (LIS), clinical information system (CIS), radiology information system (RIS), picture archiving and communication system (PACS), and the pharmacy. The relevant information would be incorporated into the patient's LHR. Reports would automatically be sent back to general practitioners and consultants. As the patient became ready for discharge, reports would be generated that assist social services with discharge planning and placement.
Home Care
Home care is becoming increasingly important as the population life expectancy increases. In First-World countries, more elderly patients are encouraged to live in the community at home. Mobile wireless devices and occasionally connected computing are key enablers.
A social services physiotherapist or home assessment worker would need to "survey" the home to ensure it meets the requirement of the elderly, disabled, or chronically ill person. This might include home alterations such as a stair lift, ramps, grab rails, bath hoist, and equipment such as a walking stick, a bed, and a chair. For these highly mobile workers, who also need to remain connected, a wireless handheld device would be a great advantage. It would allow them to take digital pictures of the home and add voice annotations and comments — which would be automatically transcribed. This would save time since hand-written notes need not be keyed into a system later. The availability and ordering of items and arranging of support services could all be done on the spot.
These patients will require ongoing medical attention. Doctors and therapists would use wireless-notebook or tablet PCs to access an individual's LHR during visits. In addition, wireless monitoring devices such as a pulse and blood pressure device could be set up and then monitored remotely. Depending on the patient, these measurements could be initiated by the patient at regular intervals, or monitoring could be automatic and continuous. In either case the monitoring system would incorporate a DSS so it can pre-emptively detect conditions that would likely require medical intervention.
Summary
A major obstacle in making services available online is getting the existing systems to interoperate. A solution that leaves the existing systems intact and operational is to add an XML-based integration layer that makes information readily available externally in defined XML formats. With this foundation layer in place, additional cross-system operations and workflows can be added in a modular fashion to implement new services. The multi-channel portal provides the user-interface component to this distributed-processing environment and can be designed to support a number of user devices, including wireless devices to provide access from anywhere and anyplace. Most importantly, the content is specifically personalized for each user to provide a one-to-one relationship to patients and businesses.
