Project - Design a Hospital Management system

worldwide network of Internet Of Things (IOT) is going to be the future network, which connects objects of different application fields, functionality and technology. These objects are uniquely addressable and use standard communication protocol and communicate in a heterogeneous networking environment. Anytime, anyplace connecting anything idea brought out significant advancements in the healthcare domain. This paper discusses with the implemented real world scenario of smart autonomous hospital management with the IOT. This paper aims at explaining in detail the technology drivers behind the IOT and health care with the information on data modeling of medical devices, data validation of critical incident data, data mapping of existing IOT data into different other associated system data, workflow or the process flow behind the technical operations of the remote device coordination, the architecture of network, middleware, databases, application services. The challenges and the associated solution in this field is discussed with the use case.

of Healh care devices makes the clinical research, laboratory management and hospital management as smart and autonomous. It is different from that of human entering values into the system. Fully automated, electronic medical records by the standardized health care Internet Of Things (IOT) in the closed loop technical delivery system enables the “Digital Hospital”. Machine to Human, Machine to Machine, Machine to Coordinating system or network are the channels for the information flow. This indeed leads to a technical paradigm needs a revisit and fine tuning in the data modeling, data sharing by data mapping with different systems, business process workflows with proper data privileges. The need for unified communication through proper backbone network structures makes the system robust. Context aware medical applications need coordination of multiple types of audio, video, discrete or analog data from multiple medical devices[1]. The entire medical IOT platform needs to be built on Service Oriented Architecture (SOA) with the well defined middleware, back end database, business process configuration feasibility, data modeling, mapping, data aggregation

The selection of data model defines whether the data is structured or unstructured, based on that the technology component of database back end is to be decided. The process flow or the workflow of the automated system is based on the event data and the preprocessing required to validate, cleanse and map the data. The architecture is nothing but the map of application framework with the infrastructure selected. The thread in the processing, infrastructure selection is the data model[7]. That too, in an automated processing system triggered by events from the IOT devices, the data model plays a major role. Even the network integration is based on the data exchange format. Some of the researchers are focusing on the infrastructure integration, some spotlights on the process automation, some give attention to the application framework. But, the very few are concentrating on the data model and linking the thread of data across the design. But , the smart hospital management system revolves around the meaningful use of data from IOT devices.

I.              SCOPE OF THIS WORK

This work focuses on the four main aspects such as data models, architecture, workflows – process flows, database decisions of the smart hospital management system enabled with IOT medical devices.

1. Medical Devices Counted

All the IOT medical devices can be categorized into medication monitoring, vital sign monitoring, activity monitoring, safety sign monitoring, patient identity and laboratory monitoring. Among them, this work focuses only on the Vital Sign Monitoring.

1. Basic Assumptions

For the initial study the remote patient monitoring of vital signs is alone considered. For the external system coordination, the insurance and disease diagnosis systems are considered. In case of the workflows, alert on critical incident alone considered as a use case. Regarding the device management, the battery and energy tracking issues are considered.

1. Infrastructure Consideration

Design only takes into account the Service Oriented Architecture. In case of network, Wired, Wireless, World Wide Web communication infrastructures are considered. The NOSQL database of unstructured database is considered rather the cloud database. Own server space for middle tier services, databases and applications are considered rather the cloud based deployment.

1. Smart data objects

The introduction of smart objects produces the new data objects. The question is how to sync the well established health care and clinical databases, hospital information systems with the data from the device events[8]. There are standards in data communication to the existing medical databases. So, there is a need for data transformation, data mapping to communicate the data to the external system.

Typical smart data modeling in the smart hospital management system is as follows:

TABLE I: GENERALISED SMART DATA OBJECTS

The patient and doctor associated, the lab reports, drug chart, intake chart, medication list are parts of the medical record of the patient. It is stored in the Hospital Information System.

