You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Sustainability
Download PDF
  • Article
  • Open Access

8 February 2022

A-SHIP: Ontology-Based Adaptive Sustainable Healthcare Insurance Policy

,
,
,
,
and
1
College of Information Technology, United Arab Emirates University, Al-Ain P.O. Box 15551, United Arab Emirates
2
Laboratoire Génie de Production, Ecole Nationale d’Ingénieurs de Tarbes, 65000 Tarbes, France
3
Laboratory of Technology and Smart Systems (LT2S), Digital Research Center of Sfax, Sfax 3021, Tunisia
*
Author to whom correspondence should be addressed.
Sustainability2022, 14(3), 1917;https://doi.org/10.3390/su14031917
This article belongs to the Special Issue Digital Technology in Healthcare: Opportunities Offered by a Sustainable Relational Ecosystem
Version Notes
Order Reprints

Abstract

Healthcare has a significant impact on human capital anywhere. Countries usually allocate financial resources to manage healthcare, which might impose a substantial financial burden on the scope of healthcare coverage. Thus, the healthcare sector must provide the best possible services at the lowest cost. This significant challenge can only be achieved through applying appropriate policies and technologies, including those used by healthcare insurance policy providers. This paper proposes an innovative, customer-centric, sustainable healthcare insurance policy model. The main objective of this model is to sustain wellness by applying technologies to avoid illness and provide wellbeing for patients by empowering self-care remotely. The proposed solution uses an adaptive ontology-based knowledge management system to satisfy customers and market needs. The proposed system creates a customized policy that consists of various packages to match customers’ healthcare needs based on their health status. The system was tested and validated using a real dataset.

1. Introduction

