AI for life sciences software

Building software around the model

Most of the work is around images or text. We use vision models on biological images and language models on scientific and clinical text, and the output might be a score, structured data, or something a specialist needs to review. We build the rest of the application around that output: the data handling and the workflow it moves through. On top of that sits the review step, the audit trail, and whatever controls the task needs.

A model that works in a notebook isn't finished software. Someone still has to build it into the real application and connect it to live data and the actual workflow. Only then is there anything for a person to review.

What happens next depends on the workflow. On one system the model produces a measurement for a pathologist, while on another it proposes an ingredient mapping that stays unapproved until someone clears it. An automated action needs more care, because there is no one there to catch a bad result.

The software produces a number or marks a region, and the person using it makes the decision. Slide scoring is one example. The measurement needs to be consistent, and validation needs to show that it is accurate and repeatable.

Ingredient mapping works this way. The software puts a result in front of someone who accepts or rejects it, new mappings stay unapproved until an administrator clears them, and the review happens inside the application.

The software takes an action without someone checking it first. That needs more scrutiny in a life sciences setting. When a client wants that kind of automation, we look at what happens if the model is wrong and what it could affect, then work out how that gets recorded.

Choosing the model

We work with models from OpenAI and Anthropic, and with models such as Llama, Qwen and DeepSeek that can run inside a client's environment. Where the model runs and what data it sees shape that choice, along with latency, cost, and how much accuracy the application actually needs, since life sciences data can be idiosyncratic and we work through those details before picking the model. A narrow task often just needs a smaller model. There is little reason to run a larger one if it does the same job.

For applications that answer questions over documents, we normally put a retrieval layer in front of the model, and it finds the relevant passages and sends only those passages along. Document level access control limits the answer to material the user is allowed to see. Knowledgewise uses this pattern and runs inside the client's environment rather than as a shared service.

For images and structured data, we record the input, model version and output. That gives each result clear provenance and makes it possible to trace it back to the source data.

Model selected, product still to build

We build the viewer, pipeline, review flow, audit trail, and the integrations needed to fit it into the systems the team already uses.

From prototype to the application

The prototype may already prove that the model works. From there we put it into the application and work through the error cases. We also decide how the result gets reviewed and handle deployment, along with the evidence the environment needs.

The software is headed for regulated use

Our regulatory and validation work runs alongside the build. A reference set is replayed as the software changes, and the results are kept with the release evidence.

Do you build models or integrate them?

We usually integrate an existing model and build the software around it. We train from scratch when there is a clear reason to, but most projects use fine tuning, prompting, retrieval and validation.

How do you validate an AI component for regulated use?

We validate the model step as part of the software around it. A reference set contains known inputs and expected outputs, and we replay it whenever the software changes. The results are kept as evidence, with our regulatory and validation team involved when the work is headed for a submission.

What happens when the model is wrong?

Some outputs will be wrong. The system needs a way to catch them before they are used, and depending on the workflow, that may be a review queue, a flag, or a threshold that sends the result to a person. On the dermatitis platform, new ingredient mappings stay unapproved until an admin clears them.