Introduction

Brazil is a country of continental dimensions with widespread regional and social inequalities [1]. The Unified Health System (called SUS) was created to achieve the universal health care in Brazil. It increased the access for a substantial proportion of the Brazilian population, improving the decentralization process, social participation, and growing public awareness of a right to health care [1].

Bahia is the 5th-largest Brazilian state by area and the 4th-largest by population. With a total area of 565.733 km2 and 15.126.371 people residing, it presents 417 municipalities that comprised 4.1% (U$ 18.6 billion) of the Brazilian economic activity in 2014 [2]. However, despite of financial results and per capita values, Bahia follows Brazil in regional and social inequalities, offering insufficient health care and telehealth services in remote regions.

According to CFM [3], 56.73% of the health care professionals are associated to Salvador Metropolitan Region (SMR) which contains 19.19% of the Bahia population [2]. Moreover, 53.2% of Bahia hospital beds and 70% of Intensive Therapy Unit (ITU) beds available by SUS are concentrated at Salvador capital [4], and 57.22% of the state budget on health was applied in hospital and ambulatory care [5]. As a result, except for SMR, most of Bahia regions do not have sufficient resources to improve and decentralize the population access to a high-quality health care service.

This paper presents CloudMedic, an e-Health Cloud [6] solution that manages health care services in remote regions of Bahia state. To this end, section 2 presents the motivations behind the CloudMedic project. Section 3 describes the applied methodology in order to provide an e-Health Cloud. Section 4 presents the CloudMedic obtained results. Finally, section 5 presents the conclusions and future work of this project.

Motivations

The complexity of Health Information Technology (HIT) systems has evolved during the years [7], from the advancements in technology such as databases and fault tolerance systems to the recently emerging Cloud Computing (CC) systems [6, 8]. CC refers to an on-demand, self-service Internet infrastructure that enables the user to access computing resources anytime from anywhere [9]. It is an important technology able to improve the interoperability for shared health care information [10], to solve the significant communication problem among health care departments in e-health solutions [11], and to provide efficient and reliable solutions in order to support health care services.

In contrast with these technology issues and advances, most of HIT systems at Bahia are expensive and not integrated (or not able) to support the current demand of new interactive [12] and proactive [13] health services. As a result, they can be classified as legacy systems evolved in old software technologies by big players or incomplete systems developed by small municipality companies.

Considering remote regions at Bahia state, low budgets, reduced workforce, network limitations and deployment costs are some situations that must be addressed by HIT companies. In fact, due to network limitations and reduced workforce, small companies could not offer a high quality and low cost technical support. Deployment costs and expensive payments necessary to legacy support of big players are other problems for the low budgets found in most of Bahia municipalities.

Rede Cegonha is a health care program promoted by Brazilian government that systematizes and institutionalizes a childbirth care model that guarantees to women and children a humanized and quality care [14]. Since 2013, Centro Médico dos Remédios (CMR) [15] and VitaLab [16] work together with Rede Cegonha in selected regions of Bahia state. They are private health companies that promote popular and low-cost health care services at 118 municipalities in Bahia state (Fig. 1).

Fig. 1
figure 1

Bahia municipalities covered by VitaLab, CMR and selected regions of Rede Cegonha

Full size image

CloudMedic was started by CMR and VitaLab due to problems and limitations found at legacy and incomplete HIT systems operated by them. Rede Cegonha was another motivation, which could not be supported by their current HIT systems in a technical and low-cost perspective. The idea was to apply more than 21 years of CMR and VitaLab health service knowledge in a new HIT platform based on CC resources that integrate and complete the functionality offered by their current HIT systems.

Methodology

Despite the computerization of processes in health care be clearly lagging behind other areas of knowledge [17], HIT has the potential to enable a dramatic transformation in the delivery of health care, making it safer, more effective, and more efficient [18]. The HIT usage also provides high levels of ambulatory Electronic Health Record (EHR) adoption and suggest an extra effort to the needed of interoperable EHRs in the future [19].

According to Moura, Leão and Lira [20], HIT production demands five main health areas that must be covered: 1) management of patient flow; 2) health facilities management; 3) EHR; 4) connection among actors of health activity; and 5) strategic and integrated management of health services. CloudMedic cover these areas through six main modules: Clinic, Hospital, Supply, Administrative, Billing and Health Business Intelligence (BI) (Fig. 2). They are responsible to manage clinical specialties, doctor appointments, vaccination tracking, surgery packages, financial accounting, maintenance and contracts, diet ordering, lab exams, EHR interoperability, etc. (Fig. 2). In other words, they control the health flow among health actors at health departments in an integrated way.

Fig. 2
figure 2

CloudMedic modules and submodules