The World Health Organization (WHO) is devoted to establishing wellness, based on science, for people around the world [1], and this goal requires an effective application of sustainable, smart healthcare systems, providing quality healthcare services to enhance health and wellness [2]. On the other hand, the gross domestic product (GDP) of healthcare is exacerbated worldwide. A World Bank report shows that the total health expenditure GDP percentage has risen from 8.6% in 2000 to almost 10% in 2016 [3]. According to statista.com (accessed on 26 April 2021), the statistics for US national health expenditure, as a percentage of GDP, increased from 13.3% in 2000 to 18% in 2020 [4]. Furthermore, patients’ expectations for healthcare services have been growing because of recent advances in technology. It is envisioned that doctors in the near future will prescribe monitoring devices and facilities, in addition to drugs, for the purpose of enhancing the health and wellness of their patients.
In the US, healthcare insurance premiums are assigned using financial aspects only, ignoring other important factors, such as customer health, medical history, and gender [5]. This traditional business model lacks several aspects to better support patients’ and healthcare providers’ expectations. Thus, a new adaptive and technologically supported system is needed. Smart healthcare is defined as a “health services system that includes wearable devices, IoT, Mobile Internet, big data, and AI to access relevant healthcare data dynamically and actively manage and respond to medical ecosystem needs intelligently [6]”. It aims to make healthcare more efficient, affordable, sustainable, and personalized. The WHO defines a sustainable healthcare system as a “system that improves, maintains or restores health, while minimizing negative impacts on the environment and leveraging opportunities to restore and improve it, to the benefit of the health and wellbeing of current and future generations” [1].
For sustainable, smart healthcare solutions to be effectively applied, computational means, such as ontology-based approaches, are needed. This section discusses research based on current healthcare insurance business models and sustainable smart healthcare ontology systems.
The existing healthcare insurance business model is financial-centric, providing insurance policies with different specifications and prices, based on customer income [7,8]. For example, Table 1 presents the different commercial health insurance business plans in the United States [5]. The process for most applied policies includes sending a claim by the service provider to the insurance company, based on the applied policy, for it to be either endorsed or rejected [9]. On the other hand, the main revenue stream for an insurance company is the return on investment from interest-generating assets [10]. The existing healthcare business model shares the cost of healthcare services and ignores health enhancements. As a financial-centric model, it focuses on financial factors only, by providing short-term plans, while ignoring the main purpose of healthcare services, which is to enhance customer wellness. Indeed, this business model can cause financial ruin for either the customer or the insurance company.
Table 1. Health insurance plan description.
Recently, work has been done in smart healthcare ontology-based systems. However, work on ontology-based insurance policy systems is limited. Sharma et al. [11] proposed an ontology-based IoT framework for monitoring COVID-19 patients remotely. The main purpose of this system is to control the spread of a virus by providing information about COVID-19 and suspected infected patients. The framework used 1D biomedical signals, such as ECG, PPG, and temperature, which includes an ontology, built by the doctor, to enhance the decision-making process. Chen et al. [12] proposed an ontology-based model for diagnosing and treating diabetes patients. The main purpose of this model is to provide a detailed analysis of data about diabetic patients by combining different kinds of disease-related knowledge. The proposed ontology includes top-level ontologies, Basic Formal Ontology (BFO) and Ontology for General Medical Science (OGMS), middle-level ontologies, Human Disease Ontology (Diseases), RxNorm Ontology (Drugs), Symptom Ontology (Symptom), Current Procedural Terminology (CPT), Gene Ontology (gene), Physical Activity Ontology, Diet Ontology and Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT). The ontology was built in Protégé and applied SWRL for reasoning.
Shen et al. [13] proposed a clinical support system as first-line therapy for diagnosing infections and prescribing an appropriate antibiotic. The reasoning process depends on data entered by the patient, including body temperature, symptoms, complications, antibacterial spectrum, contraindications, and drug–drug interactions. This proposed infection ontology was considered a complete ontology, as compared to other existing ones at the time. Applying Internet of Things (IoT) technology-based devices and protocols in data collection can enhance the quality of collected data and the accuracy of results. Hristoskova et al. [14] proposed an IoT-based ontology system to monitor the real-time data of congestive heart failure patients only. In emergency cases, the system alerts the specialized physician, while considering the physician’s location. However, the approach was validated on a medical emergency scenario and was limited to congestive heart failure patients. Abbas et al. [15] proposed an ontology-based system that recommended a suitable insurance plan based on users’ data entries. The user enters the required information and the system applies an XML retrieval approach to recommend the best policy. The system considers the policy price, the policy coverage, and benefits, while selecting the customer policy and using market standard policies.
Smart healthcare architecture is essential for understanding healthcare requirements and the system’s overall operation. Sahi et al. [16] proposed a three-layer, smart healthcare architecture that includes a wireless body area network (WBAN) for collecting patients’ data, including vital signs, a network layer, and a storage layer that includes servers. Mukhtar et al. [17] proposed a three-layer, smart healthcare architecture that includes the IoT for collecting patient data, communication medium, and cloud computing for analysis and storage purposes. Pham et al. [18] proposed a four-layer, cloud-based home environment architecture that includes a smart home environment, communication layer, remote caregiver station, and the cloud for data analysis and storage.
Bansal and Bani [19] proposed a three-layer, smart healthcare architecture that includes a body area network (BAN) to collect and relay patient data for processing and analysis. The processed data was finally dealt with in two ways, depending on the patient’s status. In an emergency, the data is sent to the doctor’s station; otherwise, it is sent to the cloud for storage purposes. Rahmani et al. [20] proposed a four-layer, smart healthcare architecture that includes the IoT, fog computing, cloud computing, and remote caregivers’ stations. The mentioned architectures lacked the holistic overview of a smart healthcare system architecture, as it focused on technology components and ignored smart healthcare partners.
This research is built upon in [21], which proposed a holistic, patient-centric, smart healthcare system architecture and aims to develop a sustainable adaptive healthcare insurance system that conveys rapid changes in smart healthcare and satisfies the market and customer requirements. The proposed system moves from being financial-centric to customer-centric by setting long-term plans and empowering them with new technologies, to sustain and enhance people’s wellness and improve the overall healthcare system. The proposed approach is ontology-based, which incorporates patients’ shared medical data, an ontology-based engine, and dynamically developed sustainable insurance policies. Being a customer-centric based system, it aims to reduce the cost of the insurance companies by automatically assigning insurance policies, according to customers’ health status, recorded in their electronic health records (EHRs). In addition, it supports treatments by applying technology as an option that contributes to enhancing patients’ health and wellness, prior to the medication stage. Some diseases can be treated by changing patients’ lifestyles and monitoring sickness indicators, using applicable technologies. A customer’s policy is a collection of packages, specified according to the customer’s health requirements. This approach satisfies the customer’s health requirements while adapting a proper insurance policy amount and enhancing the control of financial losses for the insurance companies. The proposed system repleads the use of doctors’ claims, and the policy is updated automatically based on changes to the customer’s health status and requirements. The focus is to be able to define the technical requirements when deriving policy packages.
Section 2 covers the material and methods for the sustainable, adaptive, smart healthcare insurance policy system. This section presents the overall architecture, and the development and implementation of the proposed Ontology-Based Adaptive Smart Healthcare Insurance Policy (A-SHIP) system is depicted. Section 3 presents the results. Finally, the paper is concluded with a discussion in Section 4.

2. Materials and Methods

The proposed sustainable smart healthcare architecture, Figure 1, includes different constituencies that aim at making healthcare efficient and affordable. Healthcare insurance companies utilize different technologies, such as IoT, mobile computing, cloud computing, fog/edge computing, and wearable devices, to retrieve patients’ data and track medical claims. This research aims to leverage emerging technologies to develop A-SHIP. Our previous work [21] proposed a smart healthcare insurance business model by applying the business model canvas technique [22]. We focus on the business model customer segment in A-SHIP to define a customized knowledge-based value proposition. There are three types of customer segments, namely, lifestyle management patients, self-management patients, assisted living patients. These are defined as follows:
Figure 1. Sustainable smart healthcare architecture.
  • A lifestyle management patient is a healthy and normal person. The American Society of Anesthesiologists (ASA) defines a normal healthy patient as a non-smoking person, with a BMI under 30, who exercises within the accepted practicing range [23]. This type of patient requires adjustment to their lifestyle when diagnosed with an interim disease to avoid worse medical situations.
  • A self-management patient is a person who is diagnosed with one or more chronic diseases and requires education to manage the illness and enhance their life quality [24].
  • An assisted living patient is an older person who needs real-time health and environmental monitoring [25,26].
