Quick answer

Get a proper digital test workflow in place first, and only then think about AI. The sample gets a barcode, the test joins a queue with statuses, the lab technician records cell counts directly on the slide image, the physician adds a description and approves the result, and the system produces a PDF for the patient. Every step leaves a trace in a log. When all of this runs on the clinic's own server, patient data never leaves the building. Without a structured workflow like this, there's no data that image analysis could ever learn from.

We use the cytology testing system we built for Civilmed as the example. This post is a general guide to digitising a lab workflow, with no patient data. It is not legal or medical advice.

What nasal cytology is, and why it needs a procedure

Nasal cytology is a simple, cheap and non-invasive way to assess inflammation of the nasal mucosa. Cells are collected from the nose, the slide is stained with May-Grünwald-Giemsa, and it's read under an optical microscope. On the slide you can identify normal cells (ciliated and mucinous), inflammatory cells (lymphocytes, neutrophils, eosinophils, mast cells), and also bacteria and fungal hyphae (Gelardi et al., 2016).

The proportions of these cells form patterns that help the physician distinguish allergic from non-allergic rhinitis and, among the non-allergic forms, eosinophilic, mast cell, mixed and neutrophilic types (Heffler et al., 2018). The authors of that review make a point that matters for digitisation: the method is underused partly because there's no consensus on methodology. Counts can be reported as percentages, absolute values or on a semi-quantitative scale, and within one lab the same approach must always be used.

The lesson for the software: there's no off-the-shelf “universal” cytology. The system has to run the test the way a particular lab does, with its forms, scales and sign-off path.

Where a paper workflow breaks down

Whatever the clinic, a paper or half-paper test workflow has a few typical weak spots:

  • Sample identification. A handwritten tube label is a chance for a mix-up every time it's copied.
  • Counting. A tally counter and a sheet of paper next to the microscope give you numbers, but not which cells were counted.
  • Status. Who knows which tests are waiting for assessment and which for a signature? Usually whoever has the pile on their desk.
  • Retyping. The result starts on paper, goes into a word processor, then into the clinic's system. Each copy is a chance for an error.
  • Change history. On paper it's hard to reconstruct who changed an assessment, and when.

Good digitisation removes each of these weak spots, rather than just moving the form onto a screen.

A digital test workflow in four steps

Here's the journey of one test in the Civilmed system: a lab technician takes a nasal sample, stains the slide and counts the cells, and an ENT specialist describes and approves the result.

1. Test queue

Once the tube's barcode is scanned, the test appears on the list. Its status moves from collected through in analysis to awaiting approval, and the counters at the top update on their own. The queue is the first thing the lab sees: what's waiting, what's in progress, what needs a signature.

2. The slide up close

The screen shows the slide image after staining. The lab technician marks cells in three colours (eosinophils, neutrophils and epithelial cells), and each marker goes straight into the counter below the image. A count is no longer an abstract number on a sheet: every unit in the counter has its place on the image, and you can go back to it.

3. Semi-quantitative assessment

The counts set the assessment scales, and the doctor adds a description and recommendations. The ENT specialist gets a ready picture of the case and can focus on what needs their expertise.

4. Approval

One click from the doctor: the result is approved, the test's timeline is closed with a signature, the patient's PDF is ready, and on the list the test moves to approved. The system runs on the client's server, with an audit log.

StepOn paperIn the systemWhat the lab gains
Sample intakeHandwritten tube labelBarcode scanned into the queueNo retyping of identifiers
QueueA pile on the deskLive statuses and countersYou can see what's waiting and on whom
CountingTally counter, paper sheetMarkers on the image, counter below itEvery number has a place on the slide
AssessmentHandwritten or word-processedScales set by the counts, physician's description in the systemConsistent format across tests
ApprovalSignature on a printoutApproval in the system, PDFResult ready at once, with history
Change historyHard to reconstructAudit logWho did what, and when

Data that stays inside the clinic

Test results are health data, a special category of personal data under the GDPR (Article 9). The Civilmed system runs on the client's server, so slide images, counts, descriptions and results stay inside the clinic's network.

