From biomedical text to research evidence

Start with the claim the system is allowed to make

A biomedical retrieval system can recognize the right terminology while misunderstanding the statement around it. A document may mention a condition as a hypothesis, a negated finding, a family history, or a criterion that excludes a participant. Extracting the same concept identifier from each sentence does not make those sentences interchangeable evidence.

This note examines the public methods behind that problem: preserving source context, distinguishing kinds of assertions, and evaluating retrieval against a defined research question. It describes an illustrative research workflow, not the architecture or current implementation of a private project. No clinical model, diagnostic result, treatment recommendation, or dosing function is presented.

This article describes how concept extraction could fit into that foundation without overstating what it contributes. QuickUMLS is a candidate component for investigation, not an integration claimed to be complete. The proposed path is from source text to a contextualized mention, then to a research assertion with provenance and a defined evidence type. Each transition needs its own evaluation.

Recognizing a concept is one operation among several

QuickUMLS is a system for medical concept extraction and linking using approximate matching against UMLS terminology. Its output can help identify candidate concepts in text. Using it responsibly still requires the relevant UMLS access and terminology conditions; the National Library of Medicine's knowledge-source page describes access to the distributed resources.

The next operation is contextual interpretation. In the synthetic sentence “the protocol excludes participants with condition X,” recognizing condition X is useful for indexing the protocol. It does not justify adding a positive condition observation to a participant record. The subject is an eligibility rule, and the statement concerns exclusion. A pipeline that discards that distinction can create a plausible graph with false edges.

Keep the original span and surrounding sentence next to the concept candidate. Record the terminology version, matching configuration, and any ambiguity. Negation, temporality, experiencer, and study context require explicit handling appropriate to the task. If the system cannot resolve an ambiguity, preserve alternatives or request review. Forcing every mention into one definitive entity makes the graph look clean at the cost of losing uncertainty.

Use an ontology to constrain meaning, not manufacture it

An ontology can define the types of things the workspace represents and the relationships permitted between them. A Study has a population description; a Measurement has a unit and observation time; an Assertion has a source and an evidence category. These structures help distinguish a research paper's conclusion from a participant observation or a development task's result.

JSON-LD provides a way to express linked data in JSON, while SHACL describes constraints for RDF graphs. Neither standard determines whether a biomedical assertion is scientifically justified. Structural validation can reject a missing unit or an invalid relationship type; it cannot convert a weak study into strong evidence.

The illustrative record below represents a statement about a study's eligibility criteria. It intentionally does not invent a patient or a clinical observation. A richer implementation would bind the document revision and exact source span, then record who or what interpreted that span. The important choice is to represent the kind of statement before connecting it to downstream models.

1{
2  "assertionType": "StudyEligibilityRule",
3  "subject": "synthetic-study-protocol",
4  "relation": "excludesCondition",
5  "conceptCandidate": "terminology-concept-placeholder",
6  "sourceSpan": "the protocol excludes participants with condition X",
7  "interpretationStatus": "requires-review",
8  "evidenceType": "protocol-statement"
9}

The lexical baseline is useful because its limits are visible

A lexical retriever provides a useful starting point because its matching behavior can be inspected. A query succeeds when the documents use terms the method can recognize; synonyms, abbreviations, and ambiguous language expose its limits. The baseline should have a documented tokenization policy and a fixed corpus. Its simplicity makes it easier to identify what a more elaborate representation actually contributes.

An index also needs a clear relationship to its sources. Retain document revisions and source locations so a retrieved passage can be checked. When the corpus changes, test whether the reader can distinguish current evidence from a stale copy. These are general evaluation requirements: they do not prescribe a particular storage engine, indexing algorithm, or internal deployment design.

A sensible next experiment compares this baseline with lexical retrieval plus concept expansion and, separately, a biomedical encoder. Keep the corpus, query set, and access boundary fixed. Otherwise a gain attributed to the encoder may actually come from indexing more documents or changing the chunk boundaries. Record exactly which source passage answers each research query so that evaluation concerns evidence retrieval rather than surface similarity alone.

Prediction-time availability belongs in the data contract

If the workspace later supports predictive studies, every feature needs an observation time and an availability time. A value can describe an earlier event while arriving only after the intended prediction. A retrospective table that joins on event date alone can accidentally provide information that the deployed model would never have had.

For an illustrative study, define a prediction cutoff and require both the event and the availability conditions to hold before a feature enters the model. Preserve missingness and delayed reporting rather than filling gaps with future values. Participant-level and temporal separation may both matter, depending on the question. The final split design must follow the intended use rather than a convenient random partition of rows.

Dataset permission and population scope belong in the same contract. Access to a dataset does not imply permission for every downstream use, and a model's behavior on one study population does not establish clinical effectiveness elsewhere. These are research-design constraints that should shape ingestion before model training begins. This essay proposes that contract; it does not report a clinical experiment.

Keep engineering completion separate from scientific evidence

A research record should distinguish a successful software check, an inconclusive experiment, and a result that does not support the hypothesis. Record the question, inputs, method, outcome, and remaining uncertainty. Where an experiment fails to run, explain what prevented evaluation. Where it runs correctly but finds no benefit, preserve that result without treating it as an engineering defect.

A record of completed work is not independent scientific validation. A software test may establish that prohibited documents are excluded or that a structured export follows a schema. An experiment may establish a retrieval result on a specific query set. A clinical claim requires a different evidentiary process. The interface and article language should keep those outcomes distinct.

The immediate useful deliverable is a small adjudicated set of research questions, source spans, concept mentions, and context labels. Include negated statements, eligibility rules, historical mentions, and ambiguous abbreviations. Compare systems on the same cases and retain the disagreements for review. The foundation becomes valuable when it helps explain a mistake and design the next study, not when its terminology graph merely becomes larger.

Reviewers should see the source sentence and the extracted interpretation together. Asking them to approve an isolated concept identifier removes the context needed to detect the error. Preserve disagreements between reviewers as labeled uncertainty until they are resolved; automatic consensus through majority voting is not a substitute for understanding why the sentence was ambiguous.