# An Ontological Analysis of Health Procedure Information

Paul Fabry, Francois Goyer, Adrien Barton, Jean-Francois Ethier

► To cite this version:

Paul Fabry, Francois Goyer, Adrien Barton, Jean-Francois Ethier. An Ontological Analysis of Health Procedure Information. 12th International Conference on Biomedical Ontologies (ICBO 2021), Sep 2021, Bozen-Bolzano, Italy. hal-03512281

HAL Id: hal-03512281

https://hal.science/hal-03512281

Submitted on 5 Jan 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An Ontological Analysis of Health Procedure Information

Paul Fabry¹, Francois Goyer¹, Adrien Barton²,¹ and Jean-François Ethier¹

¹ Groupe de Recherche Interdisciplinaire en Informatique de la Santé (GRIIS), Université de Sherbrooke, Quebec, Canada

² Institut de Recherche en Informatique de Toulouse (IRIT), CNRS, France

**Abstract**

Health care processes can be formally analyzed as involving two kinds of planned processes that are mereologically related: health procedures and health activities. They can involve a number of informational entities that derive from orders meant to fulfill requests such as prescriptions. This article provides definitions and axioms for such entities, following the OBO Foundry methodology. This representation could serve as a foundation for an ontological model that aims to enable interoperability between various clinical data sources in the context of a Learning Health System.

**Keywords**

Health procedure, health care process, information content entity, prescription

## 1. Introduction

Learning health systems (LHS) facilitate the transfer of knowledge between research and care activities with the aim of improving both the health of individuals and the health care system. A LHS is based on the collection of data produced in the course of care, its exploitation to generate new knowledge, and then the dissemination of this knowledge in the care system [1]. In addition, the practice of self-measurement, or quantified self, which consists in collecting data related to one's body and activities, has increased considerably with the availability of connected devices such as electronic scales, trackers or smart watches. Quantified self leads to the generation of a very large amount of health data from individuals, which could be very valuable for an LHS [2].

The implementation of an LHS requires that health data must be accessible to user systems (for clinical research, health monitoring or reflective practice, for example) while guaranteeing the proper use of the data in terms of ethics, confidentiality, and security. However, these data are often distributed in many clinical information systems and LHSs need to support interoperability between various data sources and across different activities. For this purpose, applied ontologies can provide a common, source-independent representation of clinical information [3].

As part of PARS3 [4], a distributed data access platform supporting LHS, we have developed several ontologies for domains such as drug prescriptions with the Prescription of Drugs Ontology PDRO [5,6], laboratory test reports with the clinical Laboratory Ontology LABO [7] or clinical questionnaires with the Questionnaire Ontology QUESTO [8]. These domains are traditionally considered independently of each other and have dedicated clinical information systems, such as a CPOE (Computerized Patient Order Entry) for drug prescriptions or a LIS (Laboratory Information System) for laboratory tests. Consequently, our ontologies have been developed with a modular approach, each one representing a particular domain and including all the necessary classes to be used on its own.

However, we have observed during the development of these ontologies that the domains concerned are highly interconnected, which obliged us to make arbitrary choices in our ontologies in order to be able to respect the principles of the OBO Foundry methodology [9]. For example, the class *Health care*

International Conference on Biomedical Ontologies 2021, September 16–18, 2021, Bozen-Bolzano, Italy
EMAIL: adrien.barton@irit.fr (A. 3); jf.ethier@usherbrooke.ca (A. 4)
ORCID: 0000-0002-3336-2476 (A. 1); 0000-0002-7626-1026 (A. 2); 0000-0001-5500-6539 (A. 3); 0000-0001-9408-0109 (A. 4)

<figure><img src="image_2.png" /></figure>

© 2021 Copyright for this paper by its authors.

Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

CEUR Workshop Proceedings (CEUR-WS.org)
*prescription* has been defined within the PDRO ontology as it was the first of our ontologies that needed it. Yet, a prescription, while often associated with the dispensing and administration of medication, may also direct laboratory tests or vital signs measurements. Therefore, this class could just as well have belonged to the LABO ontology. Duplicating it in this ontology, however, would have been against one of the principles of the OBO Foundry that is to reuse classes rather than duplicate them. At first glance, this problem is solved by importing *Health care prescription* into LABO and in the same way, PDRO could import classes from LABO. Not only does the cross-dependency between ontologies quickly undermine the coherence and evolution management of ontologies, but the fact that a class is needed in both ontologies also indicates that it belongs to a more general domain than those represented in PDRO and LABO, and therefore should be defined outside of these ontologies.

