Background
Literature review
Diabetes and mobile health
The ontology and mobile health
Interoperability and mobile health
Study objectives
-
We propose an interoperable, expandable, and cloud-based mobile CDSS framework for T1D management. This CDSS can remotely monitor diabetics according to their real-time WBAN metrics, and suggests adjustments in insulin dosages, exercise plans, and diet plans. The CDSS can discover critical situations, including hypoglycemia and hyperglycemia, and can suggest emergency procedures. In addition, it is able to propose actionable, evidence-based, standard, accurate, and medically complete TPs based on patient conditions and preferences collected from real-time data and historical EHR profiles.
-
Effective CDSS depends mainly on the quality of its knowledge base. As a result, we propose a real, holistic, global, and extensible T1D-treatment OWL 2 ontology (FASTO) based on SHOIQ (D) description logic. This ontology is the core knowledge base of the proposed CDSS. It supports temporal reasoning about patient observations and TPs. FASTO is built using the Protégé 5.1 ontology editor.
-
This CDSS suggests plans that include critical treatment components of insulin monitoring and management, lifestyle (i.e. diet and exercise), and education. To support evidence-based medicine, the TP-formulated treatment rules are extracted from the most recent standard diabetes CPGs. We employ SWRL rules to represent CPG knowledge, and we use ontology reasoners to implement the CDSS inference engine.
-
We propose a method to collect and integrate all patient data from heterogeneous sources in a centralized cloud-based EHR database based on the most recent HL7 standards (i.e. FHIR). This database is used to instantiate FASTO. In addition, this database can be utilized by machine learning techniques to enrich CDSS knowledge.
-
The majority of the system processes are executed in the cloud. FASTO and an ontology reasoner provide real-time knowledge-as-a-service to patients and physicians. As a result, the resources (i.e. memory, battery, and processor) of a patient’s mobile device will be preserved for monitoring.
-
The FASTO novel knowledge model reuses several standard ontologies, including the BFO 2.0 top-level ontology, vital-sign ontology, medical terminologies, and SSN sensor ontology. To support effective and efficient data exchanges between distributed and heterogeneous system modules (i.e. CDSSs, WBANs, and EHR distributed systems), we created our proposed system based on the most recent and publicly acceptable interoperability standard of HL7 FHIR. All FASTO concepts are unified with FHIR resources. The utilized SSN concepts are implemented according to the semantics and structures of FHIR resources, and all ontology classes are modeled as subclasses of BFO universals. The data are exchanged between modules based on FHIR servers and in JSON format.
-
The resulting fully-fledged FASTO ontology is transparent and independent from EHR systems’ different data formats and different sensor data standards, thanks to the FHIR standard. As a result, our CDSS is portable, offering a plug-and-play capability with any EHR ecosystem after little configurations.
Methods
Patient and Mobile health services modules
Cloud-based CDSS module
The CDSS engine
Define T1D treatment elements
Identify FHIR resources and profiling
CarePlan.category = 698,360,004|Diabetes self management plan
. We depend on the FHIR vital sign, BMI, and blood glucose profiling. To preserve the monotonicity of FASTO, we considered the final state for all resources (e.g. Observation.status = “final”
and Condition.verificationStatus = “confirmed”
). Background knowledge such as foods and interactions (e.g. food-drug, food-disease, drug-drug, and drug-disease), and drug side effects are modeled away from FHIR but are used in a standard way with resources such as NutritionOrder and Detectedissue, respectively. Remote-monitoring resources (e.g. observation) are mapped to SSN classes, and all classes are mapped to BFO universals. All references are modeled as object properties.TP data element | HL7 FHIR resource | Description | SSN class | SSN Mapping | Cloud database table | BFO universal |
---|---|---|---|---|---|---|
Patient + demographic | Patient | Person who plays the patient role (e.g. age, address, gender) | – | – | Patient | ⊑BFO: BFO_0000023 |
Physician | Practitioner | Person who plays the role of physician, nutritionist, etc. | – | – | Practitioner | ⊑BFO: BFO_0000023 |
Relative | Related person | Person who plays the patient’s family member role | – | – | Related person | ⊑BFO: BFO_0000023 |
Vital sign | Observation | Vital signs such as blood pressure, temperature | observationValue | Exact | Observation | ⊑BFO: OBI_0000027 |
Blood glucose level | Observation | Patient blood glucose level from sensor | observationValue | Exact | Observation | ⊑BFO: OBI_0000027 |
Lab test result | Observation | Lab test result (e.g. HbA1c, LDL, and RPG) | – | Observation | ⊑BFO: OBI_0000027 | |
Physical examination | Observation | Such as height, weight, BMI, and level of activity | observationValue | Exact | Observation | ⊑BFO: OBI_0000027 |
Social history | Observation | Patient medical history (e.g. smoking history, alcohol intake) | – | – | Observation | ⊑BFO: OBI_0000027 |
Patient symptom | Condition | Persistent patient symptoms that need long term management | – | – | Condition | ⊑BFO: BFO_0000019 |
Complication | Condition | Pregnancy and current and previous diseases or diagnoses | – | – | Condition | ⊑BFO: BFO_0000019 |
Body site of sensor | BodySite | Describe sensor place | platform | Partial match | BodySite | ⊑BFO: BFO_0000006 |
Adverse even | AdverseEvent | Events occur during the course of patient medical care | – | – | AdverseEvent | ⊑BFO: BFO_0000016 |
Patient allergy | AllergyIntolerance | Description of patient allergies | – | – | AllergyIntolerance | ⊑BFO: BFO_0000016 |
Patient location | Location | Location of the patient | – | Exact | Location | ⊑BFO: BFO_0000006 |
Family history | FamilyMemberHistory | Medical history of patient’s family members | – | – | FamilyMemberHistory | ⊑BFO: BFO_0000182 |
Treatment plan | CarePlan | Define patient’s future, current, or past custom care plan | – | – | CarePlan | ⊑BFO: OBI_0000011 |
Goal | Goal | Define the medical goal of a care plan | – | – | Goal | ⊑BFO: BFO_0000019 |
Diet | NutritionOrder | Describe ordered diet | – | – | NutritionOrder | ⊑BFO: BFO_0000019 |
Drug | Medication | Define a drug such as insulin | – | – | Medication | ⊑BFO: BFO_0000040 |
Plan medication | MedicationRequest | Medication prescription for patient | – | – | MedicationRequest | ⊑BFO: IAO_0000030 |
Medication dosage | Dosage | Dosage instruction information | – | – | Dosage | ⊑BFO: BFO_0000019 |
Taken medications | MedicationStatement | Patient’s current medications list | – | – | MedicationStatement | ⊑BFO: IAO_0000030 |
WBAN sensors | Device | Describes WBAN components (e.g. sensor) | sensing device | Exact | Device | ⊑BFO: BFO_0000040 |
Patient-physician | Encounter | Interaction between a patient and healthcare provider | – | – | Encounter | ⊑BFO: OBI_0000011 |
Patient-physician | EpisodeOfCare | Track provider for ongoing care of the patient | – | – | EpisodeOfCare | ⊑BFO: OBI_0000011 |
Care team | CareTeam | Group of practitioners responsible for patient monitoring | – | – | CareTeam | ⊑BFO: BFO_0000023 |
Exercise | Procedure | A procedure done by patient as a part of treatment plan | – | – | Procedure | ⊑BFO: BFO_0000019 |
UoM | Element | Units of measurement | – | – | – | ⊑BFO: IAO_0000030 |
Education | Procedure | Patient education as a part of the treatment plan | – | – | Procedure | ⊑BFO: OBI_0000011 |
fhir:primitiveDatatype
class, which is defined as: fhir:primitiveDatatype
⊑ {(fhir:element
⊑ ‘BFO:information content entity’)
⊓(fhir:hasValue max 1 rdfs:literal)}
. We implemented 16 primitive types, and each one of them is mapped to one or more XSD types by putting constraints to literal values. Complex data types are modeled with a specific name for each property. We implemented 14 complex types. For example, the fhir:timing
class is defined as:282372007
) concept, and UO OWL 2 ontology (
https://bioportal.bioontology.org/ontologies/UO
) provides another design method. However, we depend on the standard selected by HL7, i.e. the unified code for units of measurement (UCUM:
http://unitsofmeasure.org/ucum.html
). The unitOfMeasure
class is defined as ⊑(∃hasUoMCode.xsd:string
)⊓ ∃hasUoMDisplay.xsd:string
), where both display and code are imported from UCUM.Determine SSN classes and map them to BFO
ssn:sensingDevice
is defined as follows:batteryLifetime
, Latency
, Manufacture
, MaintenanceSchedule
, Security
, Processor
, OperatingPowerRange
, ResponseTime
, SystemLiveTime
, Frequency
, Resolution
, DetectionLimit
, and Sensitivity
. Most of these classes are in the MeasuringCapability
and OperatingRestriction
modules. The other classes and their related properties are imported with the same semantics. A total of 10 classes, 26 object properties, and 5 data properties are imported from the SSN ontology. The data are collected in the ontology based on the HL7 FHIR standard format and vital sign ontology (
http://purl.bioontology.org/ontology/VSO
) terminology. All patient vital sign classes are subclasses of OGMS_0000029
or the vital sign
class; in addition, these classes and bloodGlucoseLevel
are subsumed by featureOfInterest
. The process of transforming raw sensor data into JSON format is done on the WBU (i.e. the mobile phone). Collected data from WBANs has temporal and location dimensions. The temporal dimension is modeled by the SWRL TO ontology (
http://swrl.stanford.edu/ontologies/built-ins/3.3/temporal.owl
). The SWRL TO ontology is lighter than the W3C Time ontology (https://
www.w3.org/TR/owl-time
) and, at the same time, is sufficient. It has four main classes (STO:validTime
, STO:granularity
, STO:validInstant
, and STO:validPeriod
), two object properties (STO:hasGranularity
and STO:hasValidTime
), and three data properties (STO:hasFinishTime
, STO:hasStartTime
, and STO:hasTime
). In addition, it provides some temporal capabilities using SWRL buildins. The SSN is extended by some knowledge from the SmartBAN ontology (
https://www.etsi.org/technologies-clusters/technologies/smart-body-area-networks
) including fasto: Node
⊑ssn:physicalObject
and fasto: WBAN
⊑ssn:system
⊑ssn:physicalObject
classes, and SBAN:hasContact
object property. We defined two new classes of fasto:wearableSystem
and fasto:wearableSensorPlatform
to extend the definition of ssn:system
and ssn:platform
, respectively, for sensors located on the patient’s body, respectively.fasto:placedOn
, is defined for the axiom of (wearableSensorPlatform
⊑∀ placedOn.humanBodyPart
), and body parts can be defined according to the foundational model of anatomy (
https://bioportal.bioontology.org/ontologies/FMA
). According to the recent CPGs, blood glucose, not HbA1c, must be used to monitor T1D patients [20]. In addition, to build an accurate and continuing TP, a complete medical evaluation should be conducted based on a complete patient profile. Raw data collected from different sensors cannot easily work together owing to the lack of semantic interoperability. SSN converts these data to semantic data, but integrating sensors data with EHR data is another challenge. To handle this challenge, collected knowledge needs to be standardized to achieve semantic interoperability among its sources. As a result, we will extend the previously modeled knowledge by FHIR resources.Map resources to SSN and BFO
Model resources knowledge with OWL constructs
ResourceName.ElementName
]. The following are the semantics for some classes based on FHIR resources described in description logic syntax. We extended the medication resource as follows:insulin
class is subsumed by the medication
class as follows:person
≡{patient
⊔practitioner
⊔relative
} is defined as follows:patient
class is extended to capture the sensor and WBAN knowledge as follows.patientProfile
class including observations (i.e. observationValue
), complications (i.e. condition
), symptoms (i.e. condition
), adverse events (i.e. adverseEvent
), medications (i.e. medicationStatement
), encounters (i.e. encounter
), food (i.e. food
), care plans (i.e. carePlan
), etc.observationValue
class was extended according to the Observation FHIR resource, which defines its observed quantity, coding, and UoM as follows:observationValue
class in its context with sensor
, WBAN
, patient profile
, and carePlan
classes. Many classes, and many class properties, were removed to keep the figure simple. The Condition class is used to model patient’s pregnancy, current or historical symptoms, diagnoses, and complications based on the Condition.category
object property. We imported the possible diabetes symptoms from our DDO, and possible diagnosis and complications from our DMTO. The condition
class is used to define specific conditions for specific patient to be considered in TP instantiation.
medication
class and the patient’s specific medications (medicationStatement
). However, it has no equivalent logic for diseases. It has the condition
class for patient-specific conditions, but there is no resource for modeling diseases in general. For each disease, this class is critical in order to define its code and contradicted drugs, foods, and exercises. We introduced a disease
class as follows:adverseEvent
class. Patient context, including current conditions or treatments, is essential in establishing a cause-and-effect relationship for an adverse event. As a result, we relate adverseEvent
and patient profile
classes with the hasAdverseEvent
object property. In addition, the patient’s allergy and intolerance to foods and other substances is modeled in the allergyIntolerance
class. Because allergies may not depend on the context as adverse events, this class is directly related to the patient
class. The MedicationRequest
class is used to prescribe insulin for the patient, and medicationStatement
is used to collect the medication history of the patient.carePlan
class collects the semantics of the TP. Every care plan should have medication, diet, exercise, and education activities. In addition, real-time insulin dosage consultations according to changes in carbohydrates consumption and exercises are modeled.carePlan
to define the type of insulin regimen by using the hasInsulinRegimen
object property. The insulinRegimen
≡{FixedRegimen
⊔intensiveInsulinTherapy}
class is defined as follows:carePlan
has six specific, measurable, achievable, realistic, time-oriented (SMART) goals of blood glucose goal, daily per-meal glucose goal, blood pressure goal, HbA1c goal, weight goal, and other customizable goal.carePlanActivityComponent
class defines the long-term parts of the plan in the form of activities by using medicationRequest
for insulin, nutritionOrder
for diet, and procedureRequest
for education, as illustrated in Fig. 5. For real-time adjustment of insulin dosage and carb grams, the patient
class has three properties linked with the breakfast
, lunch
, and dinner
classes. These classes are subclasses of the meal
class, which is defined as (
∃hasTotalCarbsInGrams.xsd:integer)
⊓(
∃hasFood.food)
⊓(
∃hasValidTime.validInstant)
⊓(
∃hasCorrectionInsulinUnits.xsd:integer)
⊓(
∃ hasCarbsInsulinUnits.xsd:integer)
⊓(
∃hasTotalInsulin.xsd:integer)
. The patient monitoring process depends on data collected from hospitals. As a result, the Organization resource is required. The proposed system suggests TPs for physicians to approve, and the final decision is from physicians. There must be a specific party responsible for the monitoring process. As a result, the Practitioner, CareTeam, and Relative resources are used. To organize the monitoring process, Encounter and EpisodeOfCare are utilized. Each of these resources was designed as an OWL 2 class with suitable properties. For space restrictions, readers can find their DL definitions in the ontology.
Model T1D treatment knowledge with FHIR resources
ObservationValue
instance. As a result, the ontology will accept sensor observations and standardize them according to FHIR. In this version of our ontology, we depend mainly on patient weight (W) to determine TDD, as shown in Eq. 1. For DF regimen, the resulting TDD is divided into the morning dose (MD) and evening dose (ED), as shown in Eq. 2. The morning dose is divided into long or intermediate-acting insulin (MDL) and short-acting insulin (MDs), as shown in Eq. 3. The evening dose is divided into long or intermediate-acting insulin (EDL) and short-acting insulin (EDS), as shown in Eq. 4.medicationRequest
object. This class is connected to the carePlan
’s carePlanActivityComponent
by reference object property, as show in Fig. 5.carePlan
. The diet plan is defined in five steps, as shown in Fig. 7 (b).nutritionOrder
class, and BMR is added to the plan as supplementary knowledge using the nutritionOrderSupplementComponent
class (see Fig. 5). We created SWRL rules to calculate BMR for male and female patients according to the used UoM. The FHIR patient’s age and SSN weight and height observations are applied based on Eqs. 8, 9, 10 and 11. Rule 9 gives an example for calculating the BMR of a female by using the metric system (cm/kg). The resulting BMR has a UoM from the UCUM, and the value has the SCT code “165,109,007.”
Life style | Activity level value |
---|---|
Sedentary (little or no exercise) | 1.2 |
Lightly active (light exercise/sports 1–3 days/week) | 1.375 |
Moderately active (moderate exercise/sports 3–5 days/week) | 1.55 |
Very active (hard exercise/sports 6–7 days a week) | 1.725 |
Extra active (very hard exercise/sports & physical job or 2x training) | 1.9 |
carePlan
’s weight goal (WG). If W ∈ [LIW, HIW], patient has normal weight. In this case, the patient has to maintain his/her weight, and the WG should equal W. If W < LIW, the patient is underweight; he/she needs to gain weight of at least LIW − W kg. To gain this weight, the patient needs extra (LIW − W) ∗ 7700 calories. The WG should be at least W + (LIW − W) kg. If W > HIW, the patient is overweight or obese; he/she needs to lose weight of W − HIW kg. To lose this weight, patient needs to reduce calories by (W − HIW) ∗ 7700, or he/she will have to depend on the exercise plan. In this case, WG is at most W − (HIW − W) kg. We must define the period in days (d) required to lose or gain weight of (OW) and then determine the number of calories to reduce or add per day with (OW ∗ 7700)/d. The number of calories per day (CpD) is calculated as follows. CpD = MC, and if W ∈ [LIW, HIW]; CpD = MC + (OW ∗ 7700)/d, if W < LIW; and CpD = MC − (OW ∗ 7700)/d, if W > HIW. The grams of carbs are equal to CpD/4, which are distributed in meals at 30% for breakfast, 35% for lunch, and 35% for dinner. For example, Rule 13 determines the weight goal and the total daily calories for a patient who is of overweight. In addition, it codes the results using SCT and UCUM.
nutritionOrder
class supports general knowledge about diet objects, including the diet’s patient, dateTime, encounter, allergies, preferred and excluded foods, nutrients, etc. (see Fig. 5). However, we have to specifically determine each meal’s carbs and calories to be able to perform real-time monitoring. As a result, we extend the nutritionOrder resource to incorporate meal knowledge.
nutritionOrder
the object properties of NutritionOrder.meal and NutritionOrder.dailyCalories to define the order’s meal and the total daily calories, respectively. Every order is linked to a single meal. As a result, we connect a meal
class to the nutritionOrder
class, which is critical for insulin, diet, and exercise management. In this version of FASTO, we concentrate on whole calories and carbs per meals. The ontology defines the recommended foods, but it does not define specific foods and specific quantities. Please note, the required knowledge to implement specific foods is defined in FASTO, but the required SWRL was not added. For example, Rule 14 determines forbidden foods based on the patient’s current medications.
exercisePlan
class based on the Schema.org (
https://schema.org
) standard. To define the patient’s exercise sub-plan, we connect the exercisePlan
class to the carePlanActivity
class by using its reference object property.
exercisePlan
class can be mapped to the procedureRequest
instance in a straightforward way.procedureRequest
instance and sent to the patient’s mobile device (Rule 21).
Pre-meal blood glucose | Before breakfast | Before lunch | Before dinner |
---|---|---|---|
< 70 | −1 | -1 | -1 |
100–150 | Planned dose / carbs counting | Planned dose / carbs counting | Planned dose / carbs counting |
150–200 | + 1 | + 1 | + 1 |
200–250 | + 2 | + 2 | + 2 |
250–300 | + 3 | + 3 | + 3 |
> 300 | + 4 | + 4 | + 4 |
BG | Before breakfast | Before lunch | Before dinner | Before bedtime |
---|---|---|---|---|
Date | ||||
May 5 | 320 | 104 | 96 | 86 |
May 6 | 296 | 123 | 300 | 136 |
May 7 | 341 | 197 | 92 | 111 |
Cloud-based EHR database
Backend EHR systems module
Results
Ontology verification and metrics
-
generic ontology metrics including the number of classes, properties, annotations, and instances;
-
concept or class axioms, including subclass, equivalent, and disjoint axioms;
-
object property axioms, including domain and range of properties. In addition, complex axioms regarding the equivalence, inverse, disjointness, functional, transitivity, symmetry, and reflexivity of properties have been collected;
-
data property axioms, including domains and ranges properties. Further, similar to object properties, many complex axioms have been collected;
-
instance axioms, including class assertions, same individual axioms, and different individual axioms; and
-
annotation axioms, including domain and range annotations and annotation assertions.
Metric | Count |
---|---|
Classes | 9577 |
Axioms | 60,045 |
Logical axioms | 13,637 |
Equivalent classes | 7 |
Functional object properties | 9 |
Inverse object properties | 21 |
Data properties | 164 |
Data property assertions | 228 |
Object property assertions | 341 |
Class assertions | 457 |
Annotation properties | 127 |
Number of SWRL rules | 140 |
Individuals | 460 |
Annotation assertion | 35,335 |
SubClassOf | 10,024 |
Object properties | 658 |
Object property domain | 627 |
Object property range | 628 |
SubObjectPropertyOf | 649 |
Data property domains | 130 |
Data property range | 155 |
SubDataPropertyOf | 159 |
DisjointClasses axiom | 49 |
Description logic expressivity | SHOIN (D) |
Comparison with existing ontologies
Dimension | FASTO | DMTO [10] | DKOs [67] | Chen et al. [68] | Chalortham et al. [69] | Zhang et al. [70] | OntoDiabetic [71] |
---|---|---|---|---|---|---|---|
Purpose | Treatment | Treatment | Treatment | Treatment | Treatment | Treatment | Treatment |
Type of diabetes | T1D | T2D | NA | T2D | T2D | T2D | NA |
Available for reuse | Yes | Yes | No | No | No | No | No |
Based on a unified top-level ontology | Yes | Yes | No | No | No | No | No |
Encoded using standardized terminology | Yes | Yes | No | No | No | Yes | No |
Based on OWL 2 and SWRL | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Can be utilized in MH environments | Yes | No | No | No | No | No | No |
Based on an interoperability standard | Yes | No | No | No | No | No | No |
Decisions based on the whole patient profile | Yes | Yes | Yes | Only 6 tests entered by user | No | Yes | Yes |
Supports interoperability with EHR distributed systems | Yes | No | No | No | No | No | No |
Supports real-time patient monitoring based on WBANs | Yes | No | No | No | No | No | No |
Supports data communication by standards as RESTful API | Yes | No | No | No | No | No | No |
Handles interoperability with sensor data | Yes | No | No | No | No | No | No |
Based on standard knowledge (i.e. collected from CPGs) | Yes | Yes | No | Yes | No | Yes | Yes |
Uses a systematic method for creation | Yes | Yes | No | No | Yes | No | No |
Delivers complete TPs with drugs, lifestyle, and education | Yes | Yes | No | No | No | Yes | No |
Models diabetes drugs | Yes | Yes | No | Yes | No | No | Yes |
Models drugs affecting glucose level | Yes | Yes | No | No | No | No | No |
Models drug properties | Yes | Yes | No | Yes | No | No | No |
Models T1D comorbidities | Yes | Yes | Yes | No | No | No | Yes |
Reuses existing ontologies | Yes | Yes | No | No | Yes | No | Yes |
Ontology coverage | Table 5 | [10] | NA | 18 drugs +6 rules | NA | NA | NA |
Models temporal semantics | Yes | Yes | No | Yes | No | No | No |
Coverage level evaluation
Competency question | SPARQL query | Competency question | SPARQL query |
---|---|---|---|
Q1. Find all patients who achieved their TP goals. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. ?prof fasto:hasCarePlan? plan.
?plan fasto:isCurrent “true”^^xsd:Boolean;
fasto:hasGoalAchieved “true”^^xsd:Boolean.
}
| Q2. Who are the patients suffering from a specific disease with SNOMED CT code of X. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. ?prof fasto:hasComplication? cond. ?cond fhir:Condition.code? code. ?code fhir:Coding? coding.
?coding fhir:Coding.code X;
fhir:Coding.system “SNOMEDCT”.
}
|
Q3. What is the current pre-meal BG target for a patient with identifier X. | SELECT? code,? system,? value WHERE {
?p rdf:type fasto:patient;
fhir:Resource.ID? id.
?id fhir:Identifier.value X.
?p fasto:hasPatientProfile? prof. ?prof fasto:hasCarePlan? plan.
?plan fasto:isCurrent “true”^^xsd:Boolean;
fhir:DailyPerMealGlucoseLevel? goal. ?goal fhir:Goal.target? target. ?target fhir:Goal.target.detailQuantity? quant. ?quant fhir:Quantity.code? code; fhir: Quantity.value? value; fhir: Quantity.system? system.
}
| Q4. What is the current exercise plan for patient with identifier X. | SELECT DISTINCT? exe WHERE {
?p rdf:type fasto:patient;
fhir:Resource.ID? id.
?id fhir:Identifier.value X.
?p fasto:hasPatientProfile? prof. ?prof fasto:hasCarePlan? plan.
?plan fasto:isCurrent “true”^^xsd:Boolean;
fhir:CarePlan.activity? act. ?act fhir:CarePlan.activity.reference? exe.
?exe rdf:type fasto:exercisePlan.
}
|
Q5. Find all patients that are prevented from doing exercise with the compendium code of X. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. ?prof fasto:hasComplication? cond. ?cond fhir:Condition.disease? d. ?d fasto:diseaseContradictWithExercise? exe.
?exe fasto:hasCompendiumCode X.
}
| Q6. What is the insulin regimen defined for patient with identifier X. | SELECT? ir WHERE {
?p rdf:type fasto:patient;
fhir:Resource.ID? id.
?id fhir:Identifier.value X.
?p fasto:hasPatientProfile? prof. ?prof fasto:hasCarePlan? plan.
?plan fasto:isCurrent “true”^^xsd:Boolean;
fasto:hasInsulinRegimen? ir.
}
|
Q7. What are the current education materials assigned to the patient X. | SELECT? rec,? topic,? course WHERE {
?p rdf:type fasto:patient;
fhir:Resource.ID? id.
?id fhir:Identifier.value X.
?p fasto:hasEducationRecord? rec. ?rec fasto:hasLearningCourse? course; fasto:hasLearningTopic? topic.
}
| Q8. Find intensive insulin regimens, which are based on the long acting insulin with SNOMED CT code of X. FASTO supports any standard coding terminology such as SNOMED CT, LOINC, RxNorm, ICD, etc. These standards support interoperability and improve the semantic meaning of medical terms. | SELECT? ir WHERE {
?ir rdf:type fasto:insulinRegimen;
fasto:hasBasalInsulin? ba. ?ba fhir:Medication.code? code; ?code fhir:Coding? coding.
?coding fhir:Coding.code X.
}
|
Q9. Find patients that are contradict with 414,518,007|insulin detemir. A patient is prevented from taking insulin detemir in two cases: first, if he/she is currently taking a drug that contradicts with detemir, and second, if he/she has some diseases that is contradicting with detemir. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. ?prof fasto:hasPatientMedication? medstat. ?medstat fhir:MedicationReference? med. ?med fasto:drugContradictWithDrug? med2. ?med2 fhir:Medication.code? s; fhir:Coding? coding.
?coding fhir:Coding.code “126,212,009”^^xsd:string;
fhir:Coding.system “SNOMEDCT”.
}
UNION
{
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. ?prof fasto:hasComplication? cond. ?cond fhir:Condition.disease? d. ?d fasto:diseaseContradictWithDrug? med2. ?med2 fhir:Medication.code? s; fhir:Coding? coding.
?coding fhir:Coding.code “126,212,009”^^xsd:string;
fhir:Coding.system “SNOMEDCT”.
}
| Q10. List all patient taking rapid acting insulin with SNOMED CT code of X. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. ?prof fasto:hasCarePlan? plan.
?plan fasto:isCurrent “true”^^xsd:Boolean;
fasto:hasInsulinRegimen? ir. ?ir fasto:hasBolusInsulin? ins. ?ins fasto:Medication.code? code; ?code fhir:Coding? coding;
?coding fhir:Coding.code X.
Fhir:Coding.system “SNOMEDCT”.
}
|
Q11. Find child patients who have gotten in hypoglycemia before. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fhir:Person.age? a.
FILTER (?a < 10).
?p fasto:hasHistoryOfHypoglycemia? h.
FILTER (?h > 0).
}
| ||
Q12. List all patient currently on fixed insulin regimen and suffered from hyperglycemia condition before. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. fasto:hasHistoryOfHyperglycemia? i.
FILTER (?i > 0)
?prof fasto:hasCarePlan? plan.
?plan fasto:isCurrent “true”^^xsd:Boolean;
fasto:hasInsulinRegimen? ir.
?ir rdf:type fasto:fixedRegimen;
}
| Q13. List all patient who have a history of “increasing before bedtime insulin.” This pattern is inferred using the temporal abstraction of previous sensor data of before bedtime insulin. This abstraction is based on at least the previous 3 consecutive days. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof.
?prof fasto:GlucoseBefBT “increasing”^^xsd:string
}
|
Q14. List all patient having the symptom of shortness of breath. Symptoms are encoded in SNOMED CT standard terminology. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fasto:hasPatientProfile? prof. ?prof fasto:hasSymptom? sym. ?sym fhir:Condition.code? cd. ?cd fhir:Coding? cding;
?cding fhir:Coding.code “267,036,007”^^xsd:string.
Fhir:Coding.display “dyspnea”^^xsd:string.
}
| Q15. What are the characteristics of WBAN of patient with identifier X. | SELECT? wban,? sub,? lot,? date,? man,? mod WHERE {
?p rdf:type fasto:patient;
fhir:Resource.ID? id.
?id fhir:Identifier.value X.
?p fasto:hasWBAN? wban; ?wban ssn:hasSubSystem? sub; ?sub fhir:Device.lotNumber? lot; fhir:Device.manufactureDate? date; fhir:Device.manufacturer? man; fhir:Device.model? mod.
}
|
Q16. List the current sensor observations for patient X and their values. | SELECT? obs? code? quan WHERE {
?p rdf:type fasto:patient;
fhir:Resource.ID? id.
?id fhir:Identifier.value X.
?p fasto:hasPatientProfile? prof. ?prof fasto:hasObservationValue? obs.
?obs rdf:type sensedObservationValue;
fhir:Observation.code? code; fhir:Observation.valueQuantity? quan;
}
| Q17. Find adult patients that are currently on 126,212,009|insulin glargine. | SELECT DISTINCT? p WHERE {
?p rdf:type fasto:patient;
fhir:Person.age? a; fasto:hasPatientProfile? prof. ?prof fasto:hasPatientMedication? med. ?med fhir:MedicationCodeableConcept? s. ?s fhir:Coding? coding.
?coding fhir:Coding.code “126,212,009”^^xsd:string;
fhir:Coding.system “SNOMEDCT”;
Fhir:Coding.display “insulin glargine”^^xsd:string.
FILTER (?a > 19 &&? a < 55)
}
|
Complete scenario
Sensor data collection
Data collection from EHR systems
Cloud-based CDSS
carePlan
resource. The resulting carePlan
objects and their associated goal objects are mapped to FHIR resources and sent to the patient mobile device, as shown in Fig. 10.