When we hear the word unstructured, we tend to think of something messy, chaotic, disorganized, or difficult to follow. That is understandable because, in everyday language, that is usually what the word implies.
But in healthcare, unstructured information does not necessarily mean messy information.
A discharge summary can be exceptionally clear. A specialist's note can be concise, logical, and clinically precise. A pathology report can make perfect sense to the clinician reading it. And yet all three may still be considered unstructured.
That distinction matters because healthcare's unstructured information problem is not fundamentally a problem of chaos. It is a problem of implicit structure. The meaning is often already there, and a human reader can understand it immediately. The challenge is that this meaning has not necessarily been represented in a consistent way that the systems around them can interpret, connect, and use.
A simple everyday example helps illustrate the difference.
Imagine a friend sends you a message saying: “Dinner next Thursday at 7pm at The Ivy.”
There is nothing messy or confusing about that information. You immediately understand that there is an event, when it is happening, and where you need to be.
Now compare that with the same information entered into a digital calendar. The event name, date, time, and location are placed into defined fields. The underlying information has barely changed, but something important has: the structure that you inferred automatically has now been made explicit for the system.
The calendar can now trigger a reminder, calculate travel time, display the event alongside the rest of your schedule, or pass the information to another application.
Healthcare information often works in much the same way. The meaning can be perfectly clear to the person reading it while still being embedded within language rather than represented in a form that another system can reliably understand and use.
So what does “unstructured” actually mean?
Consider a clinician reading the sentence: “Metformin stopped following deterioration in renal function.”
To a medical professional, this is not an unstructured or confusing statement. It contains several clear pieces of clinical information: the medication is metformin, its status has changed, and the reason for that change was deterioration in renal function. There is also a relationship between those facts: the change in renal function led to the medication being discontinued.
A clinician understands all of that without needing the sentence to be broken into fields.
A computer system may not.
Much of the structure exists within the meaning of the language rather than being explicitly represented as separate, connected clinical data. The system might initially see a string of text where the clinician sees a clinical event, its cause, its timing, and its significance.
That is the distinction at the heart of the issue.
Unstructured does not mean the information lacks structure to a human. It means that structure is not consistently represented in a way that systems can interpret and use.
The problem becomes bigger across the patient record
The challenge becomes even clearer when we stop looking at a single document and look at an entire patient history.
Healthcare information rarely exists in one place. A diagnosis may appear in a specialist's narrative note, while a medication change is recorded months later in a discharge summary. Laboratory results might sit in another system altogether, and a referral letter may contain important historical information that was never entered into the receiving organization's EHR. Another clinician may then describe the same condition using different terminology.
There may be nothing wrong with any of those individual pieces of information. Each could be accurate, well written, and clinically useful on its own.
The difficulty is that the patient's story is now spread across different documents, systems, formats, authors, and points in time. A clinician reviewing the whole record can begin to make connections between those pieces. They can understand that one event preceded another, that two different terms refer to the same condition, or that a medication change relates to a previous diagnosis.
Systems have traditionally been much less capable of doing the same.
The information is not necessarily disorganized. It simply lacks a common, explicit structure that connects the individual pieces together.
And when that structure remains implicit, clinicians are often left doing the work of connecting it themselves: finding the relevant records, reconstructing chronology, comparing sources, and deciding which pieces of information relate to one another. The consequence is not simply an information technology problem. It affects how quickly a clinician can understand a patient and what information is available at the point a decision needs to be made.
Myth 1: PDFs are unstructured
PDFs have almost become shorthand for unstructured healthcare information, but a PDF is simply a format.
A referral letter stored as a PDF might contain a diagnosis, current medications, previous procedures, allergies, laboratory findings, family history, and a clear explanation of why the patient has been referred. To the physician reading it, this may be an extremely well-organized clinical document.
The issue is that another system may not automatically understand that a particular medication belongs to this patient, that a procedure happened five years ago, or that a laboratory result is relevant to a specific diagnosis.
The clinical structure exists in the meaning of the document, but it has not necessarily been translated into something computationally usable.
This is very different from saying the information itself is unstructured.
Myth 2: Making information digital means making it structured
Healthcare has spent decades digitizing information. Paper records became scans, letters became electronic documents, clinical notes moved into EHRs, OCR made scanned text machine-readable, and search technology made large volumes of information easier to navigate.
Each of those developments created real value, but digitization and structuring are not the same thing.
There are several distinct steps between a paper document and clinically usable structured information.
Digitization makes the content electronically accessible. A scanned page can be stored, transmitted, and viewed on a screen.
OCR can convert the pixels on that page into machine-readable text.
Extraction and language processing can identify relevant concepts within that text, such as a medication, diagnosis, procedure, or laboratory result.
Clinical interpretation and semantic structuring go further. They establish what those concepts mean in context, how they relate to one another, when they occurred, and where they came from.
Take the same example: “Metformin stopped following deterioration in renal function.”
At the most basic level, a system can recognize the words metformin and renal function. At a more sophisticated level, it can identify metformin as a medication and renal deterioration as a clinical concept.
But genuine clinical structure requires more. It means understanding that metformin was previously being taken, that it was discontinued, that deterioration in renal function was the reason, that the event happened at a particular point in time, and that the information came from a particular source within this patient's record.
That progression matters because these stages are often grouped together under the broad label of “structuring data,” even though they represent very different levels of understanding.
Healthcare has become increasingly good at turning documents into digital information. The bigger challenge is turning the meaning contained within those documents into usable clinical information.
Myth 3: If information is inside an EHR, it must be structured
The opposite misconception is equally common. If information exists inside an EHR, it feels logical to assume that it is already structured.
Much of it is. A laboratory result can be stored against a defined test, a medication can appear in a medication list, and a diagnosis can be represented using standardized clinical terminology.
Healthcare has also developed sophisticated standards for representing and exchanging this information. Terminologies such as SNOMED CT and LOINC help create consistency in how clinical concepts and observations are represented, while interoperability standards such as HL7 FHIR provide common ways for systems to exchange structured clinical information.
These standards are essential.
But their existence does not mean that all of the information entering an EHR already arrives in that form.
EHRs still contain narrative notes, scanned documents, imported files, free-text fields, and information originating from external systems. Even when structured fields are available, important clinical context may remain embedded elsewhere in the record.
The distinction is important: the problem is not that modern healthcare standards are incapable of representing clinical meaning. The problem is that much of the information healthcare receives has not yet been translated into that representation.
A standard can define how a diagnosis, medication, or observation should be represented once it is structured. It does not, by itself, take the meaning contained in a referral letter, scanned chart, or narrative note and create that structure.
That is an upstream problem, and one we will return to later in this series.
The real distinction is not structured versus unstructured
Healthcare often frames the challenge as a binary: structured data on one side and unstructured data on the other. In reality, it is much more of a spectrum.
At one end, we have information that is easy for both clinicians and systems to understand, connect, and reuse. At the other, we have information whose meaning may be completely obvious to a clinician but remains embedded inside narrative language, documents, or disconnected systems.
The more useful question is therefore not simply, is this information structured? It is: can the meaning of this information be consistently understood, connected, and used?
Answering that question requires more than identifying individual clinical concepts. A medication needs to be connected to the patient, its dosage, status, and point in time. A diagnosis needs context. A procedure needs chronology. A laboratory result needs to be connected to the correct test and clinical episode. Information from one source needs to be understood in relation to information from another.
Provenance also matters. Clinicians need to know where information came from and be able to return to the original source when required. Without that connection, structure can create a new problem by separating the information from the evidence that supports it.
This is where healthcare information starts to move from simply being readable to being usable.
Healthcare needs a layer that makes implicit structure explicit
If the problem is implicit structure, the solution cannot simply be better document storage or better search.
Healthcare needs a way to take information arriving from different sources, recognize the clinical meaning within it, connect related information across the wider record, preserve chronology and provenance, and represent that information consistently enough that it can be used by clinicians and downstream systems.
That is the role of a semantic and clinical structuring layer.
Importantly, this does not replace the original document, the EHR, or interoperability standards. It sits between them, helping transform information from the form in which it arrives into a form that can participate more effectively in the rest of the digital health ecosystem.
This is where Realize-365 fits
Realize-365 was built around exactly this problem.
The platform collects clinical information from disparate sources and creates a consistent layer of structure across it. That means going beyond simply extracting text or identifying isolated clinical terms. Realize-365 interprets clinical information in context, connects it across the wider patient history, organizes events over time, and maintains links back to the underlying source.
The resulting information can then support structured clinical facts, longitudinal timelines, concise summaries, and different clinical views of the same patient history.
The source systems still matter. The original documents still matter. The EHR still matters. Interoperability standards still matter.
Realize-365 is not intended to replace them.
Its role is to help make the clinical meaning contained within them explicit enough to be understood together, and structured enough to be used more consistently across clinical workflows and systems.
Why getting the definition right matters
This might sound like a debate about terminology, but it is much more important than that. How we define the problem determines the solutions we build.
If we think unstructured healthcare information is simply messy text, we build better extraction tools. If we think the problem is paper, we digitize more records. If we think the problem is finding information, we build better search. If we think the problem is moving information between systems, we build better interoperability.
All of those things are valuable, but they solve different parts of the challenge.
The deeper issue is that healthcare information frequently contains enormous amounts of implicit clinical structure that systems cannot reliably see or connect. A physician can read the referral. A nurse can understand the discharge note. A specialist can interpret the historical record. The information already makes sense.
The challenge is making that same clinical meaning explicit enough that the technology supporting those professionals can understand it too.
Healthcare's unstructured information problem is therefore not really a problem of chaos.
It is a problem of meaning that has not yet been made explicit.
And that is an important distinction if we want to solve it.
In Part 2, we will look at what it actually means to structure healthcare information, and why digitization, extraction, interpretation, and true clinical structuring are fundamentally different things.