Mobile platform for treatment of stroke: A case study of tele-assistance.

This article presents the technological solution of a tele-assistance process for stroke patients in acute phase in the Seville metropolitan area. The main objective of this process is to reduce time from symptom onset to treatment of acute phase stroke patients by means of telemedicine, regarding mobility between an intensive care unit ambulance and an expert center and activating the pre-hospital care phase. The technological platform covering the process has been defined following an interoperability model based on standards and with a focus on service-oriented architecture focus. Messaging definition has been designed according to the reference model of the CEN/ISO 13606, messages content follows the structure of archetypes. An XDS-b (Cross-Enterprise Document Sharing-b) transaction messaging has been designed according to Integrating the Healthcare Enterprise profile for archetype notifications and update enquiries.This research has been performed by a multidisciplinary group. The Virgen del Rocío University Hospital acts as Reference Hospital and the Public Company for Healthcare as mobility surroundings.

Introduction

Cerebrovascular illness, including acute ischemic stroke, remains a major public healthcare issue[1] in the United States[2] and worldwide.[3] Stroke represents a frequent illness paradigm, which is potentially serious, has avoidable consequences and its diagnosis depends on performance and efficiency of treatment. Critical factors to be solved are patient access difficulties to better therapies and advanced medical devices within the first 4.5 hours (from the onset of symptoms).Therefore, time is important for the care of such patients. Among the benefits of telemedicine are the optimization and reduction of time in care. More broadly, its benefits range over different levels:[4] (a) from individual patients, telemedicine can support improvements in a patient’s health and quality of life, particularly for those with chronic diseases, by enabling safer monitoring at home and reducing the number of hospital visits; (b) through healthcare systems as a whole, telemedicine can help to address the shortage of healthcare professionals, particularly in sparsely populated areas (e.g. by providing remote consultations in ophthalmology), and can improve the efficiency, quality, and timeliness of healthcare service provision. Cutting waiting lists through teleradiology procedures (within or across national borders) and saving costs by enabling remote checks of implantable cardiac devices are some of the most commonly quoted examples; and (c) to the wider European economy, last but not least, telemedicine also has the potential to contribute to the growth of the European economy. Telemedicine is a global market that is expanding rapidly and is expected to continue enjoying high growth rates in the years ahead.

Our working team has been part of a research project in which a telemedicine platform[5] has been developed for the diagnosis and treatment of stroke episodes in static environments. In that project, the neurological team in the Reference Hospital has the technological means for replying to the consultations made from another hospital that lacks these kinds of specialists.

Telemedicine in mobile environments (intensive care unit (ICU) ambulances and specialized centers) will be used in this new healthcare service. This service starts from the pre-hospital care phase.There are few related studies[6-8] regarding telemedicine systems in mobile environments. However, there are no conclusive results at a clinical level regarding the technologies used. In this sense, our study proposes a technological platform that applies healthcare standards and regulations on clinical data sharing in order to reduce time in stroke patient treatment procedures in mobile environments within the Seville metropolitan area. This is based on already implemented platforms with developed and performed validation drills with regard to systems integration, audio/video quality, and signal coverage, among others.

In general, the main purpose of this article is to promote high-impact collaboration in the healthcare sector between emergencies and specialized medical teams during the acute phase stroke. By applying information and communication technologies we aim to reduce delays in diagnosis and treatment. This case study is on patients who are classified as “Stroke Codes,” activated and registered by the Public Company for Healthcare Emergencies (EPES; in spanish - Empresa Pública de Emergencias Sanitarias).These patients are part of the referred population in the metropolitan area covered by the Virgen del Rocío University Hospital. The reliability and safety of the mobile platform and its results regarding patients will be assessed. The pilot test will engage a mobile unit and a connection point in the Reference Hospital.

