Co-Medic
Challenge
A GP practice already holds almost everything it needs to manage chronic disease well. The problem is where it lives: specialist letters, lab reports and free-text notes, accumulated over years, written by different people in different formats. Answering something as basic as “which of my patients are drifting towards diabetes and have not been screened?” means opening records one by one.
So the work does not get done, or it gets done for the patients who happen to walk in. Prevention and chronic care are exactly the areas where being systematic matters most, and they are the first casualties of unstructured data.
Co-Medic set out to fix that: population management and prevention built from the practice’s existing record data, without asking anyone to change how they work or to re-enter anything.
Solution
We worked with Co-Medic as their technical partner — shaping the platform’s technical direction, building the data-structuring pipeline at its core, and helping set up the in-house development team that would carry it forward.
Making unstructured records machine-readable
The heart of the platform is a pipeline that reads medical documents — KMEHR messages, PDFs, plain letters — and extracts what is clinically meaningful: diagnoses, medication, lab results, vital signs, social history.
A specialist letter on the left, the extracted clinical resources on the right — medication, vital signs and lab results, each typed and coded. Shown with fictitious example data.
Extraction alone is not enough, because “hypertension” and “hypotension” are one letter apart and mean opposite things. Each extracted item is therefore linked to standard terminology — SNOMED CT for clinical concepts, LOINC for lab data, exchanged over FHIR — and carries a confidence score, so the system can defer instead of guessing when a term is ambiguous.
The letter processor
The most visible result is the brievenverwerker: incoming specialist correspondence is processed automatically, and the practice sees what is new — new treatment advice, new care items, new medication — instead of reading every letter to find out.
The letter processor: each incoming letter reduced to what changed — new treatment advice, new care items, new medication. Patients and letters shown are fictitious.
From records to a population
Once the data is coded, a practice can be asked questions it could never ask before: who has type 2 diabetes, what were their last HbA1c and eGFR values, who is on metformin, whose blood pressure is drifting, who is overdue for screening.
An example population overview for diabetes screening: diagnosis, HbA1c, eGFR, medication and blood pressure per patient. All patient data shown is fake, for illustration only.
That is the point of the whole exercise. Co-Medic reports that their approach surfaces 3.7× more prediabetes cases than standard practice-software reporting — patients who were already in the records, just not findable.
Privacy as an engineering problem
Medical data does not leave the practice casually. Alongside the platform we built a dedicated de-identification service — a Dutch clinical de-identification model running in isolation — so that documents can be anonymised for research and evaluation without exposing patient identity.
Results
- A production pipeline that turns years of unstructured correspondence into coded, queryable clinical data
- Specialist letters processed automatically, surfacing only what changed for a patient
- Population and prevention views built entirely from data the practice already had
- Standards-based throughout — SNOMED CT, LOINC and FHIR rather than a proprietary schema
- An in-house development team set up and able to take the platform forward independently