The Hidden Architecture of Healing: How Ontologies and Data Models Quietly Run Modern Medicine
On this page
Uses the speech voice supplied by your browser or device.
The Hidden Architecture of Healing
How Ontologies and Data Models Quietly Run Modern Medicine
I want you to imagine something with me.
Imagine walking into a hospital—not the sanitized, fluorescent-lit corridors of your local medical center, but a vast, sprawling metropolis of information, a city built entirely of data, where every patient, every symptom, every medication, every lab result, every insurance claim, every research paper, and every clinical trial lives as a discrete packet of meaning, floating in an ocean of digital noise. Now imagine that this city has no map. No street signs. No addresses. No common language. Just billions of fragments of information, each speaking in its own dialect, each believing itself to be the center of the universe.
This is healthcare without ontologies.
This is medicine without data models.
And it is, in many ways, where we have been.
Not entirely, of course. The human mind is a remarkable pattern-matching engine, and for millennia, physicians have managed to practice medicine with nothing more than observation, memory, and the occasional scroll or ledger. But we are no longer in the age of scrolls. We are in the age of artificial intelligence, where machines—those tireless, literal-minded servants—attempt to read our medical records, predict our diseases, recommend our treatments, and discover our drugs. And machines, unlike humans, do not tolerate ambiguity. They do not understand context unless it is made explicit. They do not know that “myocardial infarction” and “heart attack” are the same thing unless someone tells them. They do not know that a “fever” in one database might be recorded as “elevated temperature” in another, or “pyrexia” in a third, or simply “hot” in a patient’s own words.
This is why ontologies matter. This is why data models matter. They are the hidden architecture of modern medicine—the invisible scaffolding that holds up everything from your electronic health record to the AI that might one day save your life.
But I am getting ahead of myself.
Let me start at the beginning.
Or rather, let me start at the surface, and then burrow inward, layer by layer, like a clinician palpating a patient, searching for the source of the disease.
The Surface: What Are We Even Talking About?
Let me begin with the most basic question, the one that every patient, every policymaker, and even many clinicians quietly ask when they first encounter these terms: What, in the name of all that is holy, is an ontology?
And what, while we’re at it, is a data model?
I will answer these questions not with the dry, recursive definitions you might find in a computer science textbook, but with something more visceral, more immediate.
An ontology, in the context of healthcare informatics, is a formal, explicit specification of a shared conceptualization. That is the textbook definition, and it is accurate, but it is also bloodless. Let me give it flesh.
Imagine a dictionary. Not just any dictionary, but a dictionary that does not merely list words and their meanings, but meticulously defines the relationships between those words. A dictionary that tells you not only what a “disease” is, but what diseases have what symptoms, what symptoms are associated with what biomarkers, what biomarkers are measured by what tests, what tests are performed in what clinical settings, what settings are staffed by what professionals, what professionals use what terminologies, and what terminologies map to what billing codes.
Now imagine that this dictionary is not written in English, or French, or Mandarin, but in a language that both humans and machines can read with perfect, unambiguous precision.
That is an ontology.
It is a map of medical knowledge. A taxonomy on steroids. A carefully curated network of concepts and relationships that allows us to say, with mathematical certainty, that “Type 2 Diabetes Mellitus” is a kind of “Diabetes Mellitus,” which is a kind of “Endocrine Disorder,” which is a kind of “Disease,” and that it is characterized by “Insulin Resistance,” which is associated with “Hyperglycemia,” which is measured by “HbA1c,” which has a normal range of “less than 5.7%,” and so on, and so on, ad infinitum.
A data model, meanwhile, is the structure that holds this knowledge. If an ontology is the map, a data model is the container—the database schema, the XML structure, the JSON format, the relational table—that stores the actual data. It defines what fields exist, what types of data can go into those fields, how those fields relate to one another, and what constraints apply. It is the difference between a beautifully organized library and a pile of books in a warehouse.
Together, ontologies and data models form the semantic and syntactic backbone of healthcare information systems. They are the reason why, when you go to a specialist across town, your primary care physician’s records can (sometimes, ideally) follow you. They are the reason why a researcher in Tokyo can analyze data from a clinical trial in Boston. They are the reason why an AI can (again, sometimes, ideally) read your medical history and suggest a diagnosis.
But I am still speaking in abstractions. Let me ground this in something more concrete.
The Who: The Cast of Characters in This Quiet Revolution
Who builds these things? Who maintains them? Who uses them? Who, in short, is responsible for the hidden architecture of healing?
The answer, like everything in healthcare, is complicated.
At the top of the pyramid—if we can call it a pyramid, though it is more like a tangled web—sit the standards organizations. These are the bodies that create and maintain the major healthcare ontologies and terminologies. The World Health Organization, with its International Classification of Diseases (ICD), now in its eleventh revision. The National Library of Medicine, with its Unified Medical Language System (UMLS), a vast metathesaurus that maps hundreds of biomedical vocabularies to one another. The International Health Terminology Standards Development Organisation, with its SNOMED CT, the most comprehensive clinical terminology in the world, containing over 350,000 concepts. The Logical Observation Identifiers Names and Codes (LOINC) committee, which standardizes laboratory and clinical observations. The RxNorm project, which standardizes drug names. The Gene Ontology Consortium, which maps the functions of genes. The Foundational Model of Anatomy, which maps the human body in exquisite detail.
These organizations are staffed by linguists, computer scientists, clinicians, biologists, and philosophers—yes, philosophers, for ontology is, at its root, a branch of philosophy concerned with the nature of being, and the people who build medical ontologies are, in a very real sense, engaged in applied metaphysics. They are asking questions like: What is a disease? Is it a process? A state? A collection of symptoms? A social construct? And how do we represent that disease in a way that is both clinically useful and computationally tractable?
Beneath these standards organizations sit the technology vendors—the Epic Systems, the Cerner Corporations, the Allscripts, the countless startups and established firms that build electronic health records (EHRs), clinical decision support systems, and health information exchanges. These vendors implement the standards, often imperfectly, often with proprietary extensions that fragment the very interoperability the standards are meant to achieve. They are the ones who must translate the elegant abstractions of ontology into the messy reality of software development, user interfaces, and hospital workflows.
Then there are the healthcare providers themselves—the physicians, nurses, pharmacists, and allied health professionals who use these systems every day. They are the end users, the ones who click the boxes, who select the codes, who (sometimes grudgingly) conform their clinical thinking to the rigid structures of the data model. They are also, paradoxically, the ones whose clinical thinking the data models are meant to support. This tension—between the fluid, intuitive, often narrative nature of clinical reasoning and the rigid, categorical, often reductive nature of structured data entry—is one of the central dramas of healthcare informatics.
And then there are the patients. Us. You and me. We are the subjects of these ontologies, the sources of the data, the beneficiaries (or victims) of the systems they enable. We are the ones whose diseases are classified, whose symptoms are coded, whose treatments are recorded, whose privacy is protected (or violated), whose lives are potentially saved—or lost—by the quality of the information that flows through these hidden architectures.
Finally, there are the artificial intelligences. The large language models, the machine learning algorithms, the neural networks that are increasingly being trained on this data, that are increasingly being asked to make sense of it, to find patterns in it, to predict outcomes, to recommend treatments. These AIs are the newest actors on the stage, and they are both the greatest beneficiaries and the greatest stress tests of healthcare ontologies and data models. They need structured data to learn from, but they also promise to extract structure from unstructured data. They need ontologies to understand context, but they also threaten to make ontologies obsolete by learning implicit relationships directly from raw text.
This is the cast of characters. A diverse, often fractious, always evolving ensemble. And their interactions—cooperative, competitive, sometimes downright antagonistic—shape the future of medicine.
The What: Peeling Back the Layers of Meaning
Let me now dig deeper into what these things actually are, because I have given you the surface definition, and the surface is never enough.
An ontology, in its most rigorous form, is composed of several key elements. There are classes, which are the categories of things—“Disease,” “Symptom,” “Drug,” “Patient.” There are instances, which are the specific things that belong to those classes—“John Smith’s Type 2 Diabetes,” “the headache John Smith had yesterday,” “the metformin he is taking.” There are properties, which describe the attributes of classes and instances—“has onset date,” “has severity,” “is treated by.” There are relationships, which describe how classes and instances relate to one another—“Type 2 Diabetes is-a Diabetes,” “metformin treats Type 2 Diabetes,” “John Smith has Type 2 Diabetes.”
And then there are axioms, which are the formal rules that constrain and define the ontology—“if a patient has Type 2 Diabetes, then that patient has Insulin Resistance,” or “if a drug treats a disease, then that drug is indicated for that disease.” These axioms allow the ontology to support logical inference, to deduce new facts from known facts, to catch contradictions, to ensure consistency.
A data model, meanwhile, is composed of entities, attributes, and relationships. An entity is a thing that we want to store information about—a Patient, an Encounter, a Lab Result. An attribute is a piece of information about that entity—a Patient has a name, a date of birth, a medical record number. A relationship is a connection between entities—a Patient has many Encounters, an Encounter includes many Lab Results.
The data model defines the schema, the structure of the database. It says that a Patient table must have a Name field, and that Name field must be a string, and it must not be null. It says that an Encounter table must have a foreign key referencing the Patient table, ensuring that every encounter is associated with a patient. It says that a Lab Result table must have a LOINC code, ensuring that the test is identified using a standardized terminology.
But here is where it gets interesting, where the ontology and the data model begin to intertwine like the double helix of DNA.
The data model is syntactic. It cares about structure, about format, about whether the data fits into the predefined slots. The ontology is semantic. It cares about meaning, about context, about whether the data makes sense in the real world. The data model says: “This field must contain a string.” The ontology says: “That string represents a diagnosis of diabetes, which implies certain clinical facts, which triggers certain decision support rules, which suggests certain treatments.”
Together, they form a complete system of representation. The data model ensures that information can be stored, retrieved, and transmitted. The ontology ensures that information can be understood, reasoned about, and acted upon.
And in the age of AI, this distinction between syntax and semantics becomes crucial. Because modern AI—particularly large language models—has become remarkably good at syntax. It can read and write human language with fluency that would have seemed magical a decade ago. But it is still, in many ways, semantically shallow. It can parrot medical terminology without understanding the clinical reality behind it. It can generate plausible-sounding diagnoses that are completely wrong. It can miss the subtle, contextual cues that a human clinician would catch in an instant.
This is why ontologies remain essential, even in the age of AI. They provide the semantic grounding, the formal representation of medical knowledge, that AI lacks. They are the bridge between the statistical patterns that AI learns and the causal, mechanistic understanding that medicine requires.
The When: A Brief History of Medical Classification
When did all this begin? When did we start trying to systematize medical knowledge, to force the chaotic, organic mess of human disease into neat, hierarchical categories?
The answer, unsurprisingly, is: a very long time ago.
The earliest known medical classifications date back to ancient Mesopotamia and Egypt, where diseases were catalogued on clay tablets and papyri. The Edwin Smith Papyrus, from around 1600 BCE, is essentially a structured case report, listing symptoms, diagnoses, and treatments in a systematic fashion. Hippocrates, in ancient Greece, developed the theory of the four humors—blood, phlegm, black bile, yellow bile—which was, in its way, an early attempt at a pathophysiological ontology, a model of how the body worked and why it fell ill.
But the modern history of medical classification begins in the nineteenth century, with the work of Jacques Bertillon, a French statistician who developed the Bertillon Classification of Causes of Death in 1893. This was the precursor to the International Classification of Diseases, which was adopted by the World Health Organization in 1948 and has since become the global standard for mortality and morbidity statistics.
The ICD is, at its heart, a taxonomy—a hierarchical classification of diseases and health conditions. It is not, strictly speaking, an ontology in the modern, formal sense. It does not have the rich relational structure, the logical axioms, the machine-readable semantics of something like SNOMED CT. But it is an ontology in the broader sense: a shared conceptualization, a common language for talking about disease.
SNOMED CT itself emerged in the late twentieth century, born from the merger of several earlier terminologies, including the Systematized Nomenclature of Pathology (SNOP) and the Systematized Nomenclature of Medicine (SNOMED). It was designed from the ground up to be computable, to support not just human readability but machine reasoning. It introduced the concept of “compositional post-coordination,” allowing users to combine multiple concepts to express complex clinical ideas—“fracture of femur due to osteoporosis,” for example, can be composed from the concepts “fracture,” “femur,” and “osteoporosis.”
The twenty-first century has seen an explosion of biomedical ontologies, driven by the genomics revolution, the rise of systems biology, and the increasing digitization of healthcare. The Gene Ontology, launched in 1998, provided a structured vocabulary for gene function that has become indispensable for genomic research. The Foundational Model of Anatomy, developed by the University of Washington, created a comprehensive, spatially-aware model of human anatomy. The National Cancer Institute Thesaurus (NCIt) mapped the complex landscape of oncology. The Human Phenotype Ontology (HPO) standardized the description of disease symptoms. The Ontology for Biomedical Investigations (OBI) structured the metadata of scientific experiments.
And then came the Semantic Web, Tim Berners-Lee’s vision of a web of data that machines could understand and reason about. The Resource Description Framework (RDF) and the Web Ontology Language (OWL) provided the technical standards for building and sharing ontologies on the web. BioPortal, maintained by the National Center for Biomedical Ontology, became a repository for hundreds of biomedical ontologies, searchable, browsable, and interoperable.
This is the timeline, the arc of history. From clay tablets to cloud-based knowledge graphs. From the four humors to formal ontologies in OWL. It is a story of increasing abstraction, increasing formalization, increasing computational power. And it is a story that is far from over.
The Where: The Geography of Data
Where does all this happen? Where are these ontologies and data models deployed, used, contested?
The obvious answer is: everywhere healthcare is practiced, researched, or administered. But let me be more specific.
In the hospital, the ontology is embedded in the electronic health record. When a physician selects a diagnosis from a dropdown menu, they are using a terminology—perhaps SNOMED CT, perhaps ICD-10, perhaps a local variant—that is part of a larger ontological system. When they order a lab test, the test is identified by a LOINC code. When they prescribe a medication, the drug is identified by an RxNorm code. The data model of the EHR determines how this information is stored, how it is linked to other information, how it can be retrieved and displayed.
In the laboratory, the ontology governs the identification of tests, the reporting of results, the interpretation of findings. A “glucose” test is not just “glucose”—it is “Glucose in blood by Glucose oxidase method,” with a specific LOINC code, a specific reference range, a specific unit of measurement. The data model of the laboratory information system ensures that this result is associated with the correct patient, the correct encounter, the correct ordering physician.
In the pharmacy, the ontology identifies drugs, their ingredients, their dosages, their routes of administration, their interactions, their contraindications. RxNorm maps brand names to generic names, generic names to ingredients, ingredients to drug classes. The data model of the pharmacy system tracks prescriptions, dispenses, administrations, ensuring that the right patient gets the right drug at the right dose at the right time.
In the research institute, the ontology structures the design of clinical trials, the collection of data, the analysis of results. The Ontology for Biomedical Investigations ensures that experiments are described in a standardized, reproducible way. The data model of the clinical data management system captures patient demographics, interventions, outcomes, adverse events, all structured according to regulatory standards like CDISC (Clinical Data Interchange Standards Consortium).
In the public health agency, the ontology enables surveillance, epidemiology, population health management. ICD codes are used to track disease burden, to identify outbreaks, to allocate resources. The data model of the surveillance system aggregates data from hospitals, laboratories, vital records, creating a picture of the health of the population.
In the insurance company, the ontology drives billing, reimbursement, fraud detection. ICD codes determine the diagnosis-related group (DRG), which determines the payment. The data model of the claims system processes millions of transactions, linking providers, patients, diagnoses, procedures, payments.
And in the AI lab, the ontology provides the training data, the ground truth, the semantic constraints that guide machine learning. The knowledge graph, built from ontological relationships, becomes the substrate for graph neural networks, for semantic search, for explainable AI.
This is the geography of data. A vast, interconnected landscape, spanning the globe, touching every aspect of healthcare. And like all landscapes, it is contested, fragmented, sometimes beautiful, often ugly.
The Why: Why Does Any of This Matter?
Why should you care? Why should anyone who is not a healthcare informaticist, not a data modeler, not an ontologist, give a damn about any of this?
I will give you three reasons.
First, because your life depends on it.
Not metaphorically. Not hyperbolically. Literally.
When you go to the emergency room with chest pain, the physician needs to know your medical history. They need to know your allergies, your medications, your previous diagnoses. If that information is trapped in a silo, encoded in a proprietary format, inaccessible because of incompatible data models, then the physician is flying blind. They might prescribe a drug that interacts fatally with your current medication. They might miss the fact that you have a history of aortic dissection. They might waste precious minutes searching for information that should be at their fingertips.
Interoperability—the ability of different systems to exchange and use information—depends on shared ontologies and data models. Without it, healthcare is a collection of isolated islands, each speaking its own language, each hoarding its own data. With it, healthcare is a connected continent, where information flows freely, where care is coordinated, where patients are safer.
Second, because the future of medicine depends on it.
We are entering an era of precision medicine, where treatments are tailored to individual genetic profiles, where AI predicts disease before symptoms appear, where virtual clinical trials test drugs in silicon before they ever touch a human body. All of this depends on data. Massive amounts of data. Data from genomics, from proteomics, from metabolomics, from imaging, from wearables, from EHRs, from everywhere.
But data without structure is noise. Data without meaning is useless. You cannot train an AI on a million patient records if those records are inconsistent, incomplete, incompatible. You cannot find the genetic variant that predicts drug response if your genomic data uses one terminology and your clinical data uses another. You cannot discover a new biomarker if your “disease” is defined differently in every dataset.
Ontologies and data models provide the structure, the meaning, the consistency that makes big data medically useful. They are the difference between a haystack and a library. Between a hoard and a collection. Between noise and signal.
Third, because justice depends on it.
Healthcare data is not neutral. It reflects the biases, the inequalities, the power structures of the society that produces it. If your ontology classifies “race” as a biological category rather than a social construct, you may perpetuate racist medical practices. If your data model does not capture social determinants of health—housing, education, employment, environment—you may miss the root causes of disease. If your AI is trained on data that underrepresents certain populations, it may fail those populations when they need it most.
Ontologies and data models are not just technical artifacts. They are political artifacts. They encode values, assumptions, worldviews. They determine what is visible and what is invisible, what is counted and what is ignored, what is treated and what is neglected. Building them well, building them justly, is an ethical imperative.
The How: The Mechanics of Meaning
Now let me take you deeper, into the mechanics of how these things actually work. Because I have told you what they are, and why they matter, but I have not yet shown you the gears turning, the pistons pumping, the intricate machinery of meaning.
Let me start with a concrete example.
Imagine a patient, let’s call her Maria, who presents to her primary care physician with fatigue, increased thirst, and frequent urination. The physician suspects diabetes. They order a fasting blood glucose test, which comes back at 140 mg/dL. They diagnose Maria with Type 2 Diabetes Mellitus and prescribe metformin.
Now, let us trace how this simple clinical encounter is encoded in ontologies and data models.
First, the symptoms. “Fatigue,” “increased thirst,” “frequent urination.” In SNOMED CT, these are concepts: “Fatigue (finding),” “Polydipsia (finding),” “Polyuria (finding).” Each has a unique identifier, a definition, a set of relationships to other concepts. “Polydipsia” is-a “Abnormal thirst.” It is-associated-with “Diabetes mellitus.” It has-finding-site “Structure of thirst center.”
The physician does not need to know these identifiers. They simply select the terms from a dropdown menu in their EHR. But behind the scenes, the EHR is using the ontology to structure the data, to enable decision support, to ensure interoperability.
Next, the test. “Fasting blood glucose.” In LOINC, this is “Glucose [Mass/volume] in Serum or Plasma—Fasting,” with code 1558-6. The result, “140 mg/dL,” is recorded with a unit of measurement, a reference range, a timestamp. The data model of the laboratory information system stores this as a structured observation, linked to Maria’s patient record, linked to the encounter, linked to the ordering physician.
The diagnosis. “Type 2 Diabetes Mellitus.” In SNOMED CT, this is “Diabetes mellitus type 2 (disorder),” code 44054006. In ICD-10, it is E11.9. The EHR stores the SNOMED CT code for clinical purposes, the ICD-10 code for billing purposes. The ontology knows that Type 2 Diabetes is-a Diabetes Mellitus, which is-a Disorder of glucose metabolism, which is-a Endocrine disorder. It knows that Type 2 Diabetes is-treated-by Metformin, is-characterized-by Hyperglycemia, is-associated-with Obesity.
The prescription. “Metformin.” In RxNorm, this is “metformin,” with various codes depending on the exact formulation. The ontology knows that metformin is-a Biguanide, which is-a Oral hypoglycemic agent, which is-a Antidiabetic agent. It knows that metformin treats Type 2 Diabetes, that it is-contraindicated in Severe renal impairment, that it may-interact-with Iodinated contrast media.
Now, here is where the magic happens. Because all of this information is structured, formalized, linked, the EHR can do things that would be impossible with unstructured text alone.
It can trigger a clinical decision support rule: “Patient has Type 2 Diabetes and is prescribed Metformin. Check renal function before initiating therapy.” It can generate a quality measure: “Percentage of patients with diabetes who have had an HbA1c test in the past year.” It can support a research query: “Find all patients with Type 2 Diabetes who are taking Metformin and have a creatinine clearance >30 mL/min.” It can enable interoperability: Maria’s endocrinologist, across town, can access her record, understand her diagnosis, continue her treatment, without missing a beat.
And now, in the age of AI, it can do even more.
A machine learning model, trained on millions of such structured records, can learn to predict which patients are at risk of developing diabetes before they ever present with symptoms. A natural language processing model, reading the unstructured notes of Maria’s previous visits, can extract additional relevant information—her family history, her lifestyle, her social context—and add it to the structured record. A knowledge graph, built from the ontological relationships, can suggest novel drug combinations, identify potential adverse events, personalize treatment recommendations.
This is how it works. Not magic, but machinery. Not intuition, but inference. The slow, painstaking, often frustrating work of making medical knowledge explicit, formal, computable.
The Which: The Technologies That Make It Possible
Which technologies, specifically, enable all of this? Which systems, methods, discoveries form the substrate of healthcare ontologies and data models?
Let me enumerate them, not exhaustively, but representatively.
The Relational Database. Invented by Edgar Codd at IBM in 1970, the relational model remains the dominant paradigm for structured data storage. Tables, rows, columns, keys, joins—these are the building blocks of most healthcare data models. SQL, the structured query language, is the lingua franca of data retrieval.
The Semantic Web Stack. RDF (Resource Description Framework) for representing data as subject-predicate-object triples. OWL (Web Ontology Language) for defining ontologies with rich logical expressivity. SPARQL for querying RDF data. SKOS (Simple Knowledge Organization System) for representing thesauri and taxonomies. These standards, developed by the W3C, provide the technical infrastructure for sharing and linking ontologies on the web.
Description Logics. The formal mathematical framework underlying OWL and other ontology languages. Description logics allow for automated reasoning—checking consistency, computing subsumption, inferring implicit relationships. They are the engine of ontology-based inference, the reason why a machine can deduce that “Type 2 Diabetes” is a kind of “Disease” without being explicitly told.
Natural Language Processing (NLP). The bridge between unstructured clinical text and structured ontological data. Named entity recognition to identify medical terms. Relation extraction to identify relationships between terms. Text classification to categorize documents. Modern NLP, powered by deep learning and transformer architectures like BERT and GPT, has achieved remarkable accuracy in extracting structured information from clinical narratives.
Machine Learning and Deep Learning. The statistical engines that find patterns in healthcare data. Supervised learning for prediction and classification. Unsupervised learning for clustering and anomaly detection. Reinforcement learning for treatment optimization. Deep learning, with its multi-layered neural networks, for image analysis, genomics, and complex pattern recognition.
Knowledge Graphs. Graph databases like Neo4j, Amazon Neptune, and RDF stores like Apache Jena and GraphDB. These technologies represent data as nodes and edges, making them ideal for storing and querying ontological relationships. Knowledge graphs are increasingly used to integrate heterogeneous healthcare data, to power AI applications, to enable explainable reasoning.
FHIR (Fast Healthcare Interoperability Resources). The modern standard for healthcare data exchange, developed by HL7 (Health Level Seven International). FHIR defines a set of “resources”—Patient, Observation, Medication, Condition, etc.—that serve as a common data model for healthcare APIs. It is RESTful, web-friendly, and increasingly adopted worldwide. FHIR can carry ontological codes—SNOMED CT, LOINC, RxNorm—as standardized terminologies within its resources.
Blockchain and Distributed Ledger Technologies. Emerging technologies for ensuring the integrity, provenance, and security of healthcare data. While still largely experimental in healthcare, they promise to create tamper-proof audit trails, to enable patient-controlled data sharing, to support decentralized clinical trials.
Cloud Computing and Big Data Platforms. The infrastructure that makes large-scale healthcare data processing possible. Hadoop, Spark, Snowflake, Google BigQuery, Amazon Redshift—these platforms allow for the storage and analysis of petabytes of healthcare data, enabling population health research, real-world evidence generation, and AI model training at scale.
These are the tools. The hammers and chisels, the scalpels and sutures, of the informaticist’s trade. They are not glamorous. They do not make headlines. But without them, the edifice of modern healthcare informatics would collapse.
The Deeper Layers: Misconceptions, Limitations, and Unresolved Questions
I have painted a rosy picture so far. Perhaps too rosy. Let me now temper it with reality, with the grit and grime of actual practice.
First, the misconceptions.
Many people believe that ontologies are complete, perfect, universal. They are not. Every ontology is a perspective, a snapshot, a best effort at capturing a fragment of medical knowledge at a particular moment in time. SNOMED CT, comprehensive as it is, does not cover every possible clinical concept. It struggles with rare diseases, with novel treatments, with the messy, idiosyncratic reality of individual patients. It is updated regularly, but always lags behind the frontier of medical knowledge.
Many people believe that data models are neutral, objective, value-free. They are not. Every data model embeds assumptions about what is important, what is measurable, what is worth recording. The EHR data model, optimized for billing and regulatory compliance, often fails to capture the narrative richness of the clinical encounter, the subtle cues that experienced clinicians rely on. It privileges what can be coded over what can be felt.
Many people believe that AI will make ontologies obsolete, that machine learning can learn implicit structures directly from data without explicit formalization. This is partially true, and partially dangerous. Large language models can indeed learn statistical associations between medical terms, can generate plausible-sounding clinical text. But they lack the causal understanding, the logical consistency, the ethical grounding that formal ontologies provide. They can hallucinate—generate confident-sounding nonsense. They can perpetuate biases hidden in their training data. They can fail catastrophically in edge cases. Ontologies are not obsolete; they are more necessary than ever, as a check on the exuberance of AI, as a source of structured, verifiable, explainable knowledge.
Now, the limitations.
Ontologies are expensive to build and maintain. They require domain expertise, logical rigor, and continuous curation. SNOMED CT costs millions of dollars annually to maintain. The Gene Ontology relies on a global community of volunteer curators. Smaller institutions, poorer countries, underfunded domains cannot afford to build their own ontologies, leaving gaps in the knowledge landscape.
Data models are hard to change. Once a database schema is established, once millions of records have been entered, modifying the structure is a herculean task. Legacy systems, built on outdated data models, persist for decades, dragging down innovation, fragmenting interoperability.
Standardization is slow, political, and often contentious. Different countries, different institutions, different specialties have different terminological preferences, different coding practices, different regulatory requirements. Harmonizing them is a diplomatic as much as a technical challenge. FHIR, for all its promise, is still not universally adopted. HL7 v2, a standard from the 1980s, still dominates much of healthcare messaging.
And finally, the unresolved questions.
How do we represent uncertainty, vagueness, and probability in ontologies? Clinical knowledge is rarely black and white. A diagnosis is often a probability, not a certainty. A treatment recommendation is often a trade-off between risks and benefits, not a binary decision. Traditional ontologies, built on classical logic, struggle with this fuzziness. Fuzzy ontologies, probabilistic ontologies, are active research areas, but far from mature.
How do we balance privacy and utility? Healthcare data is among the most sensitive personal information. Yet its utility for research, for public health, for AI training, depends on aggregation, sharing, and sometimes de-identification. Finding the right balance is an ongoing ethical and technical challenge.
How do we ensure that AI, trained on ontologically structured data, remains explainable, trustworthy, and aligned with human values? As AI systems become more complex, more autonomous, more embedded in clinical decision-making, the need for transparency, accountability, and ethical governance becomes ever more urgent.
These are the deep waters. The places where the map grows vague, where the machinery creaks, where the future remains unwritten.
The Bigger Picture: Where This Leaves Us
I began this essay by asking you to imagine a city of data, a metropolis of medical information without a map, without addresses, without a common language. I want to end by asking you to imagine something else.
Imagine that city again, but now with its hidden architecture revealed. The ontologies are the street signs, the addresses, the directories, the common language that allows every building, every resident, every transaction to be located, understood, connected. The data models are the roads, the pipes, the wires, the infrastructure that allows information to flow smoothly, reliably, efficiently. The AI is the traffic system, the public transit, the autonomous vehicles that navigate the city with increasing sophistication, but always, ideally, guided by the map, constrained by the rules, accountable to the citizens.
This is the vision. Not yet achieved. Perhaps never fully achievable. But worth striving for.
Because the ultimate purpose of all this machinery—the ontologies, the data models, the standards, the technologies—is not to replace human judgment, not to automate medicine, not to reduce the patient to a collection of codes. It is to augment human capability, to free clinicians from the drudgery of information management so they can focus on the art of healing, to empower patients with knowledge and agency, to accelerate research and discovery, to make healthcare more precise, more personalized, more equitable.
The ontology is not the territory. The data model is not the patient. The AI is not the physician. They are tools, maps, instruments. They extend our reach, but they do not replace our touch. They organize our knowledge, but they do not generate our wisdom. They process our data, but they do not feel our pain.
And yet.
And yet, in an age of information overload, of genomic complexity, of AI possibility, we need these tools more than ever. We need them to be robust, to be just, to be wisely designed and carefully governed. We need the philosophers and the engineers, the clinicians and the patients, the policymakers and the public, to engage in the hard, unglamorous work of building and maintaining this hidden architecture.
Because when you walk into that hospital, when you sit in that examination room, when you hear the beep of the monitor and the rustle of the physician’s coat, you are entering a world that is shaped, in ways you cannot see, by the ontologies and data models that run beneath the surface. They are there in the EHR that holds your history, in the lab system that reports your results, in the AI that suggests your diagnosis, in the research database that may one day cure your disease.
They are the hidden architecture of healing.
And they are, for better or worse, the foundation upon which the future of medicine will be built.
P.S. For those who wish to dig deeper, the following references and resources provide authoritative starting points:
- SNOMED CT: https://www.snomed.org/ — The most comprehensive clinical terminology in the world.
- LOINC: https://loinc.org/ — Standardized codes for laboratory and clinical observations.
- RxNorm: https://www.nlm.nih.gov/research/umls/rxnorm/ — Standardized nomenclature for clinical drugs.
- UMLS: https://www.nlm.nih.gov/research/umls/ — The Unified Medical Language System, integrating over 200 biomedical vocabularies.
- FHIR: https://www.hl7.org/fhir/ — The modern standard for healthcare data exchange.
- Gene Ontology: http://geneontology.org/ — The standard for gene function annotation.
- BioPortal: https://bioportal.bioontology.org/ — A repository of biomedical ontologies.
- Description Logics: Baader, F., Calvanese, D., McGuinness, D., Nardi, D., & Patel-Schneider, P. (Eds.). (2003). The Description Logic Handbook: Theory, Implementation and Applications. Cambridge University Press.
- Healthcare Data Modeling: Hernandez, M. J., & Viescas, J. L. (2013). SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL (3rd ed.). Addison-Wesley Professional.
- AI in Healthcare: Topol, E. J. (2019). Deep Medicine: How Artificial Intelligence Can Make Healthcare Human Again. Basic Books.
- Ethics of Medical Ontologies: Rector, A. (2004). “Medical informatics.” In The Blackwell Guide to the Philosophy of Computing and Information (pp. 267–281). Blackwell Publishing.
Word Cloud
Related reading
Selected by shared topics and section, with closer publication dates breaking ties.