A-SHIP assigns an insurance policy based on the patient’s electronic health record (EHR). The A-SHIP system is customer-centric, dynamically allocating a health insurance package that matches the customer’s current health status and requirements. Meanwhile, it optimizes the insurance company’s cost spending by eliminating unnecessary charges and duplications in diagnoses and treatments. In this case, the insurance company covers all customers’ health requirements while properly adapting a premium insurance amount. The policy is updated automatically according to the customer’s health status and doctor’s diagnosis. The policy package names and details are selected based on our assumptions for testing purposes. Some policy packages may include IoT devices and WBAN to monitor the patient’s status and update associated EHRs with any health issues. In case of a health status change, the policy package might change. The system applies ontology-based reasoning to assign a policy package. A website is also provided to validate ontology manipulations and prove the system’s intended concepts. Table 2 defines the main parameters that specify a patient’s policy.
Table 2. Insurance policy parameters.
The insurance policy in the proposed system is a customer-centric policy that is a collection of required insurance packages. To simplify the categorization of packages, they are grouped according to the patient’s segments, patient’s health status, and the patient’s need for support treatment, as follows (insurance policy can have one (or more) of the following packages):
  • Basic policy packages
    • Child basic policy;
    • Adult basic policy;
    • Elderly basic policy.
2.
Lifestyle management policy packages
  • Lifestyle management package.
3.
Self-management policy packages
  • Implant heart monitoring package;
  • Wearable heart monitoring package;
  • Implant vital signs package;
  • Wearable vital signs package;
  • Body area network (BAN) & Ambient Assisted Living package (AAL)
4.
Support treatment policy packages
  • Appointment management package
The policy packages defined in this work focus on technological requirements. Each package has details about the appropriate technical requirement according to the age and disease groups. The system assigns the basic policy package by default for all customers depending on the customer’s age (child basic policy, adult basic policy, and elderly basic policy). The basic policy covers ordinary cases that do not require continuous monitoring, such as seasonal diseases, regular vaccines, and necessary surgeries. Basic policies do not include technological requirements. Lifestyle management policy includes packages for customers who require follow-ups on their health status. In this case, a customer is healthy but diagnosed with an interim disease that can be treated with some adjustment and patient lifestyle changes. Lifestyle patients require a support treatment package to enhance their lifestyle and avoid further disease development. Self-management policy includes packages for customers with “unhealthy” health status. In this case, a customer is diagnosed with one or more chronic diseases that require more than six months of the treatment. Furthermore, it includes real-time health monitoring and environment parameters monitoring packages. To simplify the insurance policy assignment process, ages are grouped into a limited number of categories [27], as shown in Table 3.
Table 3. Age group categories.
Furthermore, diseases are classified based on the technological requirements needed to support disease treatment [28], ignoring any other medication requirement (out of this research scope). For example, the Heart monitoring group includes seven diseases that require a heart monitoring kit. The primary purpose of creating disease monitoring groups is to simplify the ontology expansion process in the future. This paper defines four groups covering thirteen diseases and uses the formal disease names listed in ICD ontology codes, Version 10 [29], as shown in Table 4.
Table 4. Disease monitoring classification.

2.1. A-SHIP Implementation Model

Figure 2 shows the A-SHIP implementation model. The implementation model consists of the healthcare cloud layer, network layer, context management layer, and application layer.
Figure 2. A-SHIP implementation model.
  • Healthcare Cloud Layer: the Healthcare insurance company, retrieves customers’ data from the shared database of the smart healthcare system hosted in the cloud as a component of the model. This system assumes that EHRs consist of all required data needed to determine the healthcare insurance policy. EHRs consist of basic patients’ details, health status, diagnosis, technological requirements, and other attributes.
  • Network Layer: provides all communication means between the different layers in the smart healthcare system.
  • Context Management Layer: consists of the following four main components: query engine, data retrieving engine, knowledge manager, and customer database. These components are discussed as follows:
    ○
    Query Management Engine is the middleware between the application layer and the data retrieving model. It receives the customer ID from the application layer and sends it to the data retrieving model requesting customer’s information, including all EHRs attributes. AJAX (Asynchronous JavaScript and XML) is a set of web development techniques on the client-side that enables the accessing of data from a server asynchronously without interfering with the web page.
    ○
    Knowledge Management Engine consists of the ontology-based context model and the reasoning engine for specifying the health insurance policy. SWRL (Semantic Web Rule Language) used to express the rules as logic in OWL web ontology language. Pellet reasoner was used to assure the ontology consistency and coherence [30,31,32].
    ○
    Customer Database is the insurance company data warehouse that consists of customers’ data and insurance policies details. It is the source for updating any patient’s healthcare insurance policy database stored in the cloud.
  • Application Layer: is a web-based application that implements the application user interface (API). It is based on HTML, JavaScript, jQuery, etc.