From a technical point of view this article represents a technological platform proposal design to support the aforementioned telemedicine process. The necessary integrations between the EPES mobile electronic health record (EHR) system and the EHR system of the Reference Hospital are described in detail. The technological platform covers the defined process following the interoperability model based on standards and the service-oriented architecture (SOA) focus. SOA main concepts are related to services, interoperability, and under coupling,[9] using messaging in accordance with the referred model in the CEN/ISO 13606 standard.[10] The content of such messages follows the structure set in the defined archetypes according to the same standard, CEN/ISO 13606. On the other hand, in messaging XDS-b (Cross-Enterprise Document Sharing-b) transactions have been used. These transactions are based on the Integrating the Healthcare Enterprise (IHE) profile (IT Infrastructure).The main devices used are the Panasonic Toughbook H2 rugged tablet PC, the Spontania video collaboration system with secure access via virtual private network (VPN) within the corporative network of Andalusia.

This article is organized by first describing the process functional of the telemedicine process, followed by the technological platform design that supports the process, starting with its technical architecture, the integrations developed among systems complying with archetype definitions based on CEN/ISO 13606 regulation. The last section contains the presentation of drills of the technological platform already developed, the conclusion and future studies.

Preliminary concepts

In this section we show some preliminary concepts. The section focuses on the functional scope of process.

Functional scope

The process starts when the patient or a family member calls the healthcare emergencies line, 061, of the EPES. The tele-operator then identifies the possibility of a stroke by applying, resulting in the the telephone trial protocol. Immediately the “Mobile TeleStroke” is activated and a healthcare emergency resource is sent with expert staff (general emergency physician, nurse, and driver) with the technological devices to perform the telephone assistance. Once at the patient’s location the corresponding diagnostic tests are performed by tele-assistance devices and a videoconference session starts from the patient’s home or inside the ambulance with the Neurology specialist in the Reference Hospital to direct the diagnosis. All the medical data are electronically sent from the device by means of a cross-consultation report. At the same time the patient may be transferred to the hospital. Once the ambulance arrives at the hospital the patient suspected of stroke can be directly requested for a computerized tomography (CT) without trial. Also, the neurology specialist may be present in the X-ray room to see the CT and diagnose the stroke type. If applicable, he may state its proper treatment.

Therefore this process can be divided into three well-differentiated phases (see Figure 1): telephonic triage, joint exploration, and treatment in the Reference Hospital. Each phase is described as follows to provide an ever greater scope.

Figure 1.

Generic functional process.

The first phase, telephonic triage, starts when the healthcare emergency call reaches the Coordination Center. In the EPES Coordination Center, the possible stroke is detected following the designed protocol. This protocol is performed by a tele-operator and if necessary by a physician from the Coordination Center. Once the possible stroke is identified and if a tele-assistance team is available, “Telestroke in Mobility” is activated. This entails the assignation of the service rendering team in addition to sending them to the patient’s location. The teams prepared for tele-assistance also perform other services, and exceptionally, it is possible for the team to go and cover a healthcare emergency service and find a possible case of stroke not detected by the Coordination Center.

The second phase, joint exploration, starts when the healthcare emergency team goes to the patient’s location. Once there, when patient data are confirmed, they must also confirm that the patient meets the criteria for inclusion (i.e. time of onset (when patient was last seen as normal) <180 min (3 h) before treatment would begin, age 18 years or older until 80 years inclusive, National Institutes of Health Stroke Scale (NIHSS) scale between 5 and 24 (severe and moderately severe stroke), and that there is no exclusion absolute criteria, although individualizing circumstances “off-label”)[11] and, thus, classified as “Stroke Code.”The physician alerts the neurologist at the Reference Hospital. The casualty physician makes notes on the mobile EHR system and sends a cross-consultation report to the neurology service of the Issuing Hospital. The neurologist views this report in the system of the hospital’s clinical station and may view the patient health records as a telemedicine episode. They both can access a videoconference virtual room to perform telemedicine tasks. From the teleconference, the neurologist can see the patient and perform the NIHSS. The neurologists can answer the cross-consultation report, issuing a diagnosis if convenient. After this, the patient is confirmed as “Stroke Code.”

