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

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. Health insurance plan description.

Health Insurance Plan	Description
Indemnity plans	Repaid the patients’ and providers’ expenses.
Conventional indemnity plan	Repaid the patients’ expenses without limitation to the provider selection.
Preferred provider organization (PPO) plan	It covers the expenses for selected providers, and the patient can select a provider outside the network, but the rates will be higher than the company’s providers’ network.
Exclusive provider organization (EPO) plan	It covers the expenses for selected providers, and the patient can select a provider outside the network, but it will not cover the expenses unless in emergency cases.
Health maintenance organization (HMO)	A healthcare system that focuses on the assumption of financial risks and provides comprehensive medical services. It covers a particular geographic area to HMO members, and the return is a fixed, prepaid fee.
Group Model HMO	A type of HMO that deals with a single multi-specialty medical group to provide the services for the HMO members. The medical group can provide services to non-HMO members as well.
Staff Model HMO	A type of HMO with its employees (physicians) and the member can have the medical services from these providers only.
Network Model HMO	A type of HMO that has contracts with different services providers. These groups can provide services for the non-HMO members as well.
Individual Practice Association (IPA) HMO	A type of HMO that consists of a group of independent practicing physicians. An IPA provides services to HMO and non-HMO plan participants.
Point-of-service (POS) plan	A hybrid plan (HMO/PPO) covers the cost for the providers in the network as in HMO and applies the traditional compensation for the other providers.
Physician-hospital organization (PHO)	An association between physicians and hospitals to help providers increase their market share, enhance bargaining power, and reduce administrative costs.
Medigap Supplemental Plans	Medigap is the most popular plan used in the USA. It provides the participant a limited amount of money to spend during the year that pays the services deductibles, copayments, and other expenses.

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.

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:

• 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. Insurance policy parameters.

Parameter	Description
Health Status	Healthy—A patient who does not require any type of treatment or continuous monitoring. In this case, the system assigns the basic policy covering seasonal diseases, vaccines, and other ordinary requirements. Follow up—A healthy patient diagnosed with an interim disease that can be treated with some adjustment and changes in the patient’s lifestyle, such as anemia. Unhealthy—A self-management patient diagnosed with one or more chronic conditions such as heart disease. Also considered the assisted living patient who requires real-time health and environment monitoring.
Age	It is an integer number that represents the patient’s age. Our system categorizes patients based on age into three groups: child, adult, and elderly.
Diagnose	The final diagnosis of the patient before being discharged from a hospital.
Support Treatment	The treatment enhances the healing process and has two values: Yes or No.

defines the main parameters that specify a patient’s policy.

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. Age group categories.

Age Group	Age Range
Child	Greater or Equal to 0 and Less than 18 Years
Adult	Greater or Equal to 18 and Less than 64 Years
Elderly	Greater than or Equal to 65

.

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. Disease monitoring classification.

Group Name	Diseases
Heart monitoring	Portal hypertension Cardiac arrhythmia, unspecified Supraventricular tachycardia Cardiomyopathies Congenital malformation of the heart Heart disease Myocarditis
Vital signs	Bacterial meningitis Cerebral infarction Leukemia
Body Area Network & Ambient Assisted Living	Epilepsy Tic disorder
Lifestyle management	Anemia

.

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.

• 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. Ontology competency questions.

Ontology Competency Questions
What are the customer’s details (patient ID)	2. What is the insurance policy package if the customer diagnosed with “Cardiac arrhythmia”?
3. What is the basic policy for the customer age between (0–17)?	4. What is the insurance policy package if the customer diagnosed with “Supraventricular tachycardia”?
5. What is the basic policy for the customer age between (18–64)?	6. What is the insurance policy package if the customer diagnosed with “Cardiomyopathies”?
7. What is the basic policy for the customer age between (65+)?	8. What is the insurance policy package if the customer diagnosed with “Congenital malformation of heart”?
9. What is the policy package for the customer with “healthy” status and the “age” between (0–17)?	10. What is the insurance policy package if the customer diagnosed with “Heart disease”?
11. What is the policy package for the customer with “healthy” status and the “age” between (18–64)?	12. What is the insurance policy package if the customer diagnosed with “Myocarditis”?
13. What is the policy package for the customer with “healthy” status and the “age” between (65+)?	14. What is the insurance policy package if the customer diagnosed with “Cerebral infarction”?
15. What is the insurance policy if the patient has “Anemia” and the patient age is between (0–17)?	16. What is the insurance policy package if the customer diagnosed with “Leukemia”?
17. What is the insurance policy if the patient has “Anemia” and the patient age is between (18–64)?	18. What is the insurance policy package if the customer diagnosed with “Biliary cyst”?
19. What is the insurance policy if the patient has “Anemia” and the patient age is between (65+)?	20. What is the insurance policy package if the customer diagnosed with “Toxic liver disease with hepatitis”?
21. What is the policy package if the customer health status “unhealthy”?	22. What is the insurance policy package if the customer diagnosed by “Epilepsy”?
23. What is the policy package if the customer health status “follow up”?	24. What is the insurance policy package if the customer diagnosed with “Tic disorder”?
25. What is the policy package if the customer requires support treatment?	26. What is the technological requirement for “Lifestyle management package”?
27. What are the diseases under “Heart monitoring” group?	28. What is the technological requirement for “Lifestyle management package”?
29. What are the diseases under “Vital signs” group?	30. What is the technological requirement for “Implant heart monitoring package”?
31. What are the diseases under “Liver parameters” group?	32. What is the technological requirement for “Wearable Heart monitoring package”?
33. What are the diseases under “Body Area Network & Ambient Assisted Living” group?	34. What is the technological requirement for “Implant vital signs package”?
35. What are the diseases under “Lifestyle management” group?	36. What is the technological requirement for “Wearable vital signs package”?
37. What is the insurance policy package if the customer diagnosed with “Anemia”?	38. What is the technological requirement for “Body area network & Ambient Assisted Living package”?
39. What is the insurance policy package if the customer diagnosed with “Portal hypertension”?	40. What is the technological requirement for “Appointment management package”?

