Ontology

Ontology for Health Economic Data, Models and Evidence

In information science an ontology is a kind of formal specification, one that defines the categories of thing in a field and states in logic how those categories relate to one another. For health economists the categories include hospital admissions, health states and costs, and a typical statement says that every emergency admission is a hospital admission, so software can treat a record of one as a record of the other. Two datasets that code the same admission differently, or two models that use the word "progression" for different events, cannot be pooled or compared until someone fixes what each term means, and an ontology records those decisions once in a form that people and software can both check.

What an ontology contains

Gruber's definition calls an ontology an explicit specification of a conceptualisation, meaning the objects, concepts and relationships presumed to exist in some area of interest. Each name is tied to human-readable text saying what it denotes and to formal axioms constraining its use. The W3C primer for the Web Ontology Language (OWL 2) describes an ontology as a set of precise descriptive statements about some part of the world, intended to prevent misunderstandings between people and to make software behave in a uniform, predictable way.

OWL 2 calls objects individuals, categories classes and relations properties. Noy and McGuinness add that an ontology together with a set of individual instances of its classes forms a knowledge base.

How subclass statements let software reach conclusions

Much of the value of an ontology lies in what a reasoner can infer from it. The OWL 2 primer explains that a statement that Woman is a subclass of Person lets a reasoner conclude that every individual recorded as a woman is also a person, and that subclass relationships are transitive. Its rule of thumb is that a subclass relation fits when the phrase "every A is a B" makes sense and is correct. For a health economist this means a query for a broad cost category can return records coded to its narrower categories without listing them.

Two features of OWL differ from what analysts expect of a database. The primer notes that a fact missing from a database is usually taken as false, whereas in an OWL document the fact may simply be missing but still true, which is the open-world assumption. The primer also warns that a domain or range statement licenses further inference instead of constraining the data, so a careless statement can make the reasoner classify a cat as a person. Checking data against set conditions is a separate job for a validation language such as the W3C Shapes Constraint Language (SHACL).

Top-level ontologies and the wiki's own ontology family

A top-level ontology holds categories common to every area of science, and the Basic Formal Ontology (BFO) is a small one of this kind, maintained in its 2020 release as conformant to the ISO/IEC 21838-1 requirements for top-level ontologies. Domain ontologies built beneath a shared top level are easier to combine and reuse, and many ontologies in the OBO Foundry use BFO in this way.

HealthEconomics.wiki publishes ontologies that keep meanings apart from real things. The Health Economics Ontology (HEO) is a vocabulary of the wiki's concepts, each with a permanent web address and a definition, written in the Simple Knowledge Organization System (SKOS) and OWL with typed relationships such as part of and used to calculate. The Real Health Economics Ontology (RHEO), written in OWL and aligned to BFO 2020, describes real things such as patients, care settings, resources, payments and the records made about them, so that a model result can be traced back to its sources. Companion ontologies cover outcomes (OHEO), valuation (HEAO), mathematics (HEMO), units of work (HETO), learning pathways (HELO) and HTA rules tied to dated guidance versions (HEIRO). Each has a BioPortal entry, and several are alpha releases.

Where ontologies appear in health economic work

Health economists often meet ontologies inside data and search tools. The ontology itself is rarely a separate object.

Real-world data for costs and outcomes

Studies that pool electronic health records and claims data across countries meet different codes for the same event. The OHDSI Standardized Vocabularies, the reference ontology for the OMOP common data model, held over 10 million concepts from 136 vocabularies in 2023 and pick one standard concept per meaning. In their atrial fibrillation example a SNOMED CT concept is standard and ICD-10-CM, Read and MeSH codes are mapped to it. Standard concepts are joined in a precomputed hierarchy of "Isa" and "Subsumes" relationships, which lets a query for a broad concept reach its narrower ones.

For real-world evidence submitted to NICE, the NICE real-world evidence framework (ECD9, published 2022) asks that conversion to a common data model be reported with its version and full mapping details, including any information loss. ECD9 also asks that changes to coding systems be documented, giving as its example the replacement of Read v2 codes by SNOMED CT in UK primary care.