Finally, the third phase starts with the call to the Reference Hospital Casualty Department that meets the patient on arrival. Therefore, this last phase is related to the activities performed in the Reference Hospital once the patient has arrived. The patient is taken directly to the X-ray unit for the corresponding CT, where the neurologist is already waiting for them. Thus, the neurologist can immediately assess the CT after its performance and diagnose if the patient has ischemic or hemorrhagic stroke, applying the corresponding treatment or directing the patient as necessary. To avoid false positive, in borderline cases, magnetic resonance imaging (MRI) diffusion sequences (sequences of MRI diffusion-weighted imaging (DWI)) or perfusion CT can be performed.[12,13] The process ends when the neurologist answers the cross-consultation report to issue the patient’s final diagnosis.

CEN/ISO 13606

One of the preliminary concepts of interest within this article is that related to the CEN/ISO 13606 standard. The CEN/ISO EN13606[14] is a European norm from the European Committee for Standardization (CEN) also approved as an international ISO standard. It is designed to achieve semantic interoperability in the EHR communication.

The overall goal of the CEN/ISO 13606 standard is to define a rigorous and stable information architecture for communicating part or all of the EHR of a single subject of care (patient) between EHR systems or between EHR systems and a centralized EHR data repository. It may also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components) that need to access or provide EHR data or as the representation of EHR data within a distributed (federated) record system.

To achieve this objective, CEN/ISO 13606 follows an innovative Dual Model architecture. The Dual Model architecture defines a clear separation between information and knowledge. The former is structured through a Reference Model that contains the basic entities for representing any information of the EHR. The latter is based on archetypes, which are formal definitions of clinical concepts, such as discharge report, glucose measurement or family history, in the form of structured and constrained combinations of the entities of a Reference Model. It provides a semantic meaning to a Reference Model structure.

The reference model of the CEN/ISO 13606 standard organizes information as follows (see Figure 2): the extract is part of the message containing the patient’s information. This information includes data entry policies and health information. This is organized as an extract containing a series of compositions that create data history. The compositions store simple statements on observations, assessment, or instructions (entries) that may be grouped in sections that represent internal document organization. Thus, the entries contain elements, each storing specific data. The elements may be grouped in clusters to display more complex data structure, such as temporary series, or tables.

Figure 2.

Simplified diagram of the UNE-EN ISO 1360610 model reference.

The system architecture will be detailed in terms of technological infrastructure, interoperability mechanisms, and user interface design. This can be done once the supported tele-assistance functional process and the CEN/ISO 13606 standard are defined as important preliminary concepts to be taken into account.

Design of technological platform

The purpose of this section is to present the design of the technological platform, starting with the definitions of architecture design. This section explains the integrations of systems and the interfaces developed.

Architecture

The architecture design of the whole system supporting the process is composed mainly by the following modules:

Issuing mobile. This corresponds to the ambulance or mobile unit. This unit has a device that loads the mobile EHR by means of a fat client. The camera incorporated into the tablet is used for the videoconference. In the ambulance, the tablet with a webcam is set up in the fixing system.

Coordination Center. This role is carried out by the EPES, where the servers of the mobile EHR are located.

Reference Hospital. This is where the hospital EHR system and archetype server are located. For drill process purposes, the Virgen del Rocío University Hospital (HUVR) is our Reference Hospital.

In Figure 3, the system architecture is shown with its nodes and its relations. The connections between the different modules are divided into four differentiated groups. The architecture of the connecting groups is presented as follows:

Figure 3.

Architecture.

Mobile EHR has a fat client application, connected by VPN to the Coordination Center to send the cross-consultation report.

Messaging between the mobile EHR, EPES Coordination Center, and the HUVR EHR is performed by ISO following the CEN/ISO 13606 standard.

To perform the videoconference, the EPES video collaboration system is used. The connection by the neurology specialist team is performed via the hospital’s EHR. The emergency staff needs VPN connection to access to the Spontania server.

Both the EPES mobile EHR server and the HUVR EHR are connected by an archetype server, located at HUVR, within the Corporative Network of Andalucia. By means of this connection, archetypes will be consulted, and the updates performed on the same will be notified.

The following subsection details the interoperability mechanisms of the systems on an SOA focus.

Interoperability