Full size image

Different types of actors with their respective health activities can use CloudMedic modules and submodules. For access grants, they are divided in different groups and roles, such as: manager, attendant, supervisors, etc., according to their competences in their respective modules. Figure 3 illustrates some types of these health actors and related inheritance based on defined groups and roles.

Fig. 3
figure 3

Types of health actors for CloudMedic functionalities

Full size image

Health actors handle important resources in HIT systems, and different types of health requirements are covered by HIT solutions. However, government rules and the complexity of HIT systems are evolving during the years, bringing new demands in meeting volatile requirements derived from health care policy [21]. In this sense, it is important to develop HIT solutions with implementation structures able to support the dynamic demand of volatile requirements provided by the health domain.

SimplesMedic was an initial attempt to identify, integrate and validate these volatile requirements in CMR and VitaLab institutions. It was a multi-tenancy HIT system that initially defined business rules for Clinic, Administrative and Billing modules applied at CMR and VitaLab institutions. CloudMedic extended SimplesMedic requirements for Hospital, Supply and Health BI modules. It also provided an implementation structure able to dynamically configure health functionalities derived from health domain.

Important assets were defined by SimplesMedic, such as: database and procedures for health business rules, standard gateway for data maintenance, and a standard approach for parameter passing between web view and database layer. They were extended by CloudMedic with a dynamic multi-front-end framework based on SmartGWT [22] and GWTBootstrap [23], a database that configures web views for new health functionalities, and a hardware structure able to support CC demands. Figure 4 illustrates a general view of the CloudMedic architecture including reused resources from SimplesMedic.

Fig. 4
figure 4

General view of the CloudMedic architecture

Full size image

Figure 5 also illustrates the deployed structure to support CloudMedic demands. It describes 3 Dell Power Edge R730 servers, 1 Dell PowerVault MD1220 storage, 2 Cisco 1900 routers, 1 Cisco SG 300-10SPF media switch and 1 Mikrotik 1100 Ah Routerboard. The database server image is allocated to the “Dell PowerVault MD1220” storage, as well as the images from the application servers. The physical servers "Dell R730g - VM Ware ESXI A" and "Dell R730g - VM Ware ESXI B" have the function of virtualizing the images contained in the storage, where each server is a mirror of the other as a guarantee of fault tolerance. The “Dell R730G - Veeam backup” server runs a proprietary backup application for the images contained within the storage, keeping copies on your disks and continuously sending copies of the data to Google Drive. The application backs up all virtual machines within 30 min and sends them to Google Drive with an interval of 2 h. External connections to the cloud are established via the Internet by OpenVPN [24]. The routerboard “Mikrotik 1100AH” works as an authentication OVPN server, which has an OVPN account for each client that needs to connect. To authenticate and join the VPN, the client needs a trusted digital certificate from the server in addition to its access credentials. For each connection, an encrypted tunnel and a specific route is created via BF128-CBC / MD5 method. CloudMedic makes use of two distinct Internet providers, where in case the main one fails the secondary takes over, making available a total of 200MBp/s. Uploads to Google Drive are made through a third 100MBp/s unique link for this purpose. If this link fails, the secondary access to the CC assumes the sending of backups.

Fig. 5
figure 5

Deployed structure to support CloudMedic demands

Full size image

Considering the production of new health functionalities, CloudMedic configurations can be performed by: 1) the creation of database models and routines in the business level; and 2) the configuration of web views and web commands in the multi-front-end framework. The production of database resources follows the SimplesMedic design approach, since most of its database models and routines were reused. It is based on relational tables with id records as primary keys accessed by stored procedures that fetch data and perform CRUD operations filtered by idUser and idOperation (‘I’-Insert, ‘U’-Update, ‘D’-Delete) references.

The configuration of web views is defined by the inclusion of Window, Grid, Action, Report, Form, Fields, ListGridFields and QueryGridFields (Fig. 6) records. They are able to represent user interfaces for health actors, showing lists of EHR, patient forms, financial reports, and so on. Web commands are defined by FormCommands, GridCommands and GridCommandsToRedirect (Fig. 6) values, which represent buttons and links that redirect current values of web views to other created web views. They also indicate which values will be passed or not to the database layer for CRUD operations or to call external web services.

Fig. 6
figure 6

Database model for multi-front-end configurations

Full size image

Web view and web command configurations define together flows of health information according to health domain requirements. Each set of defined configurations provides new health functionalities based on modeled and reused database structures. The multi-front-end framework also reflect in real-time each web view or web command configuration, bringing dynamic updates in CloudMedic interface for each defined functionality.