2.2. Ontology Engineering for A-SHIP

Ontology is a conceptual model for a specific domain and consists of classes, properties, and relations between classes. The class represents the concept, while properties represent the attributes of that concept [33]. Ontologies represent knowledge in a semantic and interoperable model that simplifies problem-solving and encourages knowledge reuse in various fields [34]. The ontology engineering process includes requirements collection based on specific competency questions, structural design, and implementation [35]. A-SHIP is an ontology-based system that facilitates the healthcare insurance domain as part of a smart healthcare system.
A-SHIP consists of insurance policy packages that consider technological requirements to enhance customers’ health and wellness. The proposed insurance policy is a customer-centric model which consists of packages depending on each customer’s parameters retrieved from their EHR. The healthcare insurance industry needs to adopt more robust and disruptive business models which embrace new emerging technologies [24]. Smart healthcare is now widely accepted, and there has been ongoing research and development in this area. Ontologies can play a critical role in adapting healthcare insurance to meet new advancements in smart healthcare. As discussed in the related work section, ontologies have already been used in different fields, including smart healthcare. However, ontologies have not been used to support smart healthcare insurance policy selection to the best of our knowledge. Available ontologies represent current healthcare insurance policies and apply XML retrieval approaches using tree matching rules to match the entered data and the ontology. In contrast, our proposed ontology provides an adaptive healthcare insurance policy that considers the technological requirements according to the customer’s available EHR information.

2.3. Ontology Scope

The ontology scope determines the overall system function and operation. It helps in assigning suitable insurance policy packages. The following functional requirements specify the scope of the ontology based on ontology competency questions in Table 5 [33]. The ontology captures three main scopes. First, the policy package scope, which defines the basic policy for each group. Second, the disease monitoring scope, which specifies the different disease groups to monitor. Third, the technology scope, which specifies technological requirements for each policy package. These scopes will be used in the reasoning engine to create an adaptive policy package based on the patient’s status changes. Table 6 presents the ontology scope in detail.
Table 5. Ontology competency questions.
Table 6. Ontology scope.

2.4. Ontology Classes and Sub-Classes

We used Protégé [36] to build and develop the ontology in this work. Protégé is a free, open-source ontology editor that enables the creation of the ontology and the SWRL rules. It has a built-in Reasoner that ensures ontology consistency. The developed ontology consists of the following two main classes: a customer class and an insurance policy class. Figure 3 presents the ontology components, including the classes and axioms. Individuals or instances are the ground-level components of an ontology. A class is a kind of group that individuals belong to. In Protégé, any class is a subclass of “Thing”, class of all things. For example, ‘Disease’ is a class of all diseases. Instances can have properties or features that they inherit by class membership. Axioms are assertions and rules in a logical form that ontology describes in its application domain. In the following, we describe classes and sub-classes.
Figure 3. Ontology components.
  • Class: Customer—represents the customer’s profile retrieved from his EHR. The policy is selected based on the customer’s profile. This research not only focuses on regular treatment but also considers the technological requirements to enhance the treatments and improve customers’ health and wellness. Figure 4 presents the customer class description;
    Figure 4. Customer class description.
  • Class: Insurance Policy—consists of five sub-classes. Figure 5 presents the instances of each sub-class in the insurance policy class;
    Figure 5. Instances of insurance policy subclasses. (a) Instances of basic policy’s subclasses, (b) Instances of Lifestyle_management subclasses, (c) Instances of Self_management subclasses, (d) Instances of Treatment_technology_requirment subclasses, (e) Instances of Support_treatment subclasses.
    ○
    Sub-class: Basic_policy—provides packages for customers with a “Healthy” health status. Figure 5a presents instances of the “Basic_policy”;
    ○
    Sub-class: Lifestyle_management—provides customers with a “need to follow up” health status. Figure 5b presents the instances of “Lifestyle_management”;
    ○
    Sub-class: Self_management—provides packages for customers with “unhealthy” health status. Figure 5c presents the instances of “Self_management”;
    ○
    Sub-class: Treatment_technology_requirement—identifies the technological requirement of each insurance packages. Figure 5d presents the instances of the “Treatment_technology_requirement” subclass;
    ○
    Sub-class: Support_treatment—identifies if the customer required a support treatment as an additional package. Figure 5e presents the instances of the “Support_treatment” subclass.
  • Class: Disease—defines diseases and disease groups. Figure 6 presents the disease group description. It represents 22 diseases in the ICD 10 code (International Classification of Diseases, Tenth Revision) and four disease monitoring groups, as shown in Figure 6a;
    Figure 6. Disease class and Disease monitoring description. (a) Disease class description, (b) Disease monitoring class description.
  • Class: Disease monitoring—groups the diseases according to the disease monitoring technological requirements. Figure 6b presents the disease monitoring description.