Health information interoperability is one of the requirements for continuity of healthcare.[15] The current health paradigms put the patient in the center of a process where organizations and professionals render their services, regardless of their temporary or geographical location. To ensure this strategy’s effectiveness, it is necessary that the information flows between different nodes allowing automatic interpretation. Thus, the professionals will have all the information necessary to perform their tasks avoiding test duplication problems and increasing the patient’s safety. It will be easier to perform information analysis studies by having available standardized information. They will be able to plan actions to perform automatically.[16]

In this aspect, the platform integration design has been implemented regarding the interoperability model based on standards and with a SOA[9] focus. The SOA is developed to increase technology efficiency and business agility.[17] Regarding messaging specification, eXtensible Markup Language (XML) messages were defined from a XML schema definition (XSD) according to the reference model on CEN/ISO 13606 standard. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable and is designed to transport and store data. The XSD describes the structure of an XML document. The contents on such XML messages follow the archetype structure defined by CEN/ISO 13606. An XDS-b transaction messaging has been defined in the IHE[18] profile.

The necessary integration services have been developed based on this definition. Such integration mechanisms offer coverage for cross-consultation report information, to both EPES request to HUVR as well as EPES response of the report with HUVR neurologists’ participation. These mechanisms have been developed to notify archetypes between both systems. The service implemented will be detailed in the following sections.

Cross-consultation report service

This service processes the cross-consultation report created for tele-assistance. Integrate the mobile EHR and the EHR of the Reference Hospital. The purpose of this service is to process cross-consultation report from mobility surroundings and its subsequent answer by the neurology group of the Reference Hospital.

To insure information safety, the communication of interoperability scenarios between the systems is performed via the Integration Platform through digital certificate and encryption mechanisms (RSA (Rivest, Shamir y Adleman), triple DEA (Data Encryption Algorithm)).

Notification service of archetypes

The cross-consultation report content is defined by an archetype based on the reference model defined in the CEN/ISO 13606 standard. The intervening systems build content in its corresponding user interfaces based on this archetype (see section “Interfaces”). The advantage of defining an archetype system is that it allows interaction with any system. In our case, both health record systems understand the same specification defined for the cross-consultation report. The notification service of archetypes notifies the creation event and/or document update corresponding to a determined archetype. The communication of interoperability scenarios is performed via Integration Platform and IHE[19] profiles. This profile method, IHE,[20] has been an important initiative in the industry to obtain interoperability in the health sector.

Interfaces

In this section, the design of the user interfaces developed for both the mobile EHR and the EHR of the Reference Hospital is introduced. The design is based on the previous definition of archetype regarding the cross-consultation report following the CEN/ISO 13606 standard. Any tool for graphic editing, such as LinkEHR Editor,[21] may be used for archetype definition. Information organization is specified in this definition based on the elements of the reference model. The existing relation of the reference model and the defined archetype is schematically displayed in Figure 4. For example, the cross-consultation report is related to a Composition, every tab of the report is related to a Section, and at the same time every section containing health information is related to an Entry, to finally define every piece of health information as Element.

Figure 4.

Definition of archetypes.

Once the archetype is defined, each one of the systems builds the user interface regardless of the technologies used in its development. If the system has mechanisms to interpret archetypes, any changes will be reflected in the corresponding interface.

The user interfaces associated with the systems involved are displayed in Figure 5. This figure illustrates the EHR system of the Reference Hospital, Virgen del Rocío University Hospital, including the cross-consultation report developed on model–view–controller (MVC) architecture of JEE (Java Platform Enterprise Edition) technology.We are also showing the cross-consultation report that has been designed on EPES mobile EHR. Such application is based on a heavy client following MVC patterns developed with .Net technology.

Figure 5.

User interfaces of the systems. On the left, the mobile electronic health record interface, and on the right, the electronic health record system user interface of the Reference Hospital.

The screens primarily cover the patient admission data, exploration, and consultation report. The consultation report shared between both hospitals has five possible statuses:

Provisional consultation. The mobile user saves details of the patient’s examination but has not yet consulted the specialist neurological group.