The smart objects read and transmit in the form of OP_CODE, LED display value of 10-16 binary digit values. In the device access layer, gateway collects data and aggregate it to make the application specific value[9]. Data model considers only the application specific data, but not the device data. The data model is the generic one in which there are device definitions, device readings and the patient – device mapping details are available. Each field in the data model of table 1 has a specific implication which is described in table 2.

TABLE II:                 SMART OBJECT DATA FIELD IMPLICATIONS

The critical health measure devices considered are pulseoximeter which sense and reports the oxygen saturation level in the blood, blood pressure detector to access the blood pressure, temperature sensor for reading the body temperature, ECG sensor to report the electrical and muscular functions of the heart, glucometer to measure the blood glucose level, airflow sensor for detecting the breathing pattern.

Here, the resource or device is registered with the application service, then by application discovery, RESTFUL API, Asynchronous notification the event data are communicated to the smart hospital management system[10]. The collected raw data can be regarded as zero level data. The application specific aggregated data can be regarded as first level data. The data is getting cleansed, validated, filtered and then analyzed with the rules and conditions configured by the specific hospital system while the data is getting associated with the system as in fig 1. Most of the data collected from the millions of IOT devices are not exploited fully with the prediction and analysis as the data generated is huge and need BIG DATA analytics to process the data 

different medical devices data coordination, real time and batch medical analytics algorithms and security measures. The technology drives behind this new paradigm given way for new avenues in software development.

I.            ABRIDGED SURVEY

Verizon provides the realistic healthcare record with the biometric values that are tracked from the wireless devices. It helps to monitor the patient healthcare at the home. Philip’s “eICU” medical suit helps the centralized staff of nurses and doctors to monitor the intensive care unit patient’s vital signs. QUALCOMM developed a cloud based medical platform 2nd Platform, which communicates the data to the other devices and interoperable with the HIPPA complaint systems[2]. Smart Pump Programming has the additional details of drug library and dosage diagnosis. Here the integration of Electronic Health Record details is flowing into the smart pump applications. The prescription values of auto documentation with the event impact data get back from the smart pump program into the hospital management system. Cisco proposes an architectural framework for the IOT enabled eHealthcare[3]. Lei Yu proposes an architecture framework with the business and application service details of middleware.

Mervat Abu-Elkheir came out with the IOT data management proposals with the primitives of design. David Lake proposes an architectural frame work Proactive Personal “eHealth”, self-management of health conditions with the security at each layer of the architecture. Authentication strategies and privacy policies and communication patterns are discussed as part of this work[4]. They have compared the proposed work with the existing architecture[3,4]. Kashif Habib and Arild Torjusen propose the communication framework for eHealthCare Operations with the encryption, security certification[3,4]. Alexandre Santosa proposes M- Health , mobile based security architecture for the connected devices[5]. It is the work on mobile based integration of devices with the health care system. Omar Said contributed device based healthcare architecture with the communication states[6].

The patient and doctor associated, the lab reports, drug chart, intake chart, medication list are parts of the medical record of the patient. It is stored in the Hospital Information System.

The smart objects read and transmit in the form of OP_CODE, LED display value of 10-16 binary digit values. In the device access layer, gateway collects data and aggregate it to make the application specific value[9]. Data model considers only the application specific data, but not the device data. The data model is the generic one in which there are device definitions, device readings and the patient – device mapping details are available. Each field in the data model of table 1 has a specific implication which is described in table 2.

TABLE II:                 SMART OBJECT DATA FIELD IMPLICATIONS

The critical health measure devices considered are pulseoximeter which sense and reports the oxygen saturation level in the blood, blood pressure detector to access the blood pressure, temperature sensor for reading the body temperature, ECG sensor to report the electrical and muscular functions of the heart, glucometer to measure the blood glucose level, airflow sensor for detecting the breathing pattern.