Decision models in HTA

Ontologies can also describe the structure of a health economic model. The Ontology for Simulation of Diseases (OSDi) represents disease stages, manifestations and pathways, together with interventions, health resources and parameters such as utilities. A 2026 study tested whether generative AI could populate its classes with individuals describing profound biotinidase deficiency. After expert review of over 1,300 generated individuals, the authors concluded that the approach needs structured prompting, suitable file formats and expert validation.

Searching for evidence

A systematic review search of MEDLINE meets MeSH, which the US National Library of Medicine describes as a controlled and hierarchically organised vocabulary used for indexing, cataloguing and searching. Articles are indexed under the most specific heading available, so a search on a broad heading needs the narrower headings shown in the MeSH trees.

Building or reusing an ontology for an analysis

Noy and McGuinness stress that there is no single correct way to model a domain and that ontology development is iterative. They suggest fixing the domain and scope first, partly by writing competency questions the finished ontology should be able to answer, and then checking whether an existing ontology can be reused or extended. For a costing study a competency question might be "which recorded contacts count as hospital care", and the answer can come from an existing clinical terminology plus a thin layer of study-specific classes.

The same guide treats synonyms as names for one class, so "QALY gain" and "QALYs gained" would be one class, and warns that a cycle in a hierarchy makes the classes in it equivalent. Reference vocabularies are revised over time (the OHDSI vocabularies semiannually), so the version used belongs in the methods.

Worked example with a cost parameter that depends on the hierarchy

The data, the drug and every number below are illustrative. An analyst estimates the annual cost of heart failure admissions for 1,000 adults to populate a one-year comparison of a fictional drug, Corvantil, against usual care. The linked extract uses a hierarchy in which "acute heart failure" and "chronic heart failure" are both subclasses of "heart failure". It contains 250 admissions coded to the parent concept, 200 coded to acute heart failure and 150 coded to chronic heart failure. Each admission costs GBP 3,000.

1. Count the admissions two ways. A query that matches the parent code exactly finds 250 admissions. A query that follows the subclass hierarchy finds 250 + 200 + 150 = 600.

2. Compute the annual cost per patient.

$$\bar{c} = \frac{n \times u}{N}$$

where $\bar{c}$ is the annual admission cost per patient, $n$ is the number of admissions found, $u$ is the unit cost per admission (GBP 3,000) and $N$ is the number of patients (1,000). The exact-code query gives 250 × 3,000 / 1,000 = 750, so GBP 750 per patient, and the hierarchy query gives 600 × 3,000 / 1,000 = 1,800, so GBP 1,800 per patient. The exact-code figure misses GBP 1,050 of the GBP 1,800, or 58% of the cost.

3. Carry the cost into the comparison. Corvantil is assumed to cut heart failure admissions by 25%, to add GBP 1,500 a year in drug cost and to gain 0.04 QALYs per patient over the year.

$$\text{ICER} = \frac{c_d - r\,\bar{c}}{\Delta E}$$

where $c_d$ is the extra drug cost per patient (GBP 1,500), $r$ is the proportional reduction in admissions (0.25), $\bar{c}$ is the baseline admission cost per patient and $\Delta E$ is the QALY gain (0.04). With the exact-code cost the saving is 0.25 × 750 = 187.50 and the ICER is (1,500 − 187.50) / 0.04 = 32,812.50, or GBP 32,812.50 per QALY. With the hierarchy cost the saving is 0.25 × 1,800 = 450 and the ICER is (1,500 − 450) / 0.04 = 26,250, or GBP 26,250 per QALY.

4. Interpretation. Ignoring the hierarchy raised the ICER by a quarter through code selection alone, with no change in clinical effect or price. A reviewer would see the difference only if the code list, the hierarchy used and any unmapped codes were reported.

How an ontology differs from nearby ideas

Neighbouring tools share vocabulary with ontologies but commit to less. The W3C SKOS Reference states that SKOS is not a formal knowledge representation language. In its account a thesaurus or classification scheme describes ideas through natural language and arranges them in hierarchies that carry no formal semantics, while a formal ontology asserts axioms and facts. Converting a thesaurus or classification into a formal ontology is, in its words, intellectually demanding and time consuming.

