Building patient report communication in-house is usually underestimated because the visible work, turning clinical language into plain language, is the smallest part of the job. The larger and permanent costs are clinical review, multilingual coverage, safety boundaries and ongoing maintenance. Building makes sense when patient communication is central to your product strategy. It rarely makes sense when it is an operational fix.
Once a diagnostic chain accepts that the gap between report and consult is a real operational cost, the next question is predictable and reasonable: why would we not build this ourselves? You already have a technology team. Report data is already in your systems. Language models are available to anyone. On the surface it looks like a two-month project.
This piece is written by a vendor, so treat it accordingly. What follows is the honest version, including the circumstances where we would tell you to build.
What you are actually building
The prototype is genuinely easy. Feed a report into a language model with a prompt asking for plain language, and you will get something impressive within a day. The difficulty is everything between that prototype and something you are willing to put in front of a patient who has just been told they have a mass.
| Component | Looks like | Actually involves | One-off or ongoing? |
|---|---|---|---|
| Plain-language conversion | A prompt | Prompt engineering, output constraints, tone calibration, handling of hedged clinical language | Ongoing |
| Clinical safety review | A checklist | A named clinician reviewing outputs, an error log, a defined escalation path, sign-off on every change | Ongoing, and the largest hidden cost |
| Boundary enforcement | Telling it not to diagnose | Systematic testing that it never assesses severity or recommends action, including on adversarial inputs | Ongoing |
| Multilingual coverage | Translation | Per-language clinical review, because a mistranslated hedge is a clinical error, not a typo | Ongoing, multiplied per language |
| Integration | An API call | RIS, LIS or PACS integration, delivery channel, identity matching, audit trail | Mostly one-off |
| Model maintenance | Nothing | Model versions change and outputs drift, so regression testing is permanent | Ongoing |
Note the right-hand column. Almost everything that matters is recurring. The build cost is not the problem. The maintenance cost is, because it never converts into a finished asset and it competes permanently with whatever else your technology team should be doing.
The question is not whether you can build it. Most competent teams can. The question is whether you want to own a permanent clinical-safety maintenance obligation that is not your core business.
When building is genuinely the right call
There are three situations where we would tell you to build, and mean it.
- Patient communication is your differentiator, not your overhead. If you intend to compete on patient experience as a product, and to keep investing in it for years, owning it is defensible. Outsourcing your differentiator is a bad trade.
- You already carry clinical-safety infrastructure. If you have clinical governance, an incident process and clinicians whose job description includes reviewing patient-facing output, the marginal cost of building is far lower than it is for most centres.
- Your requirements are genuinely unusual. A rare modality mix, an unusual regulatory position, or a data residency constraint no vendor meets can make building the only honest route.
When buying is the right call
Buying tends to win when patient communication is a problem you want solved rather than owned. Specifically: when your technology team is small enough that this project displaces revenue work; when you need multiple languages, since per-language clinical review is where in-house builds most often stall; when you want to know the cost in advance rather than discovering it over eighteen months; and when you would struggle to name the clinician who will personally sign off on patient-facing output every time the model changes.
The middle path most chains actually take
Build versus buy is usually presented as permanent, and it is not. The common sequence is to buy first to establish whether patient communication moves the metrics you care about, such as report-related call volume, and revisit the decision once you have evidence. Deciding to build before you know whether the problem is worth solving at your organisation is the expensive version of this choice.
A short evaluation checklist
- Name the clinician accountable for patient-facing output, in either scenario. If you cannot, that is your answer.
- Count the languages you need today and in two years. Multiply the review burden accordingly.
- Ask what the system does when a patient asks whether their result is dangerous. The correct answer, built or bought, is that it directs them to a clinician.
- Decide what you will measure before you start, so the decision to continue is evidence-based rather than political.
- Write down the maintenance owner. Not the build owner. Projects fail at handover, not at launch.