Here, the resource or device is registered with the application service, then by application discovery, RESTFUL API, Asynchronous notification the event data are communicated to the smart hospital management system[10]. The collected raw data can be regarded as zero level data. The application specific aggregated data can be regarded as first level data. The data is getting cleansed, validated, filtered and then analyzed with the rules and conditions configured by the specific hospital system while the data is getting associated with the system as in fig 1. Most of the data collected from the millions of IOT devices are not exploited fully with the prediction and analysis as the data generated is huge and need BIG DATA analytics to process the data.

I.            INTEROPERABILITY

There are medical thesaurus available to recognize the disease from the symptoms of the patients. cinicaldiagnosis.com, medicaldictionary.com are some of the diagnosis online services which diagnose the diseases from the reported clinical data of the patient. But, this diagnosis, suggestions need the practitioner's approval before the treatment. If the medical practitioner confirms the diagnosis of the diseases as a clinical disease, it needs an entry into the county, state wise medical information system. So that when the state authority makes the query of “How many cancer patients are there in the county?”, the count will be correct if from all the registered hospitals the data are getting automatically, timely updated in the health care systems.

The TPA (Third Party Agent) is responsible for the patient health insurance claims. The patients have the claim based on the policy and the diagnosis. Initially, based on the patient disease diagnosis, the accounts department of the hospital sends an estimated bill amount of hospital charges to the TPA for the claim. If the TPA approves the cost, the patient is not charged for that treatment and the amount is paid by the agent[12].

In the above use cases of external system coordination, the event from the IOT devices or the aggregator device can directly trigger an automated operation of integration with the diagnosis thesaurus or the insurance system. In the first case the data from IOT are to adhere to the Continuity Care Document medical record standard. The strategies that governs data normalization automatically map local content to terminology standards and translate data between standards are required to eliminate the ambiguity of meaning in clinical data. Clinical data vendors and health care information systems follow the standard like SNOMED CT. The second use case of healthcare transactions should adhere to the HIPPA. So, there are data mapping, data validation for external system integrations as in fig 2 In the healthcare, interoperability is the ability of different information technology systems and software applications to communicate, exchange data and use the information that has been exchanged.

involves the standardizing of the medical record structure, business rules to map to the destination information

