The Ontology Is the Freeway. The AI Apps Are the Cars.

Wound care is debating which AI applications to adopt while the road underneath them remains unbuilt.

AI
ontology
interoperability
WCODS
wound care
Author

Zwelithini Tunyiswa

Published

April 13, 2026

I was at SAWC Spring 2026 in Charlotte last week. The energy around AI in wound care was unmistakable. Session after session, conversation after conversation, the field is genuinely excited about what artificial intelligence might do for clinical decision support, documentation, image analysis, and outcome prediction.

Not once did I hear a conversation about the infrastructure those applications are being built on.

That silence is the problem I want to name.

Nobody expects an automaker to build its own highway network. The road is public infrastructure, funded and governed collectively, because the alternative is obviously absurd: private roads with incompatible lane widths, connecting to nothing, owned by whoever moved fastest. Cars compete on speed, efficiency, and features. None of that competition requires reinventing the road.

Wound care AI is, right now, every vendor pouring their own concrete.

The imaging platforms, the documentation systems, the billing engines, the EHRs: each has its own definition of what a wound is, what a valid observation looks like, what “healing” means. They connect to nothing outside themselves. And every time a health system changes platforms, they are not just switching software. They are repaving.

This is the infrastructure problem the field is not talking about. We are debating which AI applications to adopt while the road underneath them remains unbuilt. Without a shared, public ontology, every AI application in wound care is a car without a highway: powerful in isolation, unreliable at scale, and dangerous when it confidently navigates terrain it was never taught to read.

The good news is that this problem is solvable. But only if the field commits to building the road before the cars multiply beyond any hope of coordination.

What We Mean by Ontology

An ontology is not a glossary. A glossary tells you what words mean. An ontology tells you what things are: what kinds of things exist, what properties they have, and how they relate to each other. It is a formal, machine-readable commitment to a shared reality.

The technology industry has solved this class of problem many times. TCP/IP defines how data moves across networks: every device manufacturer, every application developer, every cloud provider builds on top of it without reinventing it. USB and Thunderbolt define how peripherals connect to computers: Apple, Dell, and Lenovo all compete on hardware design, but their ports speak the same language. Nobody argues that these standards stifle competition. They are precisely what makes competition meaningful, because they move it to the layer where differentiation actually matters.

Wound care data has no equivalent. There is no TCP/IP for wound observations, no USB standard for how an assessment plugs into an analytics pipeline. Every system speaks its own dialect. When you try to connect them, nothing works.

An ontology is that standard. In wound care, it means answering questions like:

What makes a wound a wound, as distinct from a skin observation? What is the identity of a wound across time: is the same lesion at week 4 the same object as at week 0? What is the formal definition of complete wound closure, and under what measurement conditions is an observation valid? What is the relationship between a pressure injury and the staging system that applies to it, and how does that differ from the relationship between a diabetic foot ulcer and its grading system?

These are not abstract philosophical questions. They are engineering questions. Without answers to them, encoded in a shared, open standard, every system that touches wound data is building on a different foundation.

The Current State Is Worse Than Most People Realize

We have terminologies, including ICD-10, SNOMED CT, LOINC, and HCPCS, that cover wound-related concepts in partial and overlapping ways. We have documentation systems that capture wound observations. We have imaging platforms that segment tissue. We have billing systems that encode products and procedures.

None of these talk to each other at the level of meaning.

A wound photograph in an imaging platform, a PUSH score in a long-term care EHR, a debridement CPT code in a practice management system, and a healing narrative in a nursing note are all describing the same wound, but no system treats them as observations about the same object. The wound has no persistent identity across the care continuum. It exists as a collection of disconnected records that clinicians mentally integrate because no machine has been given the tools to do so.

This is not a data quantity problem. Wound care generates enormous volumes of data. It is a semantic coherence problem. We are drowning in observations with no shared frame of reference for what they are observations of.

What a Public Ontology Would Provide

A formal, openly licensed wound care ontology would establish, at minimum:

