Component
ProviderSynch
A pull API that returns a health-history summary when a prescription is transmitted — so the pharmacist and the prescriber are looking at the same clinical picture.
Why this exists
This is the direct answer to step six. Everything that goes wrong in count-based analysis goes wrong because two facts are missing at the point of decision: what is wrong with the patient, and what the clinician is trying to achieve.
A pharmacist receiving a prescription for an unusual quantity has, today, essentially no way to answer those questions in the time available. They can see the prescription, and they can see the state monitoring record, which is another list of prescriptions. What they cannot see is the diagnosis, the treatment plan, or the six things that were tried first. So the decision defaults to the number — and the pharmacist, who is also under institutional pressure, refuses or delays.
That is not a failure of anyone’s judgment. It is a failure to give them anything to judge with.
How it works
- Triggered by prescription transmission, so it arrives when the decision is being made rather than in a report afterwards.
- Pull, not push. The summary is retrieved on request against the specific transaction, rather than the program broadcasting patient records to anyone who might want them. That is a data-minimization choice and it is deliberate.
- Summary, not a record dump. Diagnoses relevant to the prescription, current treatment plan, prior therapy tried, relevant comorbidities and co-prescriptions.
- Two-way. A pharmacist who sees something the prescriber should know — an interaction, a duplicate therapy, a supply problem — has a route back that is not a phone tag chain.
The co-prescription view matters more than it sounds. Risk in this population is rarely about one drug. Benzodiazepines, sedating antihistamines, muscle relaxants, sleep agents and psychiatric medication all contribute, and no single prescriber usually sees the whole list.
What this is not
It is not a surveillance feed. The summary answers a question about a specific prescription for a specific patient at a specific moment. It is not a standing subscription to somebody’s medical record, and it is not a population dataset that an agency can query about individuals.
It is not a decision engine. ProviderSynch does not approve or deny anything. It gives two licensed professionals the information to make their own decision, which is a different thing and a deliberately more modest one.
It is not a way to build a case. The purpose is to make an unusual-looking prescription explicable when it has an explanation. Most of the time it will.
Questions this raises
How is this different from a prescription drug monitoring program?
A monitoring program tells you what was prescribed. ProviderSynch tells you why. They answer different questions and the second one is the one that resolves an ambiguous count. We support monitoring programs and set out their evidence, including its limits, on the PDMP page. Also see what a pharmacist can actually see.
Who decides what goes in the summary?
The clinical scope is agreed with the agency and its clinical owner before deployment, and it is deliberately narrow — relevant to the prescription in front of the pharmacist, not everything known about the patient. Minimization is a design rule here, not a setting. See data governance and our note on data minimization in practice.