In addition, even if our ontologies have focused on informational entities related to their domain, we also need to detail the processes driven by these entities. For example, the process of performing a laboratory test, in addition to the collection of a specimen and some physical analysis of one of its constituents, may require collecting information about the whole individual (such as weight, sex or age) or administrating a given substance, such as glucose. Such processes are all distinct, and can exist independently of a laboratory test, but are sometime part of such a test. Furthermore, while quantified self could quickly represent an important source of information for an LHS, data produced by personal devices may vary in quality [10,11]. Therefore, it will be important to be able to distinguish these data, and the processes that led to it, from those generated in a clinic or a hospital under the control of healthcare professionals.

This highlights the need for an upstream ontology that encompasses the common classes of our domain ontologies and describe them more accurately. In the following section we will review existing ontologies for such classes, we will then detail our proposal for additional classes as well as the methodology employed and discuss some of their implications.

## 2. Existing Classes

We restricted this review to ontologies that are part of the OBO Foundry. Among them, several classes describe care processes, to be distinguished from more general health processes such as breathing or heartbeat. Most of them are subsumed under the Ontology of Biomedical Investigation (OBI [12]) class *OBI:Planned process*=*def*. "A process that realizes a plan which is the concretization of a plan specification."

The Ontology of Adverse Event (OAE [13]) describes the class *Medical intervention* and its subclass *Medical procedure*:

* OAE:Medical intervention*=*def*. "[... A] planned process that has the goal of diagnosing, preventing or relieving illness or injury."

* OAE:Medical procedure*=*def*. "[A] medical intervention that refers to any series of pre-defined steps that should be followed to achieve a desired result."

The Environment Factor Ontology (EFO [[14]]) describes another *Medical procedure* class:

* EFO:Medical procedure*=*def*. "An activity that produces an effect, or that is intended to alter the course of a disease in a patient or population. This is a general term that encompasses the medical, social, behavioral, and environmental acts that can have preventive, therapeutic, or palliative effects."

This class is a subclass of EFO:Experimental process which restricts its scope to experiments or studies.

The Ontology for General Medical Science (OGMS [15]) describes two complementary and disjoint classes:

* OGMS:Health care process*=*def*. "A planned process with the objective to improve the health status of a patient that directly involves the treatment, diagnosis, or prevention of disease or injury of a patient."

* OGMS: Ancillary health care process*=*def*. "A planned process that has the objective to support the objective of a health care process without directly involving the treatment, diagnosis, or prevention of disease or injury of a patient."
As stated above, health procedures are already represented in current ontologies. However, these classes do not seem to be sufficient to represent all situations, on the one hand because they are defined in a health care setting, and on the other hand because they focus on processes whose objective is to modify the patient's condition. There is also a need for representing non-interventional processes, like taking someone's pulse, and processes performed outside a health care context, such as taking an acetaminophen tablet for a headache at home.

### 3. Methods

In the following, using specific examples, we discuss the main difficulties encountered when trying to represent health procedures in a practical LHS setting. We then propose several classes that could meet the requirements discussed above based on a methodology in accordance with the OBO foundry principles. These classes are built following a realist approach based on BFO [16] and the Information Artifact Ontology (IAO [17]). We follow the approach proposed by Smith and Ceusters [17], according to which an informational entity is a generically dependent continuant concretized by a quality that inheres in an independent continuant.