As a configuration example, Fig. 7 shows the multi-front-end web view that configures Field values via Fields Form interface. This Form is activated by the Field Update web command recorded in the GridCommand table, which is associated to a Grid record that represents the Fields Maintenance list. This GridCommand record was defined to get selected values in the Grid and fetch data to be showed in the associated Form. It also executes the configured CRUD operation after user confirmation (the Ok button in the Form), sending the Form data to be updated by a stored procedure in the database layer.

Fig. 7
figure 7

SmartGWT and GWTBootstrap interfaces to update Field values

Full size image

Results

CloudMedic objective to provide an e-Health Cloud platform started officially in 2012 by SimplesMedic project (Fig. 8). It was an initial effort to develop an integrated and multi-tenancy HIT system that unify CMR and Vitalab experience in health care service. SimplesMedic was released in 2013, working with basic functionalities of Clinic, Administrative and Billing modules in one CMR health institution (CMR Aurora).

Fig. 8
figure 8

SimplesMedic login and main window

Full size image

As SimplesMedic requirements evolved during the time, they were extended to CloudMedic project, which was started in 2014 and is being worked on so far. During this years, 735 Forms, 103 Commands, 520 Grids, 485 reports, 546 tables, 1182 stored procedures, and other important resources in both projects, were developed, tested and deployed by approximately 7 developers. Together, they developed most of Clinic, Hospital, Supply, Administrative, Billing and Health BI functionalities necessary for a complete CMR, Vitalab and Rede Cegonha operation.

The deployed structure (Fig. 5) to support CloudMedic usage was tested by SimplesMedic and CloudMedic demands. It is currently in use by 2042 health actors divided in 62 combinations of groups and roles, generating for the Tomcat server 1k HTTP requests/min at average (6k requests/min at max.) (Fig. 9) in a monthly volume of 2.19 Mb In and 1.32 Mb Out at average (25.10 Mb In and 22.20 Mb Out at max.) per second (Fig. 10). As a result, an optimized volume of transmitted data has been used to support a considerable number of HTTP requests from health actors allocated at different service stations, departments and health care facilities.

Fig. 9
figure 9

Tomcat server results using the CloudMedic structure

Full size image
Fig. 10
figure 10

Data transmission results using the CloudMedic structure

Full size image

Health actors are also distributed in 261 health posts that cover health demands from 33 central and 85 remote municipalities at Bahia state (Fig. 11). This structure also manages more than 3.5 million financial records derived from 2,393,999 health service orders and 13,594,992 health exams, which are related to 1,386,336 patients including imported records from previous HIT system (Table 1).

Fig. 11
figure 11

Partial list of connections from CloudMedic health posts

Full size image
Table 1 Partial list of CloudMedic tables with maximum number of rows
Full size table

Considering the front-end interface, SimplesMedic migration to the multi-front-end CloudMedic is yet in progress. It is the final step to consolidate CloudMedic as a dynamic and configurable e-Health Cloud platform for health domain. As current state, important functionalities of Clinic, Administrative and Hospital modules were transferred to CloudMedic and are now in homologation process. Figure 12 illustrates a result example of this migration process, showing the current SimplesMedic and the new CloudMedic version (GWTBootstrap skin) of the health service order registration functionality.

Fig. 12
figure 12

Migration result of the health service order registration functionality

Full size image

Conclusions

This paper presented CloudMedic, an e-Health Cloud solution that manages health care services in remote regions at Bahia state. It is a dynamic and configurable solution in a CC infrastructure that improved and decentralized the access to health care services despite remote municipality limitations.

As current status, CloudMedic presents an interesting collection of health functionalities distributed in six main modules used by 62 types of health actors. It allows a complete CMR and VitaLab operation over approximately 2.4 million health service orders provided by more than 28% of Bahia municipalities since 2013. It also consolidates Rede Cegonha program, showing the viability to improve health services in remote regions against their limitations by the application of technological advances.

However, despite these positive results, CloudMedic is not yet sufficiently scalable for new customers due to CMR and VitaLab particularities applied in the project. It is a direct consequence of the high variability found during the development of health domain solutions, something possibly stable in legacy HIT of big players. Thus, CloudMedic should be yet defined as a “private solution able to be customized” instead of a COTS [21] health platform, being necessary an extra effort to become “highly configurable” for new customers.

As future work, it is important to become CloudMedic more configurable for new customers in order to achieve the status of e-Health Cluster at Bahia state. Configuration of SUS functionalities will extend CloudMedic usage by public institutions and health entities towards a public e-Health Cloud platform. The continuous multi-front-end adaptation to recent web technologies is important to guarantee the support of web view and web command configurations against technological front-end advances. Finally, the support to DICOM [25] images by a CloudMedic PACS [26] will improve to another level the telehealth diagnoses in remote regions of Bahia state.