Final consultation. Details and consultation are sent to EHR system of the Reference Hospital.

Provisional response. The neurologist saves a response to the consultation but has not yet sent it to the mobile EHR.

Final response. The response is sent to the mobile EHR.

Historical information. Stores historical data regarding all interactions between the two systems.

During the lifecycle of the consultation report and its complementary data, data modifications may arise which must be shared with both the requesting mobile unit and the Reference Hospital.

Devices

Finally, the use of videoconference devices and systems is required in this new process for enabling medical users to cover the previously defined process and conditions in emergency situations, developed into concrete functional specifications. A methodology has been designed based on the multi-criteria decision analysis method (MCDA)[22] to support device selection.

MCDA is a decision support framework. Through this framework, technology users are involved in the decision criteria for technology usage, along with process designers (physicians and technicians). The methodology was applied in two phases. In the first phase, all participants were consulted and then a data analysis was conducted. A multidisciplinary team conducted tests with various devices evaluating the results. At the same time, participants of the design process provided feedback in regard to the tested devices. According to multiple criteria, the end users were asked for their assessment on specific devices, with the aim of capturing their preferences. Based on the collected preference data, the devices were rated.

A conclusion was reached using this methodology regarding the use of a tablet and a Bluetooth audio device. Both devices are ready for working conditions at the patient’s residence. Additionally, the use of the same device with an installed webcam in the ambulance makes it possible to change the camera location between two positions, making it possible to achieve a better view of the patient. The specification of this analysis and related results are part of future group work.

Simulation

In this section, the drill data developed on the technology platform is detailed. A series of tests were performed with the following participants: neurology specialists, medical staff (physicians, nurses, technicians, and operators), researchers, electronic support staff (developers and system maintenance staff), and actors playing patients role. In this way, several scenarios have been simulated in different places and circumstances.

A set of test cases were defined for drills, covering the most basic cycles associated with the connection among systems, image, and sound transmission quality, to several scenarios of patient location. Scenarios covering a full cycle with the participation of actors were included. All the drills have been performed within the Seville metropolitan area.

It must be pointed out that several scenarios have been defined to test the technological structure; therefore, the time obtained would not be necessarily patient assistance time. The platform has been technically validated after a series of drills (Figure 6).For instance, the performing times obtained at three different cases are displayed below, covering the main steps of a full cycle. These are representative case studies, covering the entire process and the information exchanges between both systems.

Figure 6.

Image of a simulation with actors.

Following the drill term, in which the example with the actors in Table 1 is included, the technological platform has been technically validated to test the treatment process of stroke patients in mobile environments. This technological validation was certified by the technical staff and has also been certified by the medical staff on tool use and videoconference image and sound quality. After this phase, the platform will be tested with patients suffering from clinical suspicion of stroke. Conclusions from these tests will be part of a subsequent paper.

Table 1.

Example of a full drill with actors.

		Case 1	Case 2	Case 3	Status
Test case: full cycle
Step 1	Patient suffers the first symptoms	13:35:00	17:00:00	18:00:00	Accepted
Step 2	EPES is alerted	13:35:00	17:00:00	18:00:00	Accepted
Step 3	EPES assessment on patient location	13:42:00	17:06:00	18:09:00	Accepted
Step 4	Start transportation of patient in ambulance	13:53:00	17:10:00	18:22:00	Accepted
Step 5	Cross-consultation report issue	14:08:00	17:17:00	18:12:00	Accepted
Step 6	EHR reception of the cross-consultation report	14:08:00	17:20:00	18:19:00	Accepted
Step 7	Neurologist alerted	14:10:00	17:20:00	18:19:00	Accepted
Step 8	Start videoconference	14:15:00	17:25:00	18:20:00	Accepted
Step 9	Start answering request	14:20:00	17:26:00	18:23:00	Accepted
Step 10	Issue answer	14:30:00	17:35:00	18:33:00	Accepted
Step 11	Answer reception in ictus	14:30:00	17:35:00	18:33:00	Accepted
Step 12	End of the drill	14:34:00	17:35:00	18:37:00	Accepted
Total		59 min	35 min	37 min
Median		37 min