2.5. Web Ontology Language (OWL) Object Type Properties

The object properties represent the relationships between the ontology’s classes. Figure 7 presents the object–type properties of the proposed insurance policy ontology, which are defined below.
Figure 7. Object propriety Hierarchy.
  • “Has Age Group”: each customer is assigned to an age group according to the age classifications. The domain of this property is “Customer class” and the range is “Age Group class”;
  • “Has diagnosis”: each customer with “unhealthy” or “need to follow up” status is diagnosed with one or more diseases. This property’s domain is “Customer class” and the range is “Disease class”;
  • “Has Disease Group”: each disease is affiliated with a disease group. The domain of this property is “Disease class” and the range is “Disease Group”;
  • “Has Health Status”: each customer has a health status. This property’s domain is “Customer class” and the range is “Health status class”;
  • “Has Insurance Policy”: each customer has a collection of insurance policy packages representing the healthcare insurance policy. This property’s domain is “Customer class” and the range is “Insurance policy class”;
  • “Has Lifestyle Management Policy”: assigns a lifestyle management policy package to the required customer. The domain of this property is “Customer class” and the range is “Lifestyle Management Policy class”;
  • “Has Self-Management Policy”: assigns a self-management policy package to the required customer. This property’s domain is “Customer class” and the range is “Self-management policy class”;
  • “Has Support Treatment”: assigns a support treatment policy package to the required customer. This property’s domain is “Customer class” and the range is “Support treatment class”;
  • “Has Technology Requirement”: assigned if the customer required any technology requirement alongside insurance policy. The domain of this property is “Customer class” and the range is “Technology Requirement”.

2.6. OWL Data Properties

Data properties represent the relationships and links between classes and data and have either text or numeric formats. Meanwhile, we used integer format in the data properties only. Figure 8 presents the data properties hierarchy, which is defined below.
Figure 8. Data Properties Hierarchy.
  • “Has Age” defines the value of the customer’s age. The domain of this property is “Customer class” and the range is “integer”;
  • “Has Patient Id” defines the customer’s ID value. The domain of this property is “Customer class” and the range is “integer”.

2.7. Semantic Constraints

Figure 9 presents the negative property assertions as semantic constraints, which identify the classes’ restrictions. Figure 9a shows that when the patient’s health status is equal to “healthy”, it cannot be “follow up” or “not healthy”. Figure 9b shows that when the patient’s health status is equal to “not healthy”, it cannot be “follow up” or “healthy”. Figure 9c shows that when the patient’s health status is equal to “follow up”, it cannot be “healthy” or “unhealthy”.
Figure 9. Semantic constraints. (a) Semantic constraints of health status = healthy, (b) Semantic constraints of health status = not_healthy, (c) Semantic constraints of health status = Need_follow_up.

2.8. Reasoner Engine

The Reasoner/reasoning engine is the core component responsible for inferring logical consequences from a set of asserted rules. The UML activity diagram in Figure 10 presents these rules and the consequences. Alternative paths and decisions are modeled using a decision diamond. Oval shape indicates an activity or a decision. Figure 10 exhausts all cases we implemented in our system. In the following, we provide examples of these rules:
Figure 10. A-SHIP system Reasoner engine.
  • If the patient is a newborn or does not have an EHR record, they are assigned a basic policy;
  • If a person is a child and needs support treatment, then their insurance package will include a child basic policy with an appointment supplement package;
  • If a person is elderly and suffers from a disease, their health status requires follow-up. The insurance package will include elderly basic with lifestyle and BAN/AAL packages;
  • If a person is elderly and suffers from heart disease, their health status requires support treatment. The insurance package will include elderly basic with appointment package and implant heart monitoring packages.
Notice that the Reasoner is assumed to have access to the EHRs; hence, for a given patient, the Reasoner can detect and update the policy package based on the patient’s recent medical history and requirements. In case there are no changes in the medical requirements, the Reasoner keeps the same insurance package. The reasoning engine analyzes the retrieved patient data and assigns the required insurance policy. The proposed system deals with two types of knowledge, subjective and objective. The subjective knowledge is the patient’s EHR data, while the objective knowledge includes the electronic medical tools used in helping doctors treat the patient for diseases.

2.9. Validation

Protégé provides third-party Reasoners like HermiT and FaCT++ and others to validate the ontologies [37]. Reasoner detects and finds inconsistencies or contradictions of ontology’s structure and data based on mathematical models. It provides logical deductions based on inference rules defined and specified in a description logic and uses forward chaining or backward chaining to perform inference [38]. Pellet Reasoner is used to validate the A-SHIP ontology. It is an open-source Java-based OWL 2 Reasoner. It can be used in unification with Jena and OWL API libraries. Pellet supports OWL 2 profiles, including OWL 2 EL. It incorporates optimizations for nominal, conjunctive query answering, and incremental reasoning. Figure 11 shows the validation of A-SHIP ontology.
Figure 11. Validation of ontology consistency.

