Finance
A fintech MVP, kickoff to paid pilot in 12 weeks
12 weeks from kickoff to the first paying pilot customer
HealthcareSaaS Platform Build6 min read
How a behavioural health group replaced fax-and-phone intake with a portal designed against the audit it would face
Referrals arrived by fax and were re-keyed by nine coordinators. A previous vendor's portal had been rejected in security review, because protected health information would have lived in the vendor's account rather than the group's.
At a glance
- Client
- a multi-site behavioural health provider, roughly 300 staff across a dozen or so clinics, in the US Pacific Northwest
- Industry
- Healthcare
- Engagement
- SaaS Platform Build — time and materials
- Duration
- 9 months, then an ongoing support retainer
- Team
- 4 engineers, 1 architect, 1 integration specialist
- Built with
- Next.js, React, Node.js, PostgreSQL, AWS, React Native
What changed
47044days
median referral to first appointment, down from eleven, over two quarters
6926637122%
of referrals arriving digitally within two quarters of launch, from none
14711,593442720039500
coordinator hours a year removed from re-keying, across nine staff
Figures are as reported by the client over the period named in the body below, and were not independently audited by us.
Working on something like this?
Get an estimateThe short version
- The PHI boundary was drawn before any architecture was proposed — where data lives, who processes it, under which business associate agreement.
- The portal was built in the group's own AWS account, on their organisation, under their BAA. That was the reason the previous vendor's proposal had failed security review.
- Intake forms write to discrete EHR fields rather than attaching a PDF, which is the shortcut that makes a portal look finished and leaves the re-keying exactly where it was.
- A clinician review step sits in front of anything that writes to a chart. Nothing reaches a record without a person.
The problem
Referrals arrived by fax. Nine intake coordinators re-keyed them into an on-premise EHR, one at a time, and the median time from referral received to first appointment was eleven days.
Most of those eleven days were queue rather than clinical capacity. The clinicians had slots. The referrals had not reached the point where anyone could see the slots, because the referral was in a shared inbox and the audit trail for who had looked at it was whoever remembered.
- No patient-facing software of any kind. Intake, rescheduling, and paperwork were all phone calls, which meant they were all business hours.
- A previous vendor's portal had been rejected in security review, correctly — protected health information would have lived in the vendor's account under the vendor's controls.
- Nobody could answer who had seen a referral and when. In behavioural health that is not only an operational problem; a referral that goes quiet is a patient who does not come back.
What made it hard
What we did
1
Drew the PHI boundary on a whiteboard before proposing anything
Where the data lives, who processes it, which business associate agreement covers each hop, and what happens to it at the end. This is an architecture decision and it is cheapest at the start; it is also the single question the security committee had been asking and not getting answered.
2
Built in the group's own AWS account, under their BAA
Their organisation, their account, their key management, their retention policy. Our engineers had named, revocable access. The practical consequence is that the security review had a short answer to every access question, and the group can remove us without a migration.
3
Integrated over the HL7 v2 feeds that already existed
ADT and SIU through the interface engine already in place, with FHIR used only where the EHR vendor genuinely exposed it. Insisting on FHIR everywhere is a good way to spend six months on a vendor roadmap; the interface engine was there, it worked, and it was the shortest safe path.
4
Wrote intake to discrete EHR fields, not to an attached PDF
This is the decision the project turns on. A portal that emails a completed PDF into the EHR looks finished at demo and leaves nine coordinators doing exactly what they did before, with an extra step. Discrete field mapping is slower to build, involves a real conversation with the EHR vendor, and is the only version that removes the re-keying.
5
Put a clinician review step in front of every chart write
Nothing a patient types reaches a clinical record without a person approving it. This was not a compliance requirement; it was a clinical safety one, and the clinicians asked for it in the first workshop.
6
Retained audit logs under the policy they already had
Rather than inventing a new retention regime for the portal. A second policy is a second thing to defend at audit, and it is always the one nobody remembers to update.
Why HIPAA shaped the architecture rather than the paperwork
Compliance work that starts at the end is a documentation exercise pointed at a system that was not designed for it, and it is roughly three times the cost of designing it in. Access control, audit logging, minimum necessary access, and the encryption story are architectural properties. They are cheap in week one and expensive in month eight.
What we designed against is HIPAA. What we do not claim is compliance — that is a determination the group makes with its own counsel and auditors, and no vendor can hand it to you. What HIPAA ready actually requires sets out the distinction in full.
What changed
47044days
median referral to first appointment, from 11
6926637122%
of referrals arriving digitally within two quarters
14711,593442720039500hrs
a year of coordinator re-keying removed
The eleven days to four is a queue result, not a clinical one. No clinician saw more patients per hour; the referrals simply reached the scheduling step days earlier, because they arrived as structured data instead of as paper in an inbox.
Sixty-two percent digital is the number we would want scrutinised. It means thirty-eight percent still arrives by fax, from referring practices with their own systems and their own reasons, and it will not reach a hundred. A portal that assumes it will is a portal that quietly breaks the intake path for the practices that send you the most complex patients.
The 1,400 coordinator hours did not become 1,400 hours of savings. Nobody was let go. The time moved to following up the referrals that had gone quiet, which is work that previously did not happen at all.
The constraints we worked under
What this engagement did not include
- Telehealth was out of scope. It was discussed, deferred, and remains deferred — adding a clinical video pathway to an intake project would have changed the risk profile of both.
- Billing and claims were untouched. The portal writes clinical intake data and nothing financial.
- The mobile application covers appointment reminders and rescheduling only. Full intake on a phone was scoped and cut; long clinical forms on a small screen produce worse data, not more of it.
- Thirty-eight percent of referrals still arrive by fax, and the coordinator path for those is unchanged. That is a working design decision, not an unfinished feature.
- One thing we would do differently: the discrete field mapping needed the EHR vendor in the room, and we scheduled that conversation in month two. Month one would have removed about three weeks of assumption from the design.
What they own now
- The repository, the AWS account, the keys, and the retention configuration — all in their own organisation from the first commit.
- The HL7 interface definitions and the discrete field mapping, documented against their EHR version rather than against a generic profile.
- An access review procedure their compliance officer runs quarterly without us.
- Test coverage on the intake and clinician review paths, including the fixtures for the malformed HL7 messages the feed actually produces.
- A handover document written for someone who was not in the room, which is the standard we hold ourselves to on every engagement.
When this would not have worked
A custom patient portal is the right answer less often than it is proposed. We would name these before quoting.
- If your EHR vendor's own portal covers your intake flow, use it. Custom earns its place where the flow is unusual — and behavioural health intake, with its consent and referral patterns, genuinely is.
- If the EHR exposes no usable interface, neither HL7 nor FHIR, the project is a vendor negotiation before it is a software project, and we would tell you that rather than build a scraper.
- If the plan is to attach a PDF to the chart, you do not need us. That is a form vendor, it costs a fraction, and it will not remove the re-keying — which should be said out loud before anyone signs.
- If the organisation will not host the data itself, the whole security argument that made this project acceptable does not apply, and a hosted product is the better answer.
If this sounds like your situation
The capability spans custom software development, cloud solutions for healthcare, and cybersecurity services for healthcare. The engagement shape is a SaaS platform build continuing into maintenance and support, and our healthcare work describes the constraints we design against.
Compliance is an architecture decision, not a document written at the end.
“The last vendor showed us a portal. The first thing this team showed us was a diagram of where our patient data would sit, and that is why the security committee said yes.”
Recognise any of this?
Tell us what is not working. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
A portal can be designed against HIPAA — PHI boundary, access control, audit logging, minimum necessary access, encryption with keys the covered entity holds — and this one was. Compliance itself is a determination the covered entity makes with its counsel and auditors, and no development partner can hand it to you. Treat any vendor claiming to deliver compliance as a signal about the rest of their claims.
Whichever your EHR actually exposes, which is usually both partially. Here the ADT and SIU feeds already ran through an interface engine that worked, so those carried the referral and scheduling traffic, and FHIR was used only where the vendor genuinely supported it. Insisting on FHIR everywhere often means waiting on a vendor roadmap for capability you already have in another form.
Because it is the difference between removing the re-keying and relocating it. A portal that attaches a completed PDF to the chart demonstrates well and leaves your coordinators doing the same work with an extra click. Discrete field mapping takes longer, requires a real conversation with the EHR vendor, and is the only version where the 1,400 hours actually come back.
It should, and on this project it was the reason the security committee approved it after rejecting a previous proposal. We build in the client's account, on their organisation, under their BAA, with named and revocable access for our engineers. It also means removing us later is a decision rather than a migration.
A multi-site portal with real EHR integration and a designed-in control set sits in the platform range described in what custom software actually costs, and the integration count is the main driver — each interface carries its own auth, sandbox, and failure modes. A specific number comes out of discovery, with the assumptions written down.