EPES: Public Company for Healthcare Emergencies.

Conclusion

The new telemedicine environment has been implemented and already commissioned for project pilot testing, which includes the cross-consultation report. This enables its use by physicians from the stroke unit, EPES mobility surrounding, and the Reference Center physicians of Virgen del Rocío University Hospital.

On one hand, the XML messages were defined from a XSD according to the reference model in the CEN/ISO 13606 standard. The content of such XML messages follows the structure set by defined archetypes according to this standard. On the other hand, XDS-b transaction messaging design has been defined in the IHE profile.

Based on this definition, the necessary integration services have been developed. Such integration mechanisms offer coverage to cross-consultation report information sharing, to both EPES request to HUVR and the response of such report. Also, integration mechanisms have been developed for archetype notification between both systems.

Different tests have been performed on different settings of coverage, speed, devices, and so on, to ensure communication quality in different circumstances. The inclusion of specific devices is necessary in this process in order to comply with concrete functional specifications. A methodology has been designed based on a MCDA method.[21] Through this methodology, a conclusion was reached regarding the devices to be used.

A series of drills have been performed to technically validate the technological platform, demonstrating that time optimization for stroke patient attention can be achieved with its use. From the technological side, a patient arrival circuit has been prepared with alternative formulas that differ from clinical practices. After this phase, the platform will be tested with patients with clinical suspicion of stroke. During this testing there will be no limitation in the availability of professionals with experience. A neurologist will be on duty at the Virgen del Rocío University Hospital at all times, and these cases will be treated with maximum priority. Furthermore, within the framework of the healthcare process, some clinical and organizational protocols have been changed in order to minimize the response times for directly forwarding the patient to the Radiology Service. All details about the modification of these performance protocols in the Reference Hospital and in EPES will be part of a follow-on paper. Finally, regarding the technological limitations, phone coverage in certain locations of the city is still waiting to be solved, even though the platform offers mechanisms to resend all the information once the connection has been restored.

In this project, we focused on several limitations that we had to deal with in order to carry out the process. The main limitations were related to technological aspects associated with the mobile environment. On the one hand, we had to consider facts about network coverage and the proper technology in the tablet PC in order to be able to be used in an emergency situation. We have faced these limitations by making several network coverage tests in the entire metropolitan area of Seville.Furthermore, we acquired some Panasonic Toughbook H2 rugged tablet PCs, which offer resistance, are and water repellant and suitable for a proper clinical use.

On the other hand, we had to adapt the mobile unit to the context in this project in order to allow the videoconference to be done correctly and to adapt the analytic devices to the space in the mobile unit. Therefore, we ensured that proper multimedia devices were owned to make the videoconference. Among others, a fixed camera was installed to give for allowing a wider field of vision and a provider was asked to provide analytic devices that were appropriate for the space in the mobile unit. For the implementation phase of this investigation project two mobile units were equipped with trained personnel.

The technological solution presented in this article is oriented to the EPES emergency environment in Andalusia and is currently is not prepared to be expanded to other fields. Nevertheless, the solution that we are proposing in this article, and using the experience acquired during previous projects, will be the base that could allow the development of a generic solution to achieve a certain end. In this regard, we have now approved a new investigation project the main purpose of which is the development of a modular technological package that can be adapted to different healthcare systems, starting with the Spanish National Healthcare System (SNS). This platform will be re-used in other areas in which tele-assistance could be necessary, and a plan will be designed in order to transfer the results to the SNS and the market in general, establishing a framework for intellectual property rights. The platform will be able to coordinate the clinical attention for ictus cases in acute phase in different environments, counting on the real-time clinical advice of specialists in neurology, neuroscience, and ICM (Intensive Care Medicine), in order to provide a proper service in terms of patient safety, fairness of access to the service, and optimization in the use of health resources.This will be part of the work of our investigation team, whose results will be published.

Finally, this task set was possible due to a multidisciplinary team, making possible the performance of several complementary tasks, strictly related to research groups. It is determined that the current system and methodology can be applied and subsequently be expanded to other healthcare facilities.