In addition we use the object property "specializes" described in [18]. This property defines a relation of specialization between two directive informational entities (the BFO counterpart to [18]'s directive informational content entities), for example **DIE<sub>1</sub>**: "Pour 200 ml of water in a recipient" and **DIE<sub>2</sub>**: "Slowly pour 200 ml of water in a glass". It relies on the notion of compliance: an action is compliant with a directive informational entity if it is of the type specified by this informational entity. **DIE<sub>2</sub>** specializes **DIE<sub>1</sub>** if the actions compliant with **DIE<sub>2</sub>** are compliant with **DIE<sub>1</sub>**. Classes and object properties from other ontologies are re-used as much as possible to maintain orthogonality between OBO ontologies. In addition, textual definitions following an Aristotelian structure and important axioms are provided.

### 4. Results

The taxonomy of classes described below is illustrated in Figure 1.

<figure><img src="image_3.png" /><figcaption>**Figure 1:** Taxonomy of Health intervention related classes</figcaption></figure>
**4.1. Health Procedure Definition and Structure**

Consider Mr. Jones who wears a smart watch that measures his pulse on a regular basis and stores these measurements in a personal electronic record. In addition, Mr. Jones is concerned about his weight and decides to determine his body mass index (BMI) to assess its obesity status. Self-weighing has a positive impact on weight management [19]. This index is calculated as the ratio of weight (in kg) to height (in m) squared.

Let:

* PM₁ be a pulse measurement performed by Mr. Jones' watch at a given time.

* BMI₁ be the process of Mr. Jones determining its BMI by measuring his weight, his height and calculating the ratio between the two.

PM₁ and BMI₁ are evaluations of Mr. Jones' health status. In our view, they differ from each other in two important aspects:

* BMI₁ is a process that is carried out under the will of Mr. Jones that has a predetermined objective regarding his health status, that of evaluating its obesity status by calculating his BMI. On the contrary, PM₁ does not have any specified objective with regard to the health of Mr. Jones, it is an automated process that can take place even without Mr. Jones knowing about it.

* BMI₁ can be decomposed into several well-defined relevant sub-processes: weight measurement, height measurement and the calculation of the index which takes these two measurements as input. Furthermore, weight and height measurements can be realized independently or be part of other evaluation processes.

This leads us to distinguish between two levels of processes concerning health procedures: at the higher level, the health procedures themselves, which are processes with an established objective of having a desirable impact on the health status (e.g. Mr. Jones' BMI assessment), and at the lower level, the health activities (e.g. Mr. Jones' weight measurement and height measurement), which constitute the building blocks of health procedures but can be carried out independently of any health procedure. Health activities can capture a fact concerning a health status (like a height measurement for example) or aim at modifying (positively or even negatively, for example exposing an individual to covid during a trial) the health status. They can also be performed without any particular objective regarding the health status: a height can be measured to choose the proper clothing size.

While a health activity may have as parts other processes, a health procedure includes health activities as *component* processes, that is self-contained parts of a larger entity – such as gears in a motor. From an ontological point of view, this component relationship is represented using the object property *has_component_process*, defined in the Relation Ontology (RO [20]). This property is not transitive unlike *has_part*, thus it allows us to distinguish the two levels of granularity between health procedure and health activity. In addition, a health procedure may include as components other planned process than health activities. To determine the BMI for example, in addition to the measurement of height and weight, which are two health activities, there is another planned process that takes as input the measured weight and height values to compute the index.

We propose the following definitions and axioms for *Health procedure* and *Health activity*. In addition, we will use the abbreviations HP for *Health procedure* and HA for *Health activity* for the remainder of this article.

*Health procedure=def.* "A planned process that has the objective of contributing to a desired effect on the health status of an organism or several organisms achieved through the treatment, diagnosis, or prevention of disease or injury. It has some components that are planned processes, including at least one that is a health activity."

*Health activity=def.* "A planned process that aims to produce a truthful statement about the health status of an organism or modify it."

*Health procedure* subClassOf (*has_component_process* some *Health activity*)

*Health activity* subClassOf (*has_part* some *OBI:Planned process*)
The mention of “organism” in the definition implies that the health procedure does not necessarily concern human health. Indeed, veterinary medicine presents very similar processes. However, for the remainder of the article we will consider human organisms, for easiness of presentation.

Both **PM**₁ and **BMI**₁ are processes related to Mr. Jones’ health, and to which he participates. However, they are not directed by a prescription, and they are performed without the intervention of a health care professional and outside of a health care setting such as a clinic or a hospital.

“Health care” is defined in American English as: “The prevention, treatment, and management of illness and the preservation of mental and physical well-being through the services offered by the medical and allied health professions.” [21] Relatedly, “patient” is usually defined in connection with health care as: “one who receive medical attention, care or treatment” [22]. This relationship is upheld in biomedical ontologies where both OBI and the Ontology of Medically Related Social Entities (OMRSE [23]) define “patient role” as realized by the process of being under the care of a physician or health care provider.

Consequently, the recipient of a HP is not necessarily a patient, as the involvement of a health professional is not required. Note that the health care professional does not have to be directly participating in the process: if Mr. Jones' physician asks him to measure his blood pressure every morning at home, he is not a participant in the measurement process, but he is still involved as the requesting party. To take into account this distinction we propose the subclass *Health care procedure* with the following Aristotelian definition:

*Health care procedure* = def. “A health procedure on an organism and that is requested by a health care provider.”

In view of these definitions, we can say that **BMI**₁ is an instance of HP because it is done for a diagnostic purpose, but it is not an instance of *Health care procedure* because it has not been requested by a health professional.

**PM**₁ is not intended to have a desired effect on Mr. Jones’ health but produces a statement intended to be truthful about Mr. Jones’ health status, stating the measure of his pulse at the time it is performed, and consequently **PM**₁ is an instance of HA. However, if Mr. Jones had initiated a pulse measurement on his watch because he felt palpitations, then this process would be an instance of HP and have as component part the HA of pulse measurement.

## 4.2. Prescriptions, Requests and Orders

In the previous section we differentiated between health procedures and health care procedures by the fact that the latter are requested. Usually, this request is a health care prescription, a document authored by a health care provider. However, there are other types of requests which we detail below, not all of which come from a health professional.

To illustrate this, consider the following example illustrated in Figure 2. Mr. Jones visits his physician, Dr. Dylan, who prescribes a coagulation evaluation that will measure coagulation parameters in Mr. Jones’ blood. When he goes to the laboratory, Mr. Jones also take the opportunity to ask for a cholesterol test (for which he has no prescription<fnref n="2" />). Let:

* **R**₁ be the prescription for a coagulation evaluation authored by Dr. Dylan.

* **R**₂ be the verbal request for a cholesterol test made by Mr. Jones at the laboratory.

**R**₁ belongs to the kind of request considered within the PDRO drug ontology. PDRO defines a health care prescription as follows:

*Health care prescription* = def. “A document authored by a health care provider that specifies how to realize some health care process for a particular patient.”

<footnote n="2">² For the clarity of the example, we consider the case where an individual can request a laboratory test without having a prescription. However, we are aware that this is not necessarily allowed depending on the local jurisdiction.</footnote>
The term “document” in the above definition refers to an IAO:Document: “A collection of information content entities intended to be understood together as a whole.” IAO:Information content entity (ICE) is the keystone of IAO and is defined as: “A generically dependent continuant that is about something.”

A health care prescription has among its parts some IAO:Directive information entity that specify the processes to be realized [5]. In this scenario, the prescription guides the laboratory personnel to perform laboratory tests on Mr. Jones to assess its coagulation function. That is, the prescription is interpreted by the laboratory's personnel, and this interpretation leads to another entity, an order, that includes informational entities directing the appropriate tests according to the laboratory's own protocol.

<figure><img src="image_4.png" /><figcaption>**Figure 2:** Example of a prescription that is a HP request. This request (coag) is processed, and a HP order is generated containing two items, one that specifies a Partial Thromboplastin Time (PTT) test and another that specifies an International Normalized Ratio (INR) test.</figcaption></figure>

There is no prescription for R<sub>2</sub>, yet it will be interpreted by the laboratory and will result in the production of an order that will lead to the realization of a cholesterol test. Thus, the ICE leading to a HP is not a health care prescription, but it is still a request. Furthermore, this order is the result of a process that takes as input an information entity which can range from a verbal demand to a prescription. Although IAO:Document has a definition that might be broad enough to encompass verbal requests on top of prescriptions (a question that might deserve some further analysis in future works), we prudently classify here a request more generally under IAO:Informational content entity. We represent this ICE as a *Health procedure request*, and the resulting order as a *Health procedure order*.

R<sub>1</sub> is a *Health procedure request* and is processed by the laboratory personnel to generate a *Health procedure order* to perform the test. The HP request processing has usually a health care provider as participant, but not necessarily. Mr. Jones could also be a participant in this process, as illustrated by the following example. Mr. Jones is prescribed a medication with the following dosage written on the prescription: "2 tablets/day morning and evening". The pharmacy delivers this medication in a package with the label reading: "take 1 tablet AM and 1 tablet PM". Mr. Jones may interpret this label (which then becomes a request) by taking 1 tablet at 8:00 in the morning and 1 tablet at 7:30 in the evening. In that case, the order directing the medication uptake is an ICE concretized in Mr. Jones' brain [17].

Furthermore, the distinction between requests and orders is necessary because the order that results from the interpretation process is not necessarily an exact copy of the request as it might contain objectives that are different from those that were present on the request. According to the example on Figure 2, Dr. Dylan wrote "coag" on the prescription. The processing agent will attempt to generate an HP order compatible with this objective while referencing only known standard operating procedures (plan specification) for this laboratory. Sometimes, the local HP plan specification contains exactly the same objective, in which case the order will also contain this objective. In other cases, like the example presented in Figure 2, the objective present on the request cannot be directly found in the local HP plan specification. At that junction, two courses of action are possible: 1) no order is generated; 2) the processing agent generates an order that will attempt to achieve an objective considered similar by the agent. The "coag" situation is an example of the latter. The request objective "coag" is processed by the laboratory to then generate a *Health procedure order* containing two items, one that specifies a
Partial Thromboplastin Time (PTT) test and another that specifies an International Normalized Ratio (INR) test, both tests usually being performed to evaluate coagulation in this organization. Of note, in another laboratory the same prescription could have led to a different HP order that could contain a third item specifying a D-dimer test, another test used to assess coagulation. With regard to the sequence described above, we propose the following classes and their Aristotelian definition:

*Health procedure request*<sub>def.</sub> "An information content entity requesting the execution of some health procedures."

*Health procedure request processing*<sub>def.</sub> "A planned process having as specified input some health procedure request, and that aims at generating some health procedure order based on algorithms and judgment of the processing agent."

*Health procedure order*<sub>def.</sub> "An information content entity that is the specified output of a health procedure request processing and that specifies some health procedure to be performed."

A *Health procedure request* is not a particular type of document but encompass several ICEs such as a drug prescription or an injunction to do a COVID test before a plane trip for example, and these ICEs are processed by a health professional to generate orders specifying the procedures to be realized, such as a specific COVID test to be performed. In addition, we propose the following axiom:

*Health procedure request processing* subclassOf (has_specified_input some *Health procedure request*)

## 4.3. Informational Entities Related to Health Procedures

We have categorized HP and HA as OBI:*Planned process*, namely processes which realize the concretisation of an IAO:*Plan specification*, the latter being an IAO:*Directive information entity* which is defined as: "An information content entity whose concretizations indicate to their bearer how to realize them in a process." In addition, these processes will generate other relevant informational entities, such as a TSH result, or a weight measurement mentioned in the previous examples.

Let's use the example of a TSH test prescription for Mr. Jones by Dr. Dylan, as illustrated on Figure 3. The informational entities present in the prescription itself are described in the PDRO ontology and are not discussed here. Furthermore, some processes, such as the specimen collection needed to perform the assays, are not detailed for the sake of clarity.