A persistent wound object. A wound is a thing that exists over time, has a location on a body, has an etiology, and progresses through states. It is not a form field. It is not a billing code. It is an entity, and every observation, intervention, and outcome should be anchored to it.

Etiology-specific structure. A pressure injury and a diabetic foot ulcer are both wounds, but they have different staging systems, different risk factors, different healing physiology, and different evidence bases for intervention. An ontology makes those differences explicit and enforces them formally.

Measurement conditions as first-class objects. An area measurement taken after debridement under standardized lighting is not the same kind of observation as one taken during a cursory wound check. The conditions of measurement are part of the meaning of the measurement. Without encoding this, no healing trajectory analysis is trustworthy.

Formal endpoint definitions. What does “complete wound closure” mean, precisely? That definition should be machine-readable, version-controlled, and citable.

An action layer. The most forward-looking component: formal definitions of what can be done to a wound object, and by whom. Escalation to vascular surgery. Initiation of a prior authorization workflow. Closure of a wound episode. These are not just documentation events; they are state transitions that should be governed by the same ontology that defines the wound.

Why It Must Be Public

Highways are not privately owned. Not because private roads are technically impossible, but because a road that serves only one carmaker’s vehicles is not really a road. It is a moat.

This is not an argument against proprietary software in wound care. Vendors should build their own schemas, their own data models, their own application logic. That is exactly where differentiation belongs: in the vehicles, not in the road surface. USB defines the connector; it says nothing about what you plug into it. TCP/IP defines how packets move; it says nothing about what applications run on top. The standard enables the ecosystem. It does not constrain it.

A documentation platform can have a richer assessment model than the standard requires. An analytics product can extend the schema with proprietary derived metrics. An AI application can operate on its own internal representations. None of that is a problem, as long as every system can map to a shared semantic layer that makes its outputs legible to every other system.

The problem arises when those proprietary layers have no shared semantic foundation beneath them. When “wound healing” means something different in every system, when a debridement observation in one platform cannot be understood by any other, the ecosystem is not competing on clinical intelligence. It is competing on whose definition of reality becomes dominant. That is a race with no clinical winners.

What the field needs is a unifying semantic layer that sits beneath all proprietary implementations. A shared definition of what a wound is, what a valid assessment looks like, what endpoint terms mean in a regulatory context. Vendors map their internal schemas to this layer. AI systems are validated against it. Trial protocols cite it. The ontology does not constrain what vendors build on top. It ensures that what they build can be understood outside their own walls.

A public ontology, openly licensed, developed under a transparent governance process, makes that possible. The infrastructure becomes a commons. The cars compete. The road belongs to everyone.

Why AI Will Hit a Ceiling Without This

The enthusiasm at SAWC was real, and so are the early results from AI in wound care. Image segmentation is improving. Documentation burden is coming down. Predictive flags for wound deterioration are beginning to show clinical value. None of that should be dismissed.

But there is a ceiling approaching that the field has not yet seen, because most AI deployments are still operating within a single system, on a single institution’s data, under a single vendor’s definition of a wound. The moment you try to generalize, the limitations of building on incoherent foundations become unavoidable.

Consider what AI actually requires to function reliably at scale.

A model trained to predict healing trajectory needs to know that the wound at week 0 and the wound at week 8 are the same object. If the underlying data has no persistent wound identity, the model is learning correlations between disconnected observations, not longitudinal dynamics. It may perform well in validation on the same system’s data and fail immediately when deployed elsewhere.

A model trained to recommend debridement needs to know what debridement means: which type, under what clinical conditions, applied to what wound state. If “debridement” is a free-text field in one system and a CPT code in another and an uncoded nursing note in a third, the model is not learning about debridement. It is learning about documentation patterns. Those are not the same thing, and the difference becomes visible when the model encounters a documentation pattern it was not trained on.

A model designed to flag wounds at risk of infection needs a coherent definition of periwound status, exudate character, and tissue composition, applied consistently across assessments. Without formal measurement conditions encoded in the data, the model cannot distinguish a clinically meaningful change from a documentation artifact or a lighting difference in the photograph.

