Anticoagulation follow-up is a specialist job, so it tends to get a specialist tool. And a specialist tool tends to mean a second place to type the same name, the same health insurance number, the same date of birth. That retyping is not a small tax. It is where the errors come from, and it is the reason good clinical software gets quietly abandoned.
The second-system tax
Count what it actually costs to keep a patient in 2 places. The name and the health insurance number get typed twice. The date of birth gets typed twice. When a patient moves, changes name, or turns out to have been entered with a transposed digit, the correction has to happen twice — and the second one is the one that gets forgotten.
The result is not that the specialist tool is wrong. It is that the 2 systems drift, and nobody can tell which one is right. A pharmacist who cannot trust the second screen stops opening it, and the tool that was bought to make the work safer becomes a thing that gets updated on Fridays.
This is a solved problem everywhere else in software. It is unsolved in community pharmacy mostly because the specialist tools and the dispensing systems are built by different companies who have never had a reason to talk.
What “integrated” should actually mean
The word gets used for almost anything, including a shared login page. 3 tests separate a real integration from a marketing one.
Does it open on the right patient? Not the right application — the right patient. If a pharmacist still has to search for someone they were already looking at, nothing has been integrated.
Does it sign in the right person? A shared account is easy to build and destroys the audit trail: every entry ends up attributed to whoever the account belongs to. If your record of who did what is going to mean anything, the launch has to name the individual.
Does it write anything? A read-only connection is a smaller promise and a much easier one to keep. A tool that can write into your dispensing record needs to be trusted very differently from one that can only be opened from it.
Why most add-on tools never get there
Usually because the integration is treated as a partnership rather than a specification. That means a contract, a certification programme, a fee, and a roadmap slot on both sides — which is a lot of process to justify for a button.
It also means the smaller vendor waits for the larger one, and the larger one waits for enough customers to ask. Nothing happens, and the pharmacist keeps typing.
What we published
We took the other approach and wrote the thing down. Retroact Connect is an open launch protocol: a pharmacy system signs a short-lived token with its own key, opens Retroact with it, and the pharmacist lands on that patient’s anticoagulation record already signed in under their own name.
There is no agreement to sign before building it, no certification to pass, and no fee. We hold only the vendor’s public key, which means we can never sign anything on their behalf — and a vendor can never reach a pharmacy that has not switched them on.
There is also a read-only FHIR R4 endpoint, so a pharmacy system can pull the INR results and recorded doses back into its own chart rather than asking anyone to look at them in 2 places.
What it deliberately does not do
Retroact does not accept clinical data through the API. Clinical entries are made by a named person in a session that person opened, because that is what makes an audit trail worth keeping.
Doses are published as a record of what was taken, never as an order. Retroact documents the dosing a pharmacist decided under their own written protocol. It does not recommend one, and the data it hands to another system must not be readable as though it had.
Questions
Does a pharmacy have to do anything?
Not to keep using Retroact. If you want your dispensing software to open it, forward the specification to your software vendor. Nothing reaches them until you switch the integration on from your own settings, and switching it off stops access immediately.
What can the pharmacy system read back?
The patient, the INR results, and the doses recorded — as FHIR R4 resources, read-only. INR results carry the LOINC code 6301-6, so they arrive as a recognised lab observation rather than a number in a text field.
Does this mean the software recommends doses?
No. Retroact records the dosing decided under the written protocol a clinic configures, and enforces the limits that protocol sets. The data published to another system is a record of what was taken, never an order or a recommendation.
What does it cost a software vendor to build?
A signed token. There is no library to adopt and nothing to certify. Most of the work is deciding where the button goes. The specification and the discovery documents are public, so a developer can confirm the whole thing exists before talking to anybody.