3. Results

A-SHIP is part of the integrated, sustainable, smart healthcare system and it works dynamically, without any user intervention. A website was built to validate the ontology and to present the results of our system. The control components implement the following:
  • Retrieve the ontology and the Reasoner;
  • Recuperate the patient dataset;
  • Feed the Reasoner with the instances;
  • Present the patient data and the insurance policy.
Several web development tools were used to develop the ontology-based web application. These tools include HTML, CSS, JavaScript, jQuery, OWL API, and SWRL API. The web application presents the customer policy for a specific customer ID. The web services are hosted on the Apache Tomcat server. The Semantic Web Rule Language (SWRL) is used with the Reasoner to Query data. Based on the requested customer ID, Ajax fetches the customer data, using JavaScript to integrate it with the ontology manager. The system reads the ontology, registers the Rule engine and Reasoner, then maps the user data with the rules and applies the specific policy, according to the user’s query.
Figure 12 shows the website user’s interface. The patient enters the ID, then the system presents the customer information (age, disease, health status support treatment) and the healthcare insurance policy details.
Figure 12. User Interface Design.

3.1. Data Source

A-SHIP is an innovative, ongoing research model, to augment a sustainable smart healthcare system. Therefore, it was challenging to get the required dataset to match the system requirements. For the proof of concept, we created a dataset by gathering and combining information from different sources to make the required EHR format. MIMIC is the main dataset used and consists of patients’ information. Other data sources were used to collect insurance and technological-related data, as shown in Table 7. The patient’s ID and age were encrypted for privacy purposes. We calculated the age according to the FMIMIC age encrypting formula and using the same ID. The dataset was created in CSV format and consists of 12 columns (covers basic patient information and health status). One thousand one hundred ninety-eight patient records were selected to cover all healthcare statuses and the proposed insurance policy packages.
Table 7. Data source.

3.2. System Testing

We considered different scenarios for testing our system. We validated our system by executing three requests that covered all health statuses (healthy, need follow-up, unhealthy) for all groups. We added dummy data to balance different age groups and compensate for missing ones. Table 8 and Figure 13 present the testing scenario outcomes and reference screenshots.
Table 8. Testing scenarios.
Figure 13. Testing scenarios. (a) customer ID# 8472, (b) customer ID# 4925, (c) customer ID# 6675, (d) customer ID# 5005, (e) customer ID# 5002, (f) customer ID# 5004, (g) customer ID# 5007, (h) customer ID# 5012, (i) customer ID# 5010.

4. Conclusions

In this paper, we proposed an adaptive, sustainable healthcare insurance policy. The main purpose of the proposed system is to assign a customer-centric policy based on customers’ requirements. This system retrieves customer data from associated EHRs. It selects the required policy packages, according to the customer’s health status, age, and technical requirements, to maintain their health and wellness. As proof of concept, we developed an ontology-based web application that implements the A-SHIP model and applies SWRL rules to match patients’ data with the required insurance policy package. We have developed different scenarios to validate our ontology and presented results.

Author Contributions

Conceptualization, M.A.-T. and F.S.; methodology, M.A.-T., H.B.E. and F.S.; software, M.A.-T., M.R.N. and H.B.E.; validation, M.A. and K.S.; formal analysis, M.A.-T.; investigation, M.A.-T. and F.S.; resources, F.S.; data curation, M.A.-T.; writing—original draft preparation, M.A.-T., M.R.N.; writing—review and editing, K.S., F.S. and M.A.; visualization, M.R.N.; supervision, F.S.; project administration, F.S.; funding acquisition, F.S. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by the United Arab Emirates University (UAEU) research grant number 31T078, and the APC was funded by the College of Information Technology, UAEU.

Data Availability Statement