system record structure without losing the meaning. The HL7 standard suggests, the XML data format for the Electronic Health Care((EHC) Record., The following Algorithm 1 is the algorithm for data processing in IOT enabled health care applications.

Algorithm 1 : Structural Decomposition and Data Validation of Data Remanence from IOT Medical Devices

Input:IOT_MED: Devi={ IOT_MED_Reading, Patient},i=1..n

For Every event of the Device (Devi) € IOT_MED Do Begin

Authenticate Device CreateDatabaseconnection(con) InsertSmartDataObject(Devi) ExecuteQuery(con)

If Devi Triggers Transmission Then

CreateRootNode(Devi)

Refer Device Definition, Business Rule from Database(con) Add SmartDataObjectTag in EXI XML()

Get Attribute() and AttributeValue()

Create EXIXML ChildNode for all attributes() Create EHC Record in EXIXML format() Normalize the EHC Record() as per standard(con)

Validate Data for Device(Min, Max Range) from DB(con) Check for Datatype, Dataformat, Correcttimestamp, SemanticAnnotation, from Device Standards Described in DB(con)

If Check or Validation fails Then

Follow the Fallback Action as per workflow configuration

EndIf

Process the EHC Record (Message Composition, Content Categorization, Message Filtering, Data Aggreation,Parsing ) Analyze the EHC Record for Prediction Model, Pattern Definition, Frequency Tracking

On the Fly Data Transformation(Source,Target) using Business Rules in DB(con)

Repackage EHC Record into Target Data Model() Identify Network connection

Transmit EHC Record in the Protocol transmission format

End

I.                VALIDATIONS

There are multiple types of tests are conducted by the standard bodies like FDA. Safe Medical Device mission considers the security of the data as well the safety of the patient from the radiation. Process validation confirms whether the device events are as per the predefined procedure. Design validation checks whether the device operation satisfies the user need. Data verification confirms the data is within the range and as per the data format and data is of recent one not the old recording which is called the residual data of the instrument[13]. Association of Advanced Medical Instrumentation (AAMI.org) brought out the standards for the data as per the application specification, data validation rules for different IOT enabled medical devices as shown I fig 3. The validation is required at the machine level data as well.

The retention time, peak asymmetry, signal to noise ratio, resolution between two identified peaks, the response time are to be validated in a scheduled time of the life cycle to confirm the accuracy. The device level tests confirm the basic performance of the device where as application level tests confirms the business meaning of the data for decision support, interoperability, network capability tests are for confirming the secured communication without losing value.The user experience tests focus on easy work flows, clear instructions, meaningful help messages and pleasant simple user interfaces.

I.                            WORKFLOWS

Usually, the system classifies the data as level1, level2, level3 (where the level1 – simple entry or sensed data

• the raw data, level2 – classified and categorized data, level3
• inferences, statistics, counts). So, the data model also should have the layers with the unification is aimed at. In an implementation scenario, we have to create our own channel and define the fields of data communication from the channel. Define the data set as per definition and upload the data, see it in the required format.we can set the react apps when the reading of a field (a defined condition) value is so and so. The reaction could be the custom HTTP POST or GET. We can define the web services that should be called on so called condition and be published, the reaction could call that and showcase whatever necessary. On the ThinkSpeak IOT platform a simple ECG recording has been plotted from real time channel of predefined pseudo values in fig 4. The XML for interchange used are the advanced Efficient XML format.

TABLE III. CHANNEL DEFINITION IN THINKSPEAK

{"channel":{"id":39354,"name":"Channel 39354","description":"ECG recorder","latitude":"123.0","longitude":"123.0","field1 ":"ecgdata","created_at":"2015-05- 25T11:42:45Z","updated_at":"2015-05-

25T11:51:45Z","elevation":"34","last_entry_id":2},"fee ds":[{"created_at":"2015-05- 25T11:42:45Z","entry_id":1,"field1":"500"},{"created_ at":"2015-05-

25T11:45:45Z","entry_id":2,"field1":"450"}

RTI is a Java based IOT platform in which there is a health care relevant server where the ECG, pulse data is generated which we can receive by connecting to the server and set alarm on out of range values.In case of the bed side monitoring or on the critical care, the range of data generates the event which is captured in fig 5 . The event triggers the call of alarm services configured as per the workflow. For example, the alarm should be sent only to the “Critical Care” service subscribed doctors of the unit and not to all. If the alarm action is not taken, the hospital management system, should have the escalation matrix as part of the work flow[14]. In the hospital management system, the event driven process flow is explained in the following Figure 7 with the event- value.

I.             ARCHITECTURE

The architecture is the logical application framework. Whereas, the infrastructure is the technological component chosen for the architectural description. The devices usually of 3 main classes, minimum device of 8 bit system with the on chip controller and without embedded devices. Mid level devices have the very limited 32 bit architecture, but with the embedded operating system.Most capable devices have the fully capable 64 bit architecture running on a full operating system like Linux. In case of the connectivity, there are numerous connectivity options like LAN or WAN connection with the TCP/UDP connectivity. Zigbee or Mesh radio network, UART serial lines, low power Bluetooth connections, point to point wired links, mobile-network, IPV6 with virtual IPs, WIFI connection are some of the possible connections in the Body Area Network of the HealthCare domain[15]. The data interchange format could be the XML or JSON. TinyDB, Cougar, SINA, Dsware, MILAN, Mires are some of the database options for storing the internal data. The middleware and application services could be event triggered, application driven or service oriented. The communication protocol options vary from IEEE 802.15.4e (standardized for Medical Body Area Network), BTLE, 2G-3G, LTE, Zigbee protocol to CoAP. The application services could be device observation services, web notification services, sensor or actuator alert services.