Polish law sets concrete requirements for medical records systems. The Minister of Health's regulation on the types, scope and templates of medical records and how they are processed (§ 1) requires, among other things, that the system holding the records ensures (ISAP, in Polish):

  • integrity of the content and metadata, meaning protection against changes outside documented procedures;
  • access for authorised people and protection against everyone else;
  • identification of whoever creates the record or makes an entry or change, along with the scope of the change;
  • the time each record and entry was made;
  • printing, and export of all data in standards (such as HL7 or DICOM) so it can be restored in another system.

The same regulation (§ 4) sets out how records are signed: for example with a qualified electronic signature, Poland's trusted profile signature or an e-ID signature, and internal records also through the system's own mechanisms. Which method fits a given document is worth settling with the clinic's lawyer. An audit log and in-system approval don't replace that analysis, but without them it's hard to meet the requirements on identification and timing. Other countries have their own rules, and the same design principles apply.

For labs that want to demonstrate quality formally, the reference point is ISO 15189:2022, which sets requirements for quality and competence in medical laboratories (ISO). Software doesn't get you accredited, but it makes the test workflow much easier to document.

Where AI fits in

In the Civilmed system, the lab technician marks the cells and the physician approves the result. There's no automated cell classification, and we don't claim there is. But a digital workflow has a consequence worth understanding before anyone proposes “AI for cytology”.

No data, nothing to learn from. An image analysis model needs thousands of images annotated under one procedure, with a confirmed result. A paper workflow doesn't produce that. A digital one, where every marker has its place on the image and every result carries a physician's signature, could, subject of course to consent, anonymisation and the clinic's own decision. We explain how object recognition in images works in computer vision explained.

Diagnostic software is a medical device. The IVDR covers, among other things, software that the manufacturer intends for the in vitro examination of specimens from the human body to provide information, for example on a disease process or state (IVDR, EUR-Lex). Qualification depends on the intended purpose set by the manufacturer, and the MDCG 2019-11 guidance (revised in June 2025) explains how to work it out for software. A tool that assesses a slide on its own for diagnosis therefore needs clinical validation and a conformity assessment, not just a good model.

A sensible order. First the digital workflow and clean data. Then, if the lab wants it, a prototype analysis as a research tool, compared against human assessment and kept away from patient results. Only at the end comes the decision on whether to pursue a medical device at all. That's how we work in our R&D lab: we test a technology before it becomes a product.

How to start: from a process map to the first test in the system

Digitising a lab doesn't start with picking technology. It starts with talking to the people who run the test. In practice, the order looks like this:

  1. Process map. We write out one test's journey from collection to result: who takes the tube, who stains, who counts, who describes, who signs, and where the result goes.
  2. Forms and scales. We gather every form in use and agree on one counting method and one assessment scale. That's a decision for the lab and its physicians, not for developers.
  3. Statuses and permissions. We agree on the states a test can be in and who may move it forward. The lab technician doesn't approve results; the physician doesn't need to scan tubes.
  4. Result template. We design the PDF so the patient and the referring doctor get what they need, in a consistent format.
  5. Tests on fictional data. Before the first patient goes into the system, the whole workflow runs on sample data.
  6. A parallel period. For the first few weeks, it's worth comparing results from the system with the old way of working.

Lab digitisation checklist

  • The current test workflow is written down: who does what, when, and on which document.
  • One counting method and one assessment scale, used for every test.
  • The sample is identified by barcode from collection to result.
  • A queue with statuses visible to the whole lab.
  • Counts recorded in the system, ideally linked to a place on the slide image.
  • The physician's description and recommendations in the system, with no retyping.
  • Approval and signature in line with medical records rules (settle this with a lawyer).
  • The result PDF generated by the system.
  • An audit log: who changed what, and when.
  • Data export in standard formats.
  • A server inside the clinic's network, with backups, updates and access control.
  • Data for any future image analysis only after consent, anonymisation and the clinic's decision.

Running non-standard tests?

Every lab has its own procedures, forms and sign-off paths. We build systems that take each test from sample to signed result the way that lab works, on its own server. The four steps of the Civilmed system, each with an animation, are on the Civilmed case study page. Another example from medical imaging is our PACS with an in-browser DICOM Viewer.

Sources