Not applicable.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. WHO. About WHO; World Health Organization. 2020. Available online: http://www.who.int/about/en/ (accessed on 4 May 2020).
  2. WHO. eHealth. 2020. Available online: http://www.who.int/ehealth/en/ (accessed on 4 May 2020).
  3. World Bank. Current Health Expenditure (% of GDP). 2019. Available online: https://data.worldbank.org/indicator/SH.XPD.CHEX.GD.ZS?end=2016&start=2000&view=chart (accessed on 26 October 2019).
  4. Statista. US National Health Expenditure as Percent of GDP from 1960 to 2019. 2019. Available online: https://www.statista.com/statistics/184968/us-health-expenditure-as-percent-of-gdp-since-1960/ (accessed on 26 April 2021).
  5. Healthcare.gov. Premiums, How Insurance Companies Set Health, USA. Available online: https://www.healthcare.gov/how-plans-set-your-premiums/ (accessed on 30 December 2020).
  6. Tian, S.; Yang, W.; le Grange, J.M.; Wang, P.; Huang, W.; Ye, Z. Smart healthcare: Making medical care more intelligent. Glob. Health J. 2019, 3, 62–65. [Google Scholar] [CrossRef]
  7. Moses, M.A.; Pedroza, P.; Baral, R.; Bloom, S.; Brown, J.; Chapin, A.M.; Compton, K.; Fullman, N.; Eldrenkamp, E.; Jung, A. The future of health insurance. Lancet 2015, 204, 759–760. [Google Scholar]
  8. IBM, Define Customer Segments in the Insurance Sample; IBM Knowledge Center. Available online: https://www.ibm.com/support/knowledgecenter/en/SSCJHT_1.0.0/com.ibm.swg.ba.cognos.pci_oth.1.0.0.doc/c_pci_pm_insur_cust_seg.html (accessed on 11 April 2019).
  9. Punke, H. Why Doctors Review Health Insurance Claims. 2018. Available online: https://www.makingthehealthcaresystemwork.com/2018/10/23/why-doctors-review-health-insurance-claims/ (accessed on 23 March 2019).
  10. Rose, S. What is the Main Business Model for Insurance Companies? 2018. Available online: https://www.investopedia.com/ask/answers/052015/what-main-business-model-insurance-companies.asp (accessed on 6 April 2019).
  11. Sharma, N.; Mangla, M.; Nandan, S.; Gupta, D.; Tiwari, P. Biomedical signal processing and control a smart ontology-based IoT framework for remote patient monitoring. Biomed. Signal Process. Control 2021, 68, 102717. [Google Scholar] [CrossRef]
  12. Chen, L.; Lu, D.; Zhu, M.; Muzammal, M.; Samuel, O.S.; Huang, G.; Li, W.; Wu, H. OMDP: An ontology-based model for diagnosis and treatment of diabetes patients in remote healthcare systems. Int. J. Distrib. Sens. Netw. 2019, 15, 5. [Google Scholar] [CrossRef]
  13. Shen, Y.; Yuan, K.; Chen, D.; Colloc, J.; Yang, M.; Li, Y.; Lei, K. An ontology-driven clinical decision support system (IDDAP) for infectious disease diagnosis and antibiotic prescription. Artif. Intell. Med. 2018, 86, 20–32. [Google Scholar] [CrossRef] [PubMed]
  14. Hristoskova, A.; Sakkalis, V.; Zacharioudakis, G.; Tsiknakis, M.; de Turck, F. Ontology-driven monitoring of patient’s vital signs enabling personalized medical detection and alert. Sensors 2014, 14, 1598–1628. [Google Scholar] [CrossRef] [PubMed]
  15. Abbas, A.; Bilal, K.; Zhang, L.; Khan, S.U. A cloud based health insurance plan recommendation system: A user centered approach. Futur. Gener. Comput. Syst. 2015, 43–44, 99–109. [Google Scholar] [CrossRef]
  16. Sahi, M.A.; Abbas, H.; Saleem, K.; Yang, X.; Derhab, A.; Orgun, M.A.; Iqbal, W.; Rashid, I.; Yaseen, A. Privacy preservation in e-Healthcare environments: State of the art and future directions. IEEE Access 2017, 6, 464–478. [Google Scholar] [CrossRef]
  17. Mahmoud, M.M.E.; Rodrigues, J.J.P.C.; Ahmed, S.H.; Shah, S.C.; Al-Muhtadi, J.F.; Korotaev, V.V.; De Albuquerque, V.H.C. Enabling technologies on cloud of things for smart healthcare. IEEE Access 2018, 6, 31950–31967. [Google Scholar] [CrossRef]
  18. Pham, M.; Yehenew, D.H.; Weihua, S. Delivering home healthcare through a Cloud-based Smart Home Environment (CoSHE). Futur. Gener. Comput. Syst. 2018, 81, 129–140. [Google Scholar] [CrossRef]
  19. Bansal, M.; Bani, G. IoT Based development boards for smart healthcare applications. In Proceedings of the 2018 4th International Conference on Computing Communication and Automation (ICCCA), Greater Noidia, India, 14–15 December 2018; pp. 1–7. [Google Scholar]
  20. Firouzi, F.; Rahmani, A.M.; Mankodiya, K.; Badaroglu, M.; Merrett, G.V. Internet-of-Things and big data for smarter healthcare: From device to architecture, applications, and analytics. Futur. Gener. Comput. Syst. 2018, 78, 583–586. [Google Scholar] [CrossRef] [Green Version]
  21. Al Thawadi, M.; Sallabi, F.; Awad, M.; Shuaib, K. Disruptive IoT-based healthcare insurance business model. In Proceedings of the 22nd IEEE International Conference on Computational Science and Engineering and 17th IEEE International Conference on Embedded Ubiquitous Computing CSE/EUC, New York, NY, USA, 1–3 August 2019; pp. 397–403. [Google Scholar]
  22. Osterwalder, A.; Pigneur, Y. Business Model Generation-A handbook for visionaries, Game Changers and challengers striving to defy outmoded business models and design tomorrow’s enterprises. In The Medieval Opus: Imitation, Rewriting, and Transmission in the French Tradition; University of Sheffield: Sheffield, UK, 2010; pp. 45–58. [Google Scholar]
  23. Doyle, D.J.; Garmon, E.H. American Society of Anesthesiologists Classification (ASA Class). 2019. Available online: https://www.ncbi.nlm.nih.gov/books/NBK441940/ (accessed on 26 April 2021).
  24. Bodenheimer, T.; Lorig, K.; Holman, H.; Grumbach, K. Patient self-management of chronic disease in primary care. JAMA 2002, 288, 2469–2475. [Google Scholar] [CrossRef] [PubMed]
  25. Uddin, Z. Ambient sensors for elderly care and independent living: A survey. Sensors 2018, 18, 2027. [Google Scholar] [CrossRef] [Green Version]
  26. Marcelino, I.; Laza, R.; Domingues, P.; Gomez-Meire, S.; Fdez-Riverola, F.; Pereira, A. Active and assisted living ecosystem for the elderly. Sensors 2018, 18, 1246. [Google Scholar] [CrossRef] [Green Version]
  27. Healthy Communities Institute. How Are the Different Age Groups Defined? Conduent Healthy Communities Institute. 2020. Available online: https://help.healthycities.org/hc/en-us/articles/219556208-How-are-the-different-age-groups-defined (accessed on 22 June 2020).
  28. UpToDate. Available online: https://www.uptodate.com/home (accessed on 20 February 2020).
  29. Bioportal. International Classification of Diseases, Version 10. 2019. Available online: https://bioportal.bioontology.org/ontologies/ICD10/?p=summary (accessed on 21 June 2019).
  30. Naqvi, M.R.; Iqbal, M.W.; Ashraf, M.U.; Ahamd, S.; Soliman, A.T.; Khurram, S.; Choi, J.-G. Ontology driven testing strategies for IoT applications. Comput. Mater. Continua 2022, 70, 5855–5869. [Google Scholar] [CrossRef]
  31. Naz, T.; Akhtar, M.; Shahzad, S.K.; Fasli, M.; Iqbal, M.W.; Naqvi, M.R. Ontology-driven advanced drug-drug interaction. Comput. Electr. Eng. 2020, 86, 106695. [Google Scholar] [CrossRef]
  32. Shahzad, S.K.; Ahmed, D.; Naqvi, M.R.; Mushtaq, M.T.; Iqbal, M.W.; Munir, F. Ontology driven smart health service integration. Comput. Methods Progr. Biomed. 2021, 207, 106146. [Google Scholar] [CrossRef]
  33. Lasierra, N.; Alesanco, A.; Guillén, S.; García, J. A three stage ontology-driven solution to provide personalized care to chronic patients at home. J. Biomed. Inform. 2013, 46, 516–529. [Google Scholar] [CrossRef]
  34. Riaño, D.; Real, F.; Lopez-Vallverdu, J.A.; Campana, F.; Ercolani, S.; Mecoci, P.; Annicchiarico, R.; Caltagirone, C. An ontology-based personalization of healthcare knowledge to support clinical decisions for chronically ill patients. J. Biomed. Inform. 2012, 45, 429–446. [Google Scholar] [CrossRef]
  35. Noy, N.F.; McGuinness, D.L.; Arcos-Novillo, D.A.; Güemes-Castorena, D. Development of an additive manufacturing technology scenario for opportunity identification—The case of Mexico. Futures 2017, 90, 1–15. [Google Scholar]
  36. Protege. Available online: https://protege.stanford.edu/ (accessed on 20 February 2019).
  37. Zhao, H.; Zhang, S.; Zhao, J. Research of using protégé to build ontology. In Proceedings of the 2012 IEEE/ACIS 11th International Conference on Computer and Information Science ICIS 2012, Shanghai, China, 30 May–1 June 2012; pp. 697–700. [Google Scholar]
  38. Abburu, S. A survey on ontology reasoners and comparison. Int. J. Comput. Appl. 2012, 57, 33–39. [Google Scholar]
  39. Johnson, A.E.W.; Pollard, T.J.; Shen, L.; Lehman, L.-W.H.; Feng, M.; Ghassemi, M.; Moody, B.; Szolovits, P.; Celi, L.A.; Mark, R.G. MIMIC-III, a freely accessible critical care database. Sci. Data 2016, 3, 1–9. [Google Scholar] [CrossRef] [PubMed] [Green Version]
  40. Hindawi. Available online: https://www.hindawi.com/about/ (accessed on 15 February 2020).
  41. The IoT Marketplace. Available online: https://www.the-iot-marketplace.com/ (accessed on 15 February 2020).
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
Study of CZTSSe-Based Solar Cells with Different ETMs by SCAPS
Previous
Behavior of RC Beam–Column Joints Strengthened with Modified Reinforcement Techniques
Next