[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. Ontology scope.

Policy Package Functional Requirements
The ontology shall define a basic policy for each age group; child (0–17), adult (18–64), and elderly (65+).
The ontology shall define the policy package based on the health status: healthy, unhealthy, and need follow-up.
The ontology shall specify if the customer requires support treatment.
The ontology shall define the policy package based on a disease affiliated with a certain disease group such as Heart monitoring, Vital signs group, Liver parameters, Body area network and ambient assisted living, etc.
Disease Monitoring Functional Requirement
The system shall specify the diseases under each disease group such as Heart monitoring group, Vital signs group, Liver parameters group, Body area network and ambient assisted living group, Lifestyle management group.
Technology Requirements
The ontology shall specify the technological requirements for each of the following policy packages: Lifestyle management package, Implant heart monitoring package, Wearable Heart monitoring package, implant vital signs package, Implant vital signs package, Wearable vital signs package, Wearable vital signs package, Wearable vital signs package, Body area network and Ambient Assisted Living package, Appointment management package

presents the ontology scope in detail.

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.

• 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;
• Class: Insurance Policy—consists of five sub-classes. Figure 5 presents the instances of each sub-class in the insurance policy class;

  ○

  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;
• 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.

• “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.

• “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”.

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:

• 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.

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.

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. Data source.

Data Source	Description	Used Field	Website
MIMIC dataset [39]	Provides patients real data from a hospital	Patient ID	https://mimic.physionet.org/gettingstarted/access/ (accessed on 15 December 2019).
		Age
		Diagnose
Uptodate.com [28]	Clinical support source and used to explore and investigate the treatment of the disease	Insurance policy packages	https://www.uptodate.com/home (accessed on 20 February 2020).
Hindawi.com [40]	An open-access publishing website that has several journals and was used to specify the technological requirements	technological requirements	https://www.hindawi.com/ (accessed on 15 February 2020).
IoT marketplace.com [41]	Offers complete healthcare IoT solutions	technological requirements	https://www.the-iot-marketplace.com/ (accessed on 15 February 2020).

. 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.

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. Testing scenarios.

#	Description	Outcome	Figure
1.	customer ID# 8472, who is a child diagnosed with Bacterial meningitis and required support treatment	Child basic policy + Implant vital sign package + Appointment management package.	Figure 13a
2.	customer ID# 4925, who is a child diagnosed with Anemia and required support treatment	Child basic policy + Lifestyle management package + Appointment management package.	Figure 13b
3.	customer ID# 6675, who is a child diagnosed with fever	Child basic policy.	Figure 13c
4.	customer ID# 5005, who is an adult diagnosed with fever	Adult basic policy.	Figure 13d
5.	customer ID# 5002, who is an adult diagnosed with Anemia and require support treatment	Adult basic policy + Lifestyle management package + Appointment management package.	Figure 13e
6.	customer ID# 5004, who is an adult diagnosed with Tic disorder and require support treatment	Adult basic policy + Body area network and ambient assisted living package + Appointment management package.	Figure 13f
7.	customer ID# 5007, who is elderly, diagnosed with fever	Elderly basic policy.	Figure 13g
8.	customer ID# 5012, who is elderly, diagnosed with Anemia, and require support treatment	Elderly basic policy. Lifestyle management package + Appointment management package.	Figure 13h
9.	customer ID# 5010, who is elderly, diagnosed with congenital malformation and require support treatment	Elderly basic policy. Implant heart monitoring package + Appointment management package.	Figure 13i

and Figure 13 present the testing scenario outcomes and reference screenshots.

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.