001 Telemedicine
Telemedicine systems break where they touch the pharmacy.
A prescription leaves your platform and something outside your control has to accept it. When that fails it usually fails quietly, and the first person to find out is standing at a counter.
002 What we do here
The consult is the easy half.
Video, scheduling and notes are yours and they mostly work. The part that costs you money is everything that leaves the building.
Scope, in one screen
- What we do
- Repair and connect platforms that already have users Audits, security work, integrations, migrations, monthly care
- Prescribing
- Surescripts and ScripSure, in production Direct integrations we have built and still maintain
- The pharmacy side
- Ordering, inventory sync, order state you can read Queues that cannot lose an order, and a record of every attempt
- Stacks
- PHP, Node and Python Plus the front end on top and the hosting underneath
- Not our work
- Your clinical product, your roadmap, your day-to-day tickets
- Start here
- Write and tell us what breaks A written reply within one business day, from an engineer
The prescription that never arrived. Your system reported success because the message was accepted for delivery, not because a pharmacy received it. Those are two different events, and a lot of platforms only record the first one.
The refill nobody answered. Requests come back from the pharmacy and have to reach a prescriber who is still licensed, still at your practice, and still the right person for that patient. When one of those is no longer true the request does not bounce. It sits.
The order that was charged twice. A request timed out, something retried it, and the second attempt was treated as a new order. This is the most expensive failure on the page because it reaches your customer’s card statement before it reaches your logs.
The integration that passed the demo. It worked against the test partner and fails against the real one, and nobody can say which of the differences between them is the one that matters.
003 The specific ones
The networks people write to us about.
Named here because you searched for them. Every term is explained where it appears.
Surescripts. The network almost every US pharmacy is reachable through. We build direct integrations to it, which means your system sends and receives NCPDP SCRIPT — the standard message format prescriptions travel in — rather than paying a middleman to translate for you. The work that actually takes the time is routing: deciding which of several plausible pharmacy records is the one the patient means, and what your system does when the answer is ambiguous. We also do the engineering certification asks for, prepare the test cases and sit in the calls. The certificate is issued to you, not to us.
ScripSure. Consultation and full integration with both the Basic and Premium APIs. That includes EPCS — electronic prescribing of controlled substances, which adds identity proofing and two-factor signing on top of ordinary prescribing — along with formulary checks, which tell a prescriber what a patient’s insurance will actually cover before the prescription is written, and refill workflows, which are the requests coming back the other way. If you are choosing between Basic and Premium, that is a conversation worth having before you build, not after.
Pharmacy ordering. Where you are placing and tracking orders rather than prescriptions, the same three properties decide whether it is reliable. Orders wait in a queue until delivery is confirmed, so an hour of the other side being down is an hour of orders waiting rather than an hour of orders gone. Inventory sync reconciles instead of overwriting, so two systems disagreeing produces a flagged difference rather than a silent wrong number. And every order carries a state you can read without opening the database.
What we are not. We are engineers, not your compliance advisor. We establish what is true about your systems and we fix what is broken. Whether that satisfies a specific regulation for your specific business is a question for someone qualified to answer it. We sign an NDA before anything is opened, and a Business Associate Agreement where the work touches health information.
004 Money and messages
Charged twice, delivered never.
Two failures cost more than everything else on this page combined, and they have the same root: a message that was sent twice, or sent once and lost.
Duplicate charges. The fix is an idempotency key — a value your system attaches to a request so that sending it twice does the same thing once. The other side stores the key and returns the original result instead of doing the work again. Without one, every retry you add to make the system more reliable also makes double charges more likely.
Webhooks nobody verified. A webhook is a message another company sends to your system when something happens on theirs. It arrives as an ordinary request from the internet, which means anyone can send one. It has to be checked against a shared secret, and it has to be rejected if it is stale — a correctly signed message captured and replayed an hour later is still an attack.
Nothing watching. The connection fails on the 3rd and is discovered on the 28th when somebody reconciles the month. This is the difference between a bad afternoon and twenty-five days of manual reconstruction, and it is the cheapest of the three to fix.
005 What it costs
The same prices as everything else we do.
There is no healthcare surcharge. An audit is an audit whether the system prescribes or sells shoes.
Writing to us is free and a person answers within one business day. The audit is five business days and produces a written report you own and can hand to anyone, including the partner asking you difficult questions. Migration and integration work is quoted from that audit as one fixed number that does not grow. Every price is published.
If you already know which connection is broken and you only want that one made reliable, that is smaller work and can be quoted directly.
0FQ Questions people ask
Questions people ask about this
Have you actually done a Surescripts integration, or is this a capability page?
We have built them and we still maintain them. That is why this page names the parts that are tedious rather than the parts that sound good: the directory lookup that returns three plausible pharmacies, the message your test partner accepts and production rejects, the refill that arrives for a prescriber who left the practice.
Can you get us through certification?
We do the engineering that certification asks for, we prepare the test cases, and we sit in the calls. We cannot issue the certificate and we will not tell you that you are certified — that is between you and the network. What we can tell you is whether your system is ready, and what is left, in writing.
Our prescribing works. It just fails sometimes and we find out from support.
That is the common case and it is the cheapest thing on this page to fix. A connection that retries, records every attempt and raises an alarm on failure is usually a few days of work, and it does not require touching the rest of your platform.
Do you handle EPCS?
Yes. Electronic prescribing of controlled substances adds identity proofing and two-factor signing on top of ordinary prescribing, and most of the work is in the parts nobody demonstrates: what happens when the second factor times out, and whether the audit record survives it.
Do you sign a Business Associate Agreement?
Yes, and before anything is opened. If the system handles health information covered by HIPAA, we sign a BAA as well as the NDA. We are not your compliance advisor and we will not tell you the result satisfies a regulation, but the paperwork that lets you hand us the work is not the obstacle.
We are on a deadline with a partner. How fast can you tell us where we stand?
Five business days for the full audit. If the question is narrower — can this system send this message to that network — it is often answerable in a couple of days, and you get the answer in writing whether or not you go ahead.
0RL Related
The general version of these problems
Most of what goes wrong here is not specific to healthcare. These pages cover the same mechanisms without the vocabulary.
0GO If this sounds like you
Tell us what’s actually breaking.
Describe it in your own words. A person reads it and replies within one business day — what we think is happening and whether we’re the right people for it. Free, and a person is what’s at the other end.
Or read the work first.
Anonymized write-ups of real repair work on systems we were handed. Every one of them says what we would do differently, including the parts that did not go well.