By industry
AI agents and automation for healthcare administration and pharmacy
We are not a clinical systems vendor and we do not build anything that decides what happens to a patient. What we do build is the administrative layer around care — scheduling, records retrieval, intake, stock and billing — which is where most of a clinic’s wasted hours actually sit, and where the failure modes are recoverable.
Two weeks to a written build plan · no obligation to build with us
- No clinical decisions, by design
- Admin onlyNo clinical decisions, by design
- Models can run inside your network
- On-prem optionModels can run inside your network
- Anything touching a clinical record
- Clinician signsAnything touching a clinical record
- To a written build plan, via the audit
- 2 weeksTo a written build plan, via the audit
Where the time goes
If two of these are true, there is something here
Written the way the people doing the work describe it, not the way a process document does.
The front desk is a switchboard
Booking, rescheduling, directions, opening hours, repeat prescription queries and "has my result come back". Most of those never need a clinician and all of them need a person right now.
Three systems that cannot see each other
Scheduling in one place, records in another, dispensing in a third, billing in a fourth. Staff bridge them by memory and by retyping.
No-shows are found out on the day
Reminders go out inconsistently, confirmations are not tracked, and an empty slot is discovered when the patient does not arrive.
Pharmacy stock is counted, not known
Expiry dates, batch numbers and near-expiry stock live on a shelf and in a book. Write-offs are discovered rather than predicted.
What we connect to
The systems you are already running
Healthcare integration is mostly a question of what your systems will let you read. We work with standard interfaces where they exist and exports where they do not.
- Clinical systems (read-only)
- HL7 v2
- FHIR APIs
- OpenMRS
- Vendor EHR export feeds
- DICOM metadata
- Practice and pharmacy
- Appointment / PMS platforms
- Pharmacy POS
- Inventory and batch systems
- Billing and claims tools
- Patient channels
- SMS gateways
- WhatsApp Business API
- Patient portals
- Web forms
What we build here
Five things worth building for healthcare & pharmacy
Each one names the systems it touches, because an integration that is not named is an integration nobody has thought about yet.
- 01
Scheduling and reminders that close the loop
Booking, rescheduling and cancellation handled in the patient’s own channel, with confirmations tracked and unconfirmed slots surfaced early enough to be refilled. Nothing clinical is discussed.
- Touches
- Appointment system · SMS / WhatsApp · calendar
- What changes
- Fewer empty slots, and a front desk that can talk to the people in front of it.
- 02
Intake and form capture
Registration details, history forms and consent captured before the visit and written into the practice system in the right fields, so the first five minutes of an appointment are not spent typing.
- Touches
- Web forms · practice management system · document store
- What changes
- Appointments start with the paperwork already done.
- 03
Records retrieval for staff
A staff-facing assistant that finds the document, the previous visit note or the result a clinician is looking for, with a link to the source record. It retrieves and cites; it does not summarise clinical judgement or suggest anything.
- Touches
- EHR / document store (read-only) · staff authentication
- What changes
- Less time hunting through systems, with the source always one click away.
- 04
Pharmacy stock, batch and expiry
Dispensing and receipts read into a live stock picture with batch and expiry tracked, near-expiry lines flagged while they can still be used or returned, and reorder points proposed from actual movement.
- Touches
- Pharmacy POS · inventory system · supplier catalogues
- What changes
- Write-offs become predictable, and shortages are seen before the shelf is empty.
- 05
Billing and claims preparation
Invoices and claim forms assembled from the visit record and coded against your existing rules, with anything incomplete or ambiguous routed to a person before submission rather than rejected afterwards.
- Touches
- Billing system · practice management · payer formats
- What changes
- Rejections fall because the gaps are caught before the claim leaves.
How it is put together
How a patient request is handled without touching clinical ground
The whole design turns on one classification, made early and conservatively: is this administrative or is it clinical? When in doubt, it is clinical.
- 01
Classify
Every inbound message is sorted into administrative, clinical or urgent before anything else happens. Uncertainty resolves upward — to a person — not downward.
- 02
Escalate immediately
Anything with urgency signals is handed to staff at once with the original message, and the patient is told plainly that a person is being contacted. No triage, no reassurance, no advice.
- 03
Identify
Administrative requests that need a record require the patient to be verified through your existing process first. Nothing personal is returned to an unverified contact.
- 04
Act within the admin boundary
Appointments, reminders, receipts, directions and form capture are handled directly. Prescriptions, results, advice and anything a clinician owns are never actioned.
- 05
Record
What was asked, what was disclosed, what was done and who approved it — kept for the same period as your other patient communication records.
Your data
What we will and will not do with it
Stated plainly, and without claiming a certification we do not hold. If a requirement here is harder than what is written, say so on the call and we will tell you whether it is buildable.
No diagnosis, triage, advice or clinical summarisation
We will not build a system that tells a patient what is wrong, how urgent it is, or what to do about it — and we will decline that scope even where a client is willing to accept the risk. Retrieval for clinicians cites the source record rather than interpreting it.
Patient data can stay entirely inside your network
Where patient information is involved we default to open-weights models running on your own infrastructure, so nothing leaves your environment. Hosted models are used only for content with no patient data in it, and only if you agree to that split explicitly.
We hold no healthcare certifications
We are not HIPAA-certified — no software company is, since HIPAA certifies programmes and not products — and we are not an accredited medical device developer. We build to controls your compliance officer sets and hand you the audit trail. If your requirement is a certified vendor, it is not us.
Proof
We have shipped pharmacy software that people actually buy through
Digital Pharmacy is a nationwide medical app for a German-owned operator — people buy from pharmacies across the country and reach doctors through it, and pharmacists run their inventory and take orders through a companion admin app. It also carries a machine-learning image search that identifies a medicine or a pharmacy from a photograph, which is the kind of narrow, checkable AI this sector should be buying. We have never built a hospital clinical system, and we will say so rather than imply otherwise — the administrative and commerce layer around care is where we have actually shipped.
- Pharmacy network in one app
- NationwidePharmacy network in one app
- ML to find a medicine from a photo
- Image searchML to find a medicine from a photo
- Customer and pharmacist admin
- Two appsCustomer and pharmacist admin
Technology
What this gets built with
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Interfaces
- FHIR
- HL7 v2
- REST adapters
- Scheduled exports
- Webhooks
- Models
- Self-hosted open weights
- On-prem inference
- Retrieval with citations
- Structured output
- Platform
- Django
- PostgreSQL
- Next.js
- Celery
- Docker
- Controls
- Role-based access
- Verified identity
- Audit log
- Data residency
- Retention rules
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 1–2
Sit with the work
We watch the process as it is actually done, not as the process document says. The output is a map of every step, which system it touches and how long it takes.
DeliverableProcess map and a shortlist of what is worth automating - 02Week 2–3
Design the access layer
Which systems get read, which get written to, what scope each credential carries, and which decisions stop for a person. Agreed in writing before anything is built.
DeliverableArchitecture and permission model - 03Week 3–8
Build against your real data
Built in your sandbox against real records, not a demo dataset. The write path goes through a review queue from the first day, so nothing lands in a live system unseen.
DeliverableRunning system in staging, with the review queue - 04Week 8–10
Run it beside the humans
It runs in parallel with the people doing the job. We compare the two outputs, fix what differs, and only then start letting the routine path through unattended.
DeliverableAgreement rate report and a go-live threshold - 05Ongoing
Hand over and watch
Source code in your repository, deployment in your accounts, cost and failure dashboards you can read without us. Support if you want it, not because you are locked in.
DeliverableRepository, runbook and monitoring
Why Devs Core
Three reasons that are checkable
We run two of our own products
Cadenza and Budge are ours. What an agent costs per run, where it fails and which decisions need a person came from operating them, not from a vendor deck.
The write path is reviewed by default
Anything that changes a record in a system of record goes through a queue a person can see. You choose what graduates to unattended, and when.
You own the code
Source in your repository, infrastructure in your accounts, model keys in your name. There is no runtime of ours you have to keep paying for.
Questions
Healthcare & Pharmacy — the questions we get asked
Can you build a symptom checker or a triage bot?
No. We decline that work. It is the one category in healthcare where a confident wrong answer causes direct harm, and no amount of disclaimer text changes the fact that patients read it as advice.
Is patient data sent to an AI vendor?
Not by default. Where patient data is involved we run open-weights models on infrastructure you control. If you are willing to use a hosted model for something with no patient data in it, that is a decision you make explicitly, in writing, per flow.
Are you HIPAA compliant?
HIPAA compliance is a property of your organisation and its programme, not a badge a development vendor holds. We build to the controls your compliance officer specifies — access control, audit logging, encryption, residency, retention — and we will sign a BAA where your counsel requires one. We do not claim to certify your compliance.
Can it read results and tell the patient?
It can tell a patient that a result has arrived and that the clinic will contact them. It does not disclose the content or characterise it. Releasing a result is a clinical act with a person attached to it.
What is the safest place for a clinic to start?
Scheduling and reminders. The data involved is minimal, the benefit is immediate and measurable in filled slots, and the worst failure is a duplicated message rather than a harmed patient.
Do you work with pharmacies separately from clinics?
Yes, and pharmacy is often the easier build, because stock, batch, expiry and reorder are inventory problems with a regulatory overlay rather than clinical ones. The dispensing decision stays with the pharmacist throughout.
Related
What healthcare & pharmacy buys most often
- Read more
Custom Software Development
The operational system underneath — the one the packaged software did not cover. React and Django, built to be handed over.
From $14,000 - Read more
AI Integration Services
The access layer between the software you already run and any AI model — so an agent can reach your ERP, CRM or helpdesk without being handed the keys.
From $8,000 - Read more
Process Automation
Replace the manual steps between two systems — the re-keying, the copy-paste, the spreadsheet that reconciles what neither system knows.
From $4,500 - Read more
AI Readiness Audit
Two weeks that end in a written plan: which processes are worth automating, what each would cost, and what has to be fixed first.
From $2,400
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com