The prescription from Dr. Dylan is a *Health procedure request* and, when processed by the laboratory, the resulting *Health procedure order* will direct a TSH assay by the laboratory.

With regard to the previous sequence, we propose the following definition and axiom:

*Health procedure directive item*<sub>def.</sub> "A directive information entity that specifies a health procedure to be carried out."

*Health procedure order* subclassOf (has_part some *Health procedure directive item*)

In turn, a *Health procedure directive item* includes a *Health procedure objective specification* that specifies the objective of the procedure, in this case, the dosage of Mr. Jones' TSH. The *Health procedure objective specification* is then specialized by a *Health procedure plan specification* which describes the plan to be followed according to the laboratory's own protocol to achieve the objective. Figure 2 illustrates a case where the plan specification identified as "thyroid assessment protocol 2.1" specializes the objective specification "TSH". Of note, in this specific example, if the TSH dosage is abnormal, HAs aiming at evaluating T3 and T4 (two related thyroid hormones helping to better characterize the thyroid function when the TSH is abnormal) will also occur. In the future the hospital could specialize the same HP objective specification using a different plan specification that would not
include conditional T4 and T3 HA. Only a TSH result will be provided even if it's abnormal. We propose the following definitions and axioms for the aforementioned classes:

*Health procedure directive item objective specification* = def. "An objective specification that specifies the objective of a health procedure to be realized."

<figure><img src="image_5.png" /><figcaption>**Figure 3:** Examples of an order with one directive item that could lead to more than one HA. In this hospital, additional tests (HA) are carried out if the TSH is abnormal.</figcaption></figure>

*Health procedure protocol* = def. "A plan specification defining the required aspects to be present in each instance of a given type of health procedure."

*Health activity plan specification* = def. "A plan specification defining the required aspects to be present in each instance of a given type of health activity."
*Health procedure directive item* SubClassOf (*has_part* some *Health procedure objective specification*)

*Health procedure plan specification* SubClassOf (IAO:mentions some *Health activity plan specification*)

We consider the relation between *Health procedure directive item objective specification* and *Health procedure protocol* to be one of specialization, as defined in [18]: the laboratory's thyroid assessment protocol is a specialization of the objective in that it directs actions that are compliant with the realization of Mr. Jones' TSH assay. To that effect, we propose the following axiom:

*Health procedure protocol* subClassOf (specializes some *Health procedure directive item objective specification*)

Finally, a *Health procedure instruction* specializes a *Health procedure protocol*, which also specializes the *Health procedure directive item*. In effect, the *Health procedure instruction* applies the parameters of the *Health procedure directive item* (2021/05/12, as requested by Dr. Dylan, for Mr. Jones) to the directives stated in the *Health procedure plan specification* (perform a thyroid assessment that includes dosages of TSH, T3 and T4 according to laboratory's protocol). A *Health procedure* is directed by a *Health procedure instruction*. We propose the following definition and axioms for *Health procedure instruction*:

*Health procedure instruction* = def. "A directive information entity that includes all the required information to carry out a health procedure according to 1) the health procedure directive item of a particular health intervention order and 2) the health procedure plan specification related to this type of health procedure."

*Health procedure instruction* subClassOf (specializes some *Health procedure directive item*)

*Health procedure instruction* subClassOf (specializes some *Health procedure plan specification*)

*Health procedure* subClassOf (*is_directed_by* some *Health procedure instruction*)

In addition to the directive entities, there are other informational entities that are generated by the different processes. For example, the HP "thyroid assessment for Mr. Jones" includes three HA for measuring the three hormones of interest: TSH, T3 and T4. These HA will each generate an IAO:Data item which is an "[...] information content entity that is intended to be a truthful statement about something [...]". In our case, these are the values of TSH, T3 and T4 concentrations in Mr. Jones' blood. We consider these data items to be instances of *Health activity data item* that is defined as follows:

*Health activity data item* = def. "A data item that is a specified output of a health activity."

Different data items can be generated during the health activity, such as a time stamp for example. However, the health activity data item is the principal data resulting from the process (as it is its specified output), e.g., a test result, and can often be integrated into a report.

As discussed in the BMI example, a *Health activity data item* can be used by another HI's component to output a general result for the HP. For the BMI, this process consists of computing the function having as input the two health activity data items obtained (weight and height). This process is adequately represented by the class *OBI:Data transformation* that is defined as: "A planned process that produces output data from input data." When this data transformation occurs in a HP, it produces an ICE that is the principal information generated by the HP, such as the result of the Mr. Jones' TSH in our example. We refer to this process as a *Health procedure data transformation* that is defined as follows:
*Health procedure data transformation* = def. "A data transformation that is a component of a health procedure, that has as specified input at least one health activity data item generated by health procedure component and aim at generating a health procedure result item."

The ICE generated, the *Health procedure result item*, is the principal data resulting from the HP. In our BMI example it is the BMI's value.

*Health procedure result item* = def. "An information content entity that is a specified output of a health procedure data transformation."

*Health procedure result item* subClassOf (is_specified_output_of some *Health procedure data transformation*)

This *Health procedure result item* is a part of larger entity, the *Health procedure order reporting item*, that includes also other information related to the result such as the normal range values.

*Health procedure result item* subClassOf (is_part_of some *Health procedure order reporting item*)

*Health procedure order reporting item* = def. "An information content entity including information about a health procedure directive item and possibly the associated health procedure."

The *Health procedure order reporting item* is part of the *Health procedure order report* which could contain other ICEs such as the name of the laboratory where the tests were performed, identifications of the prescribing physician (Dr. Dylan) and the patient (Mr. Jones), etc.

*Health procedure order report* = def. "A document containing information about some health procedure orders and possibly the associated health procedures."

*Health procedure order report* subClassOf (has_part some *Health procedure order reporting item*)

*Health procedure order report* subClassOf (isAbout some *Health procedure order*)

# 5. Discussion and Conclusion

With this work we propose a representation of health procedures according to two classes of planned processes, *HP* and *HA*, with the former having as parts the latter. We describe also the informational entities directing them by distinguishing between a request, whether sanctioned or not by a health professional, and an order and the process that allows to transform one into the other. The informational entities that are included in an order are described in more detail as well as those that are produced by HA and HP and eventually reported.

There are several points we would like to address regarding the proposed definition of HP. First, *Health procedure* share some similarities with OGMS:*health care process*. However, a distinction between the two is needed as the former class encompasses procedures that exist beyond a health care setting. Further work and discussion with the OGMS team needs to be done in order to identify how to best integrate the classes defined in this work in the current ontological landscape. To that effect we have not provided yet an ontology in OWL format including the aforementioned classes. Secondly, although the purpose of a HP is to contribute to health status in a desired way, the HAs that compose it do not necessarily have this objective, as a HA can modify the health status in a positive or negative direction. For example, a HP that consists of a nuclear medicine scan includes an HA that is the injection of a radioactive substance. This process does not have a beneficial effect as such, on the contrary it entails risks of important adverse events but is part of a process which is realized with the aim of obtaining a beneficial effect. In addition, a HP involves an organism. We have assumed in this work that this organism is a human being, but the definition allows for the inclusion of veterinary procedures
as well. If the need to make the distinction arises, it seems relatively easy to define subclasses specifically for human beings.

We define a HP request as an ICE that encompass many different ICEs such as prescriptions or verbal orders. A different approach could have been to create a subclass of BFO:Role named HP request role and define a HP request as an ICE that bears a HP request role. However, since a BFO:Role is a realizable entity, it must inhere in an independent continuant, and ICEs are not independent continuants (neither are their concretizations). An alternative would be that this request role is borne by the independent continuant carrying the information quality concretizing the ICE. However, this independent continuant can be difficult to define, especially in the case of a verbal request for example. A possible evolution would be to consider this request role as a type of informational slot that can bear semantic and pragmatic properties, as envisioned in [24].

As for our previous ontologies, we have created these classes following the OBO Foundry methodology, and one question that arises is how to integrate this work with already existing classes in other OBO ontologies. The mereology of processes detailed in this paper includes two main levels: *Health procedure* and *Health activity*. We consider that a *Health activity* can include some planned processes as a part and this would be the path we propose to integrate these classes with the many planned processes related to health procedures and evaluations that have already been established, such as OBI:Specimen collection or OBI:Assay. In effect, the health activity that is the realization of a TSH test on Mr. Jones has as part an assay that measures Mr. Jones’ TSH blood concentration.

In this regard, although the examples illustrated in this work are mainly concerned with evaluation processes such as laboratory tests and vital signs, a preliminary evaluation hints at the fact that this framework could be applied to other domains such as surgical operations or nursing care for example.

The focus will now be to identify how to best integrate the classes defined in this work in the ontological landscape.

# 6. Acknowledgements

We would like to thank our many colleagues from the Groupe de Recherche Interdisciplinaire en Informatique de la Santé (GRIIS) for their support and insightful discussion. Pr. Ethier is a grant recipient from FRQS. Paul Fabry is funded by the Quebec SPOR Support Unit. François Goyer is supported by the Health Data Research Network.

# 7. References

[1] V.C. Kaggal, R.K. Elayavilli, S. Mehrabi, J.J. Pankratz, S. Sohn, Y. Wang, D. Li, M.M. Rastegar, S.P. Murphy, J.L. Ross, R. Chaudhry, J.D. Buntrock, H. Liu, Toward a Learning Health-care System - Knowledge Delivery at the Point of Care Empowered by Big Data and NLP, Biomed Inform Insights. 8 (2016) 13-22. https://doi.org/10.4137/BII.S37977.

[2] S.P. Wright, T.S. Hall Brown, S.R. Collier, K. Sandberg, How consumer physical activity monitors could transform human physiology research, American Journal of Physiology - Regulatory Integrative and Comparative Physiology. 312 (2017) R358-R367. https://doi.org/10.1152/ajpregu.00349.2016.

[3] J.-F. Ethier, M. McGilchrist, A. Barton, A.-M. Cloutier, V. Curcin, B.C. Delaney, A. Burgun, The TRANSFoRm project: Experience and lessons learned regarding functional and interoperability requirements to support primary care, Learning Health Systems. 2 (2018). https://doi.org/10.1002/lrh2.10037.

[4] PARS3, GRIIS. (n.d.). https://griis.ca/en/solutions/pars3/ (accessed May 18, 2021).

[5] A. Barton, P. Fabry, J.-F. Ethier, A classification of instructions in drug prescriptions and pharmacist documents, in: Proceedings of the 10th International Conference on Biomedical Ontology (ICBO 2019), Buffalo, New York, USA, 2019: pp. 1-7.

[6] J.-F. Ethier, A. Barton, R. Taseen, An ontological analysis of drug prescriptions, Applied Ontology. 13 (2018) 273-294. https://doi.org/10.3233/AO-180202.
[7] A. Barton, P. Fabry, L. Lavoie, J.-F. Ethier, LABO: An ontology for laboratory test prescription and reporting, in: 2019 Joint Ontology Workshops Episode V: The Styrian Autumn of Ontology, JOWO 2019, CEUR-WS.org, Graz; Austria, 2019.

[8] P. Fabry, A. Barton, J.-F. Ethier, QUESTO – An ontology for questionnaires, in: Proceedings of the 11th International Conference on Biomedical Ontologies, ICBO 2020, CEUR-WS.org, Bolzano; Italy, 2020.

[9] B. Smith, M. Ashburner, C. Rosse, J. Bard, W. Bug, W. Ceusters, L.J. Goldberg, K. Eilbeck, A. Ireland, C.J. Mungall, N. Leontis, P. Rocca-Serra, A. Ruttenberg, S.-A. Sansone, R.H. Scheuermann, N. Shah, P.L. Whetzel, S. Lewis, The OBO Foundry: coordinated evolution of ontologies to support biomedical data integration, Nature Biotechnology. 25 (2007) 1251–1255.
https://doi.org/10.1038/nbt1346.

[10] K.R. Evenson, M.M. Goto, R.D. Furberg, Systematic review of the validity and reliability of consumer-wearable activity trackers, International Journal of Behavioral Nutrition and Physical Activity. 12 (2015). https://doi.org/10.1186/s12966-015-0314-1.

[11] D. Fuller, E. Colwell, J. Low, K. Orychock, M. Ann Tobin, B. Simango, R. Buote, D. van Heerden, H. Luan, K. Cullen, L. Slade, N.G.A. Taylor, Reliability and Validity of Commercially Available Wearable Devices for Measuring Steps, Energy Expenditure, and Heart Rate: Systematic Review, JMIR MHealth and UHealth. 8 (2020). https://doi.org/10.2196/18694.

[12] A. Bandrowski, R. Brinkman, M. Brochhausen, et al., The Ontology for Biomedical Investigations, PLOS ONE. 11 (2016) e0154556. https://doi.org/10.1371/journal.pone.0154556.

[13] Y. He, S. Sarntivijai, Y. Lin, Z. Xiang, A. Guo, S. Zhang, D. Jagannathan, L. Toldo, C. Tao, B. Smith, OAE: The Ontology of Adverse Events, J Biomed Semantics. 5 (2014) 29.
https://doi.org/10.1186/2041-1480-5-29.

[14] J. Malone, E. Holloway, T. Adamusiak, M. Kapushesky, J. Zheng, N. Kolesnikov, A. Zhukova, A. Brazma, H. Parkinson, Modeling sample variables with an Experimental Factor Ontology, Bioinformatics. 26 (2010) 1112–1118. https://doi.org/10.1093/bioinformatics/btq099.

[15] R.H. Scheuermann, W. Ceusters, B. Smith, Toward an ontological treatment of disease and diagnosis, Proceedings of the 2009 AMIA Summit on Translational Bioinformatics. (2009) 116–120.

[16] R. Arp, B. Smith, A.D. Spear, Building Ontologies with Basic Formal Ontology, MIT Press, Cambridge, MA, USA, 2015.

[17] W. Ceusters, B. Smith, Aboutness: Towards Foundations for the Information Artifact Ontology, in: Proceedings of the Sixth International Conference on Biomedical Ontology (ICBO), CEUR vol. 1515, 2015: pp. 1–5.

[18] A. Barton, L. Vieu, J.-F. Ethier, Directing actions, in: 2019 Joint Ontology Workshops Episode V: The Styrian Autumn of Ontology, JOWO 2019, CEUR-WS.org, Graz; Austria, 2019.

[19] C. Shieh, M.R. Knisely, D. Clark, J.S. Carpenter, Self-weighing in weight management interventions: A systematic review of literature, Obesity Research and Clinical Practice. 10 (2016) 493–519. https://doi.org/10.1016/j.orcp.2016.01.004.

[20] oborel/obo-relations, oborel, 2021. https://github.com/oborel/obo-relations (accessed May 13, 2021).

[21] health care (n. d.), American Heritage® Dictionary of the English Language, Fifth Edition. (2011).

[22] patient (n. d.), American Heritage® Dictionary of the English Language, Fifth Edition. (2011).

[23] A. Hicks, J. Hanna, D. Welch, M. Brochhausen, W.R. Hogan, The ontology of medically related social entities: recent developments, J Biomed Semantics. 7 (2016) 47.
https://doi.org/10.1186/s13326-016-0087-8.

[24] A. Barton, F. Toyoshima, J.-F. Ethier, Clinical documents and their parts, in: Proceedings of the 11th International Conference on Biomedical Ontologies, ICBO 2020, CEUR-WS.org, Bolzano; Italy, 2020.