A patient communication layer does not replace a RIS, LIS or PACS. It reads the finalised report, produces a plain-language version, and returns it for delivery through whatever channel already exists. The clinical systems remain the source of truth, the report itself is never modified, and integration is typically read-only at the point of report finalisation. This is why it can usually be added without a migration.
The most common reason patient communication projects stall is not cost or clinical scepticism. It is a reasonable belief among IT teams that anything touching the reporting stack means a migration, a vendor negotiation and a year of work. For this category of tool, that is usually not true, and this piece explains why.
Where the layer sits
Think of it as sitting after reporting and before delivery. The radiologist or pathologist finalises the report exactly as they do today. At that point, the finalised text is passed to the communication layer, which returns a plain-language version. Your existing delivery mechanism, whether that is a portal, email, WhatsApp or print, then sends both. Nothing upstream changes.
| Stage | Owned by | Changes? |
|---|---|---|
| Acquisition and study management | Modality, PACS | No |
| Reporting and sign-off | RIS, LIS, reporting workstation | No |
| Finalised report stored | RIS, LIS | No. Remains the authoritative record |
| Plain-language version generated | Communication layer | New step, read-only input |
| Delivery to patient | Existing channel | Sends both documents instead of one |
The three integration patterns
In practice, one of three approaches fits almost every centre.
1. Message-triggered
Where the RIS or LIS already emits a result message on finalisation, that message triggers generation. This is the cleanest option when the infrastructure supports it, because it uses a pathway that already exists and requires no change to clinical workflow.
2. Direct API call
Your delivery application calls the communication layer directly when it is about to send a report. Suitable where a patient app or portal is already in place and you control that codebase. The integration burden sits with the delivery layer, not the clinical systems.
3. Delivery-side integration
Where the report reaches patients through a messaging provider, integration happens at that layer. Common for centres running WhatsApp-first delivery, and it keeps the clinical stack entirely untouched.
What IT should ask before anything else
- Is the integration read-only with respect to the clinical record? Anything that writes back to the report should face a much higher bar.
- What data leaves our environment, where is it processed, and where is it stored?
- What is the retention period, and can it be set to zero retention after generation?
- Is patient data used for model training, and can that be excluded contractually rather than by policy?
- What happens on failure? If the layer is unavailable, does report delivery continue normally? It must.
- What audit trail exists of what was generated and delivered for each patient?
What this does not solve
Integration is the easy part, and vendors emphasise it because it demonstrates well. The harder questions are clinical: what oversight exists, what the measured error rate is, and where the boundary sits between simplification and clinical judgement. Those are covered separately in what AI can and cannot safely do in patient communication. A clean integration with poor clinical governance is a worse outcome than no integration at all.