• Common data models. Gruber likens ontologies to conceptual schemas in databases. The OMOP data model fixes tables and fields, and the OHDSI vocabularies fix what the codes in them mean.
• Data linkage. NICE ECD9 describes data linkage as combining sources to extend the information on individual patients. Linkage joins records for the same person, whereas an ontology aligns the meaning of the codes inside them.
• Knowledge graphs and the FAIR principles. The FAIR principles ask data and metadata to use a formal, shared knowledge representation language and FAIR vocabularies, and place both requirements under interoperability. Ontologies supply those vocabularies and knowledge graphs apply them to data, in support of digital interoperability between health data systems.

Where ontologies fall short in health economic use

An ontology standardises meaning and leaves data quality untouched. Gruber noted that committing to a common ontology guarantees consistency but not completeness. The OHDSI authors write that standardising vocabularies will never conclude, that mappings may be wrong and that some data elements, such as detailed tumour attributes, still lack adequate vocabularies.

A study of the OHDSI network published in 2026 found that 61 of 89 terminologies appeared in fewer than 10% of data sources, and that fewer than 1% of codes (95 of 742,337) appeared in all 22 sources that gave code-level data, even after harmonisation. For a cost-effectiveness analysis a code list that performs well in one database may not transfer to another, and ECD9 asks that an existing code list be reviewed for validity before use.

Some misunderstandings recur. A hierarchy query is taken as proof that a code list is right, when the query only applies the hierarchy supplied. An ontology populated by a language model is assumed ready for use, although the OSDi study found lower reliability for structurally complex parts and kept expert validation.

Sources

• Gruber TR. A translation approach to portable ontology specifications. Knowledge Acquisition. 1993;5(2):199-220. https://tomgruber.org/writing/ontolingua-kaj-1993.pdf
• Noy NF, McGuinness DL. Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory; 2001. https://protege.stanford.edu/publications/ontology_development/ontology101.pdf
• Hitzler P, Krötzsch M, Parsia B, et al., editors. OWL 2 Web Ontology Language Primer (Second Edition). W3C Recommendation, 11 December 2012. https://www.w3.org/TR/owl2-primer/
• Miles A, Bechhofer S, editors. SKOS Simple Knowledge Organization System Reference. W3C Recommendation, 18 August 2009. https://www.w3.org/TR/skos-reference/
• Knublauch H, Kontokostas D, editors. Shapes Constraint Language (SHACL). W3C Recommendation, 20 July 2017. https://www.w3.org/TR/shacl/
• Basic Formal Ontology. BFO 2020 repository README and BFO home page, accessed 2 November 2026. https://github.com/BFO-ontology/BFO-2020
• Wilkinson MD, Dumontier M, Aalbersberg IJ, et al. The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data. 2016;3:160018. https://doi.org/10.1038/sdata.2016.18
• Reich C, Ostropolets A, Ryan P, et al. OHDSI Standardized Vocabularies, a large-scale centralized reference ontology for international data harmonization. Journal of the American Medical Informatics Association. 2024;31(3):583-590. https://doi.org/10.1093/jamia/ocad247
• Ostropolets A, Korsik V, Skuhareuskaya T, et al. Real-world use of controlled terminologies, ontologies, and vocabularies for evidence generation across a large international observational network. JMIR Medical Informatics. 2026;14:e92727. https://doi.org/10.2196/92727
• González-González E, Castilla-Rodríguez I, Dorta-Hernández JA. Ontology-driven generation of parameters for health technology assessment models: a prompt engineering study. International Journal of Technology Assessment in Health Care. 2026;42(1):e47. https://doi.org/10.1017/S0266462326103754
• National Institute for Health and Care Excellence. NICE real-world evidence framework (ECD9). Published 23 June 2022, last updated September 2025. https://www.nice.org.uk/corporate/ecd9
• US National Library of Medicine. Medical Subject Headings (MeSH) home page and MeSH Tree Structures, accessed 10 October 2026. https://www.nlm.nih.gov/mesh/meshhome.html