These are not edge cases. They are the central challenge of deploying AI in a domain where the training data is semantically incoherent. The models will appear to work in pilots. They will degrade silently in production. And because wound care outcomes play out over weeks and months rather than milliseconds, the feedback loop is slow enough that the degradation will be difficult to attribute to its true cause.

There is a further problem at the population level. The most valuable applications of AI in wound care are not single-institution tools. They are multi-site models that learn from the full heterogeneity of wound presentations across care settings, patient populations, and treatment protocols. That kind of model requires data that can be pooled across systems. Data can only be pooled across systems if those systems share a semantic foundation. Without an ontology, there is no pooling. Without pooling, the models are perpetually underpowered for the questions the field most needs to answer.

The ceiling is not algorithmic. The best model architectures in the world cannot compensate for training data that does not know what it is talking about. The ceiling is semantic. And the only way through it is to build the road.

The Clinical Trial Connection

I want to be specific about one dimension of this that is underappreciated: the cost to clinical research.

Every wound care trial redefines its primary endpoint. Not because trialists are negligent, but because there is no authoritative, machine-readable definition to cite. Complete wound closure, percent area reduction, time to first closure: these concepts appear in hundreds of protocols with subtle but consequential variations in measurement conditions, confirmation requirements, and follow-up windows. Meta-analysis is compromised. Regulatory review is complicated. Replication is impeded.

The WCCC’s Clinical Trial Standards and Reporting Workstream exists precisely because the field recognized this problem. The output of that work, including consensus definitions, reporting standards, and methodological guidance, should not remain in PDF form. It should be encoded as executable schema: machine-readable, version-controlled, and integrated with the statistical analysis plans that reference it.

An open wound care ontology is the infrastructure that makes that possible. The standards work already done by the WCCC, by NPUAP/EPUAP, and by HL7’s wound care FHIR implementation guide is the raw material. What is missing is the formal ontological layer that makes it actionable.

We Are Starting to Build It

Talk is insufficient. The problem has been described in wound care informatics circles for years. What the field needs now is a working artifact that others can adopt, critique, extend, and build against.

To that end, in my role at the Wound Care Collaborative Community I have (re:) launched the Wound Care Open Data Standard (WCODS), an open, community-driven specification for wound care data, released under the Apache 2.0 license. The project now lives at github.com/woundccc/wound_care_open_data_standard.

The design philosophy is deliberate. Rather than producing another PDF of guidelines, WCODS encodes the standard as executable schema: typed, validated, and machine-readable. The target formats are JSON, for interoperability with EHRs and clinical APIs, and Parquet, for large-scale analytics pipelines and registries. The schema is generated from formal data models, which means a wound assessment either conforms to the standard or it does not. There is no ambiguity at the point of validation.

The initial roadmap covers the core wound object and its properties, etiology-specific staging structures, assessment models with measurement conditions, and formal endpoint definitions grounded in regulatory guidance. The goal for version 1.0 is a specification stable enough for pilot implementation in clinical software, research registries, and statistical analysis plans submitted to the FDA.

Apache 2.0 means vendors can adopt it commercially without restriction. There is no reason for a proprietary implementation when the standard is free.

A Call to the Field

I am not arguing that this is easy. Ontology development requires sustained collaboration between clinicians, informaticists, statisticians, and regulators. It requires governance structures that can resolve disagreements about meaning without degenerating into politics. It requires funding that is not contingent on commercial return.

But continuing to layer AI systems onto semantically incoherent data infrastructure is not a stable equilibrium. The failures will come, and they will be clinical. A risk score built on a miscoded wound etiology. A healing trajectory model trained on inconsistently measured area observations. A prior authorization agent that approves the wrong product because “debridement” means something different in the system it queries than in the system it learned from.

The work starts now. The repository is open. The question is whether the clinical, academic, and regulatory communities can organize around a shared commitment to semantic infrastructure before the commercial pressures of AI adoption make that coordination prohibitively difficult.

I believe we can. And I believe the evidence of that will be measured in commits, not consensus statements.

github.com/woundccc/wound_care_open_data_standard


Comments or questions? Add them under the LinkedIn post.