Custom healthcare software and patient portals - built so patient data stays in your infrastructure, and out of ours.
Intention InfoService builds patient and provider portals, health-tech front ends and the integrations behind them, on the standards healthcare actually runs on: FHIR and the US Core profiles, SMART on FHIR to launch inside the system of record, HL7 v2 where the legacy interface is still the interface. Protected health information stays inside the HIPAA-eligible infrastructure you already own. And because most briefs that arrive labelled "patient portal" describe something the EHR you are already paying for can do, that is usually the first thing we will tell you.
A paid discovery first, a fixed price before any build, and the code is yours.
- Open standards: FHIR, SMART on FHIR, HL7 v2
- We never store your patients' PHI
- We'll tell you when your EHR already does it
Where the obligations landWho is bound
- HIPAA
- Binds you - and us, if we handle PHI
- PHI custody
- Your HIPAA-eligible infrastructure
- Interoperability
- FHIR, SMART on FHIR, HL7 v2
- Accessibility
- WCAG 2.1 AA, under Section 1557
The boundary is the architecture. Everything else follows from it.
The surfaces around the record, not the record itself
Healthcare software is mostly interface, integration and constraint. The system of record already exists, it is expensive, and it is where the patient data belongs. The interesting engineering is what you can build around it without becoming one more place a breach can happen. A typical engagement is one of these:
Patient and provider portals
The interface people actually use to book, message, pay a bill, view results and manage a record - reading and writing through the systems that already hold the data, rather than copying it into a new database somebody now has to defend.
SMART on FHIR apps and integration
An app that launches inside the record system, authorised through OAuth 2.0 under the user's own credentials, so the EHR stays the system of record and the custody boundary. We build to the published specification, which is free to anyone.
Booking, intake and pre-auth surfaces
Scheduling, registration, forms and payment flows that post straight into the processor and the practice-management system you already run under their agreements, rather than parking identifiable information on a server we control.
Operational tooling on de-identified data
Dashboards, reporting and workflow tools built on de-identified or aggregate datasets, so the people analysing throughput and no-show rates are not handling identifiable records to do it.
Public sites and pre-login surfaces
Provider directories, find-a-doctor search, service lines, location and hours, price-transparency displays fed from your systems, and the content that ranks. None of it holds patient data at all, and it is the majority of most healthcare web work.
AI features, grounded and non-diagnostic
Assistance grounded in your own approved material, with human-in-the-loop review. Explicitly not clinical decision support and not a diagnosis: the moment software is intended to drive a treatment decision, it is a different regulatory animal, and we say so.
What this page is, and where the build actually lives
This page is about the sector, what building for it demands, and which side of the compliance boundary we stand on. The engagement itself is priced and scoped on the service pages:
A bespoke system, scoped before it is priced - a portal or an integration layer is custom software, so it enters through the discovery-first way we price a bespoke build. Which stack it lands on is a separate question, answered on how we decide what to build it with.
The site in front of the practice, not the system behind it - the public site that people find you through holds no patient data and is a different job with its own published starting prices. That is a healthcare marketing site, priced and published, and being found in the first place is an organic growth engagement.
Patients on phones - a native patient experience is a separate build, and we have not shipped a mobile app for anyone yet, in this sector or any other. The honest terms are set out on mobile app development, on honest terms. Assistive features route to AI features, grounded in your own data.
Can you buy HIPAA-compliant software? No - and the phrase itself is the tell.
It is the most common phrase in this category. It is in the headlines, the title tags and sometimes the web addresses of the firms you are comparing us against. And it describes something that cannot exist. Compliance under HIPAA is an operational state of an organisation - a covered entity or a business associate - made out of risk analysis, policies, training, contracts and breach procedures. It is not a property a developer bakes into an application and hands over. There is also no HIPAA certification. The Department of Health and Human Services says it does not endorse or otherwise recognise private organisations' certifications regarding the Security Rule, and Amazon Web Services writes on its own compliance page that there is no HIPAA certification for a cloud service provider. A badge saying otherwise is a private product, sold by whoever printed it. So what should you ask instead? Ask where the patient data will physically live. Ask who becomes a business associate when it does. Ask which of the parties in the diagram would have to notify a breach. Those questions have real answers, they are answered further down this page, and a firm that leads with the badge usually has not thought about them.
What building for healthcare actually demands
Every sector claims to be special. In this one the regulation reaches past the buyer and grabs the vendor, the data subject can be harmed rather than merely inconvenienced, and the system of record is a platform you do not own and cannot replace.
Here, the law reaches the vendor
HIPAA binds covered entities, and it binds their business associates directly. A software firm becomes one the moment it creates, receives, maintains or transmits protected health information on a covered entity's behalf, and its own subcontractors become business associates in turn. So where a vendor stands relative to that boundary is an architecture decision, and we make it deliberately. What we build is the data plane that keeps the records inside your infrastructure.
The least data to lose
Every party who holds a copy of a record is another place it can leak from, and another notification you may have to make. Data minimisation is not a virtue we advertise, it is the shape of the system: opaque references instead of stored identifiers, request-time reads instead of a synchronised copy, and no standing production key on our side.
Integration is the product
Almost nothing in healthcare stands alone. The record system, the practice-management system, the identity provider, the payer and the lab all have to agree, and the standards that make them agree - FHIR, the US Core profiles, SMART on FHIR, HL7 v2 - are where a health build is won or lost. They are published, and they are free to build to.
Accessibility is a funded-program gate
The 2024 Section 1557 final rule adopts WCAG 2.1 Level AA for the web content and mobile apps of covered health programs, and a health system's procurement asks about it before it asks for a demo. We build to it as a method and verify on real assistive technology. We do not tell you a product conforms before it exists.
Sensitive data is not one thing
Substance-use records carry heightened consent rules on top of HIPAA. Reproductive and mental-health data are reached by state consumer-health laws that HIPAA never touches. Those are not policy paragraphs, they are segmentation and consent decisions in the schema. What we build is consent as first-class data, and the segmentation the sensitive categories require.
We would rather scope than guess
A health build is custom software. It enters through a paid discovery that ends in a written scope, a data-flow map and a fixed price - because the alternative is a number invented before anyone knew whether your data would leave the record system at all, which is the question that decides the cost.
When we'd tell you not to build, and when we'd turn the work down
If the record system you already pay for ships a patient portal that does most of this, configure it, or put a small app on top of it through SMART on FHIR, and keep your money. That is the answer most often, and it is the column we highlight in the table below. If your product is meant to diagnose, to drive a specific treatment decision, to interpret a medical image or a signal from a device, or for a patient to rely on primarily, then it may be a regulated medical device - a determination for you and your regulatory counsel, not for us - and it needs a regulatory strategy and a quality system before it needs a web team. We build the workflow, data and interface layers around a cleared device; we are not your regulatory or clinical-validation partner, and we will say so rather than take the project. If the build genuinely requires us to hold your patients' data, we are not your vendor today, for reasons this page spends its length on. And if procurement gates on a supplier who carries a HITRUST certification, a SOC 2 report or a signed business associate agreement, we do not clear that gate, and you should choose a firm that does. Where a custom build genuinely wins: when the experience is the product and the record system actively fights it - a condition-specific programme, a multi-provider network the EHR was never designed to span, an intake or triage flow that decides whether people show up at all. That is a paid discovery before any build quote, and we will make that case with you in writing rather than assume it. Talking you out of a build you do not need is the only credential we can offer before the first health build ships.
Twelve things a health build turns on
Almost none of it is the screen a patient sees. This is the layer a health product is actually judged on - and it is where a team that has read the standards and the Privacy Rule is worth more than a team that has printed a badge.
PHI-free architecture by default
We design so that protected health information stays inside the HIPAA-eligible infrastructure you already run. What we build reads and writes it at request time rather than copying it into a store we control, so the records you are accountable for do not expand onto a vendor's servers you cannot audit.
SMART on FHIR app launch
An app authorised through OAuth 2.0 that acts under the user's own credentials against the record system's FHIR endpoint, with the EHR staying the system of record. It is the mechanism that lets an app read and write clinical data while holding none of it - the custody boundary, made concrete.
FHIR R4, US Core and USCDI
We build to the open, published US-realm profiles rather than a proprietary schema, so the data model your integration speaks is the one regulators and other vendors already build to. The specification is dedicated to the public domain; anyone can implement it.
HL7 v2, C-CDA and legacy interfaces
The modern API is not always the interface that exists. We ingest and exchange HL7 v2 messages and C-CDA documents where a lab, an older system or a payer still speaks them, and design toward TEFCA and QHIN-reachable networks without claiming to be one.
De-identified and synthetic dev data
We build and test on synthetic records and de-identified datasets - the Safe Harbor and Expert Determination methods the Privacy Rule names, Safe Harbor being the removal of its 18 enumerated identifier categories - so real patient data is not required to do the work, and does not sit in a test environment waiting to leak.
Least-privilege access and audit logging
Role-based access, break-glass that is time-boxed and logged rather than a standing key we hold, and tamper-evident trails that record who reached what, and when. Where a task genuinely needs production access, you grant it, it is scoped, and it expires.
Consent and authorisation as data
HIPAA authorisation, the heightened consent that substance-use records require, and GDPR Article 9 conditions modelled as first-class, granular and revocable data rather than a checkbox - because the sensitive-data rules are a schema decision before they are a policy statement.
Accessibility engineering to WCAG 2.1 AA
Semantic structure, keyboard operability, contrast, focus order and screen-reader support built in from the first component and verified on real assistive technology - claimed as a method and as build work, never as a conformance outcome or a VPAT we do not have.
Secure-by-design SDLC
Threat modelling, dependency and secrets scanning, static and dynamic analysis in the pipeline, and documented change control - the engineering practices the Security Rule safeguards describe, run as a matter of course rather than produced for an audit that has not happened.
Tokenisation and minimisation at the edge
Opaque references in place of stored identifiers, field-level separation of the identifying data from the rest, and boundaries drawn so the systems we touch hold no identifiable health information even as they drive a workflow that depends on it.
Grounded, non-diagnostic AI
Assistance grounded in your own approved material, with human-in-the-loop review and explicit non-diagnostic guardrails. We treat the line where software starts driving a clinical decision as a hard boundary, because crossing it changes what the software legally is.
HIPAA-eligible cloud, under your BAA
We deploy only on the services AWS calls HIPAA-eligible, Google calls covered and Azure calls in-scope, configured on your own tenant under the business associate agreement you hold with the cloud provider. Their own wording is eligible, covered, in-scope, under a BAA, shared responsibility - and we use theirs, not a marketer's.
Our default for a health product: draw the business-associate boundary first, and build on the outside of it. Start by asking whether the record system you already pay for does most of this, and whether the rest can ride on a SMART on FHIR app and the published standards. That is usually the fastest, cheapest and safest answer, and saying so costs us the larger engagement. When a custom build genuinely is right, keep the protected health information inside your own HIPAA-eligible infrastructure, reach it at request time under scoped and expiring access rather than a standing key, and develop against synthetic and de-identified data so real records never enter a test environment. Model consent and the sensitive-data segments before the features, because retrofitting them after the schema is set is the expensive path. Treat accessibility as build work from the first component, because under Section 1557 it is a gate and gates fail late. And keep the analytics and error trackers off any surface that sees patient data, because that is the exact failure the Federal Trade Commission has already acted on against consumer health apps.
The patient data we can't lose is the data we never store.
We have no healthcare clients, no hospital logos, no business associate agreement on file and no audit to wave, and you should weigh that. What we have instead is a posture most firms in this sector quietly reverse. Rather than expanding onto your side of the compliance boundary and asking to hold your patients' data, we architect ourselves to the outside of it - and below is exactly what that buys you, and what it costs us.
The business associate boundary, and the side we build ourselves onto
The single most valuable thing a healthcare software firm can become is your business associate - the shop that holds the data, hosts the system, signs the agreement and bills a recurring retainer to run it forever. That is where the stickiest revenue in this sector lives, and it is the obvious thing for a development firm to grow into. We decline it on purpose. It is not a contract we were offered and turned down; it is a business model we could build and choose not to, the same against-interest move as telling a merchant to use a platform we do not sell.
Standing outside that boundary is more work, not less. We build synthetic and de-identified datasets to develop against instead of reading the failing record directly. We engineer time-boxed, logged, client-granted break-glass instead of holding a standing production key. We reach data at request time through infrastructure in your name instead of copying it into a database we control. We take on that cost so that we hold less of your risk.
And no, this does not offload risk onto you. Your patients' data already sits in your own infrastructure, where your liability already is. Our posture does not move risk onto your side of the table; it declines to add a new party to your breach surface. The least data we can lose is the data we never store, and that is a security virtue rather than a limitation - which is the whole point of building it this way.
Who each law binds - and what we build for it
HIPAA binds the covered entity - and, unlike FERPA in education, it binds us directly the moment we handle PHI. A software firm that creates, receives, maintains or transmits protected health information on a covered entity's behalf is a business associate, directly liable under HITECH, and its own subcontractors become business associates in turn. Whether a given engagement makes us one is specific to its facts and its contract, not something a web page can decide. So we architect not to become one, and when a build genuinely cannot avoid it, we say the engagement changes and that it is not one we take today. What we build is the client-hosted data plane, a minimum-necessary access model, audit logging, and break-glass that expires.
The FTC Health Breach Notification Rule and state consumer-health laws bind the app operator even where HIPAA does not. A direct-to-consumer wellness or mental-health product usually sits outside HIPAA, and inside the FTC rule - which the Commission has enforced against GoodRx and against the Premom app for leaking health data to advertisers through trackers - and inside laws like Washington's My Health My Data Act, which carries a private right of action, and California's medical-information law, which now reaches some mental-health apps. We do not decide which regime applies to you; your counsel does. What we build is consent capture, data minimisation, third-party-disclosure controls, and the exact thing those FTC cases turned on: no advertising or analytics trackers on any surface that sees health data.
GDPR makes health data a special category, the institution the controller and us the processor. Processing needs both a lawful basis and a specific Article 9 condition, and there is no general certificate a development firm can hold to prove it behaves like a processor. What we build is the processor posture: data-processing terms, subject-rights mechanics, minimisation, and in-region hosting where residency is required. What you will never get from us is the word compliant - not about HIPAA, not about the FTC rule, not about GDPR, and not about accessibility. Compliance is a property of how an organisation operates and contracts, attested by people qualified to attest it. We do the engineering that makes it reachable, tell you where the cost of clearing each gate actually lands, and leave the attestation where it belongs.
Your PHI stays in your infrastructure, in your name
Patient data lives at rest inside your own HIPAA-eligible environment - your cloud, your database, your account - not on a system we operate and rent back to you. What we build reads and writes it through your infrastructure rather than copying it into ours, so the records you are accountable for never expand onto servers you cannot audit.
We develop against synthetic data, not your patients
We build and test on synthetic records and de-identified datasets, so real patient data is not required to do the work. Where a task genuinely needs production access it is scoped, time-boxed, logged and granted by you, never a standing key we keep. It is harder work for us, and a smaller blast radius for you.
You own the code, the schema and the integration
The repository, the data model, the FHIR and SMART on FHIR integration and every record are yours, on infrastructure registered in your name, handed over on final payment with no licence back to us. We build to published standards so another team, or your record system's own vendor, can take it forward without paying us rent.
We are honest about the boundary, before you sign
We do not sign business associate agreements and we do not store your patients' PHI today, and we will not pretend otherwise to win the work. If discovery finds that patient data genuinely has to flow through what we build, we tell you it changes the engagement and that it is not one we take on - rather than quietly becoming your business associate and hoping the contract goes unread.
Procurement, answered truthfully
No business associate agreement, no HITRUST certification, no SOC 2 report and no ISO 27001 of our own - and there is no HIPAA certification for anyone to hold. We complete your security questionnaire honestly, including the parts where the answer is no, and help you evidence the parts that are genuinely ours: the access model, the audit logging, the data-flow diagram. If your procurement requires a supplier who carries those attestations, we will tell you plainly that is not us.
We will tell you not to build
If your record system's own patient portal already does this, or a SMART on FHIR app on top of it does, we point you there rather than quote a bespoke build - and the anti-recommendation above costs us that engagement whenever we are right. It is the only credential we can honestly offer before the first health build ships, and we would rather offer it than a borrowed logo.
The healthcare badges, named correctly - and the category errors we won't commit
Start with the one that does not exist. There is no HIPAA certification. The Department of Health and Human Services neither issues nor recognises one, and a cloud provider as large as Amazon Web Services says the same about itself, so a "HIPAA-certified" badge advertises a thing the regulator does not grant. What do exist are these, and we hold none of them. A SOC 2is an attestation report a CPA firm writes about an organisation's controls, not a certificate - we have not undergone a SOC 2 examination. ISO 27001 is a genuine certification held by an organisation, and we are not certified to it. HITRUST CSF is the healthcare-specific certification this sector flaunts most, at its e1, i1 and r2 assessment levels, held by an organisation - we hold none of them. ONC / ASTP Certified Health IT is a credential that attaches to a product rather than a company: a product is tested by an authorised testing laboratory, certified by an authorised certification body, and listed on the Certified Health IT Product List with its own identifier - so "an ONC-certified agency" is a category error, and on a build for you that certification would be yours to earn as the product's owner. The record-system marketplaces work the same way. Epic lists products in the Epic Showroom, entered at the Connection Hub tier, and grants its Toolbox designation to products that follow its recommended practices - product credentials, not company ones, and we have none. Oracle Health, formerly Cerner, runs a developer program where a product earns validated-integration status and a marketplace listing - again a product listing, which we do not have. athenahealth runs its Marketplace and Marketplace Partner Program, where a partner lists an integrated solution - once more a product listing we have not made. We name these precisely because this sector is full of firms that hold a product-level credential, or none at all, and let it imply the company is certified. It does not, we hold none, and what we offer instead of a badge is the boundary on this page, code you own outright, and a paid discovery before any price.
What our real work proves here, and what it does not
Our production work is real, custom web builds - a professional training platform rebuild and a financial-services site, both on our work page. Neither is a clinic system, and we will not pretend otherwise. What carries over is narrow and deliberately non-clinical: identity and roles deciding who may see which record, structured catalogs and records that must stay correct, enquiry and enrolment flows that have to post reliably and never silently drop, and an operator screen a non-technical person runs all day. That machinery we have built and run in production, and a patient or provider portal is made partly of it. What does not carry over is the entire clinical core. A wrong enrolment costs money; a wrong allergy, medication or lab value can harm a patient. PHI is not catalog data, an electronic health record is not an enquiry form, and breach notification, minimum-necessary access and the business associate boundary are things a training site or a loan-comparison site never taught anyone. So we claim the first machine, and we fence off the second as work we have not shipped: the two real builds on our work page, described honestly. We have no healthcare clients, no shipped patient portal, and no EHR integrated in production. The healthcare-specific part of what we offer is the standards depth on this page, the boundary above it, and a willingness to tell you the thing that costs us the sale.
The data-flow map comes before the build
We map exactly where patient data goes before anyone designs a screen, because that map decides whether the work stays outside the business-associate boundary - which is the decision the rest of the engagement turns on. Then we model consent and roles before the features, and prove the integrations against synthetic data before real records exist.
Discovery & the data-flow map
1-2 weeksA paid discovery that ends in a written scope, a fixed build quote credited toward the build, and a map of exactly where patient data flows - and therefore whether the work can stay outside the business-associate boundary. If your record system already does most of it, we say so, and the engagement gets smaller.
Consent, roles and the PHI boundary
before designWho may see what, which data is sensitive enough to segment, where consent is captured, and which surfaces are allowed to hold identifiable data - modelled before any feature. These are schema decisions, and retrofitting them after the schema is set is the expensive path.
Integration on sandboxes and synthetic data
weeksThe SMART on FHIR launch, the FHIR reads and writes and any HL7 v2 feed stood up early against vendor sandboxes and synthetic records - so the integration is proven before real PHI is anywhere near it, and real data first appears only inside your own infrastructure at deployment.
Accessibility & security-review readiness
throughoutBuilt to WCAG 2.1 AA as a method and verified on real assistive technology, not a checker score - then we help you answer the security questionnaire your buyer sends, honestly, including the parts where the answer is that we hold no HITRUST, no SOC 2 and no signed agreement.
Deploy, hand over & care
on deliveryDeployed onto HIPAA-eligible cloud in your name, then handed over: the repository, the code, the IP and the infrastructure are yours. Care runs on the non-PHI surfaces only - the marketing site, the front-end layer, the pipeline - while backups and access to anything holding patient data stay inside your infrastructure, not ours.
The comparison nobody selling you a build will show you
This is the decision, and it is made before a single screen is designed. We build custom front ends, which means the middle column costs us money every time it is the right answer. It usually is.
| Use your record system's own portal | Add an app or integrate | Build a bespoke front end | |
|---|---|---|---|
| What it is | The patient portal your EHR already ships, configured | A SMART on FHIR app or integration on top of the system of record | A custom front end built from the workflow up, on your own stack |
| Best for | Standard scheduling, messaging, results and bill-pay | A specific gap the built-in portal can't close, on the data it already holds | When the experience itself is the product and the record system fights it |
| Where the PHI lives | In the EHR. You never took on a new store | In the EHR. The app reads and writes it, holds none at rest | In your HIPAA-eligible infrastructure, reached at request time |
| Who becomes a business associate | The EHR vendor, under the agreement you already signed | The EHR vendor still holds the data; scope the app so no one new does | Whoever ends up holding or hosting the data - a line to draw deliberately |
| Interoperability | Whatever the vendor built in | FHIR, US Core, SMART on FHIR - the published standards | Whatever you build to. The specs are free; the work is not |
| Accessibility gate | The vendor's conformance report, which you inherit | The vendor's, plus whatever your app layer adds on top | Entirely yours to establish and to evidence under Section 1557 |
| Our take | If the built-in portal does most of it, start here and keep your money | The right answer for most people who ask us for a custom portal | Only when the built-in portal and an app on top both genuinely fall short |
The highlighted column is the one that most often wins, and it is the one that pays us least. When the third column genuinely is right, it is a paid discovery before any build quote, and we will make that case with you in writing rather than assume it. Which stack it lands on is a separate question, answered on how we choose the stack.
A health build is scoped, not quoted from a page
No quote wall, and no invented range either. Every agency page in this sector publishes a custom-healthcare-software price band. None of them can know whether your patient data will leave the record system at all, which is the question that decides the cost - and neither can we until we have mapped it.
Discovery Sprint
A paid discovery that ends in a written scope and a fixed build quote. It ends in a written scope, a data-flow map that shows where patient data lives and who becomes a business associate, and a fixed price for the build - credited toward that build. If discovery concludes your record system already does this, you keep the scope and the recommendation, and the larger engagement never happens.
1-2 weeks
Where the rest of a healthcare budget goes - and where our care plans stop
The portal or integration is one line. The site that markets the practice is a different job with its own published starting prices, on our web design and development service. A native patient experience on phones is a separate build again, on mobile app development, on honest terms - and we have shipped no mobile apps for anyone yet, which that page says plainly. The system itself is a paid discovery before any build quote. One boundary matters more here than on any other page: our published care plans - the monitoring, the standing access and above all the scheduled offsite backups - are built for ordinary websites, and we do not point them at a system that holds patient data. Holding a copy of, or a key to, a database of patient records is exactly what would make us a business associate under HIPAA and liable under HITECH, which is the boundary this whole page exists to stay outside. So on a health build we care for the parts that hold no PHI - the marketing site, the front-end layer, the pipeline and the dependencies - while backups, access and monitoring of anything holding patient data stay inside your HIPAA-eligible infrastructure, run by you or by a host that will sign the agreement we won't.
Not sure you should build at all? That's the first thing discovery answers, and it is the answer we're happiest to give.
Building for healthcare, answered
Can you build a HIPAA-compliant app?
No one can hand you a 'HIPAA-compliant app', and a firm that says it can is selling you a phrase. Compliance under HIPAA is an operational state of an organisation - a covered entity or a business associate - made of risk analysis, policies, training, contracts and breach procedures. It is not a property a developer bakes into software. There is also no HIPAA certification: the Department of Health and Human Services says it does not endorse or recognise private certifications, and Amazon Web Services says the same about itself. What we build is software that keeps protected health information inside your own HIPAA-eligible infrastructure, engineered to the practices the Security Rule describes, so that you can operate it as part of your own compliance - which is the only place compliance can actually live.
Do you sign a business associate agreement (BAA)?
No, not today, and we would rather tell you that on the first call than after a discovery. A BAA is the contract you sign with a vendor that creates, receives, maintains or transmits your patients' PHI, and it makes that vendor a business associate, directly liable under HITECH. We architect specifically so that we are not that vendor: the patient data stays inside the infrastructure you already run, and what we build reaches it at request time rather than storing a copy we would have to sign a BAA to hold. If a build genuinely cannot avoid us holding PHI, that changes the engagement, and it is not one we take on. If a signed BAA is a hard requirement for you, you should choose a firm that offers one, and we will say so plainly.
Have you built healthcare software before?
No, and we will not dress that up. We have no healthcare clients, no hospital logos and no patient portal in production, and you should weigh that against whatever else we say. Our production work is a custom, full-stack online store on its own backend, and a corporate site. What we offer instead is standards depth - FHIR, US Core, SMART on FHIR, HL7 v2 - an accurate account of who each regulation actually binds and where the business-associate boundary falls, and a willingness to tell you not to build when your record system already does the job. If a portfolio in healthcare is your deciding criterion, there are firms who have one, and we would rather you knew that now than after a discovery.
Where will our patients' data actually live?
Inside your own HIPAA-eligible infrastructure - your cloud tenant, your database, your account, under the business associate agreement you hold with your cloud provider - and not on a system we operate and rent back to you. This is the question we think you should ask every vendor first, because most pages in this sector never answer it. What we build reads and writes the data through your infrastructure rather than copying it into ours, so the records you are accountable for do not expand onto servers you cannot audit. A portal front end momentarily handles data in the browser to display it; it stores none of it at rest on our side. Storing the least data we can is the point, not a limitation.
Should we build a custom patient portal, or use the one our EHR already ships?
Usually you should use the one you already pay for. Most briefs labelled 'patient portal' describe scheduling, secure messaging, results and bill-pay, and the major record systems ship all of that in their own portal, kept up to date and inside their own compliance boundary. The honest first question is whether the built-in portal does eighty per cent of it, and whether the rest can ride on a small SMART on FHIR app on top. Building a bespoke front end is right when the experience itself is the product and the record system actively fights it - a condition-specific programme, a multi-provider network the EHR was never designed to span, an intake flow that decides whether people show up. That category is real, and much smaller than the number of people who ask for it.
What is SMART on FHIR, and do we need it?
SMART on FHIR is the open standard that lets an app launch inside a record system, authorised through OAuth 2.0 under the user's own credentials, and read or write clinical data through the system's FHIR interface - while the EHR stays the system of record. It matters because it is the mechanism that lets you add functionality without standing up a second database of patient data: the record system keeps holding the data, and your app holds none of it. If you are adding a focused capability on top of an EHR you already run, it is very often what you need, and it keeps you on the safe side of the custody boundary. If you are building something the record system has no concept of, you may need more, and we will tell you which.
Can you integrate with Epic, Oracle Health or athenahealth?
We build to the standards those systems expose - FHIR, US Core and SMART on FHIR - and against their developer sandboxes and synthetic data, which is how integration is built and tested before any real record is involved. We should be precise about credentials, though: each of them runs a marketplace that lists products, not development companies. Epic lists apps in its Showroom, Oracle Health lists validated integrations, and athenahealth lists solutions in its Marketplace, and we hold none of those listings because we have no healthcare product of our own to list. On a build for you, that listing - if your product needs one - would be yours to earn as its owner, and we build the integration you would list. We have not integrated one of these in production, and we say so.
Is our product a medical device, and can you handle that?
That is a determination for you and your regulatory counsel, not for us, so we will not tell you your product is or is not a device. What we can tell you is where the line sits: if software is meant to diagnose, to drive a specific treatment decision, to interpret a medical image or a signal from a device, or for a patient to rely on primarily, it may be regulated as Software as a Medical Device, which needs a quality system and a regulatory strategy before it needs a web team. If that is your product, we build the workflow, data and interface layers around a cleared device, but we are not your regulatory or clinical-validation partner, and we will point you to one rather than take a project we are not equipped to carry.
Who owns the code, and who is responsible for the patient data?
You own the code outright - the repository, the data model, the integration and the IP, on infrastructure registered in your name, handed over on final payment with no licence back to us. The patient data was always yours, and stays inside your infrastructure throughout, which is deliberate: the legal responsibility for those records under HIPAA is the covered entity's, and an organisation that does not control its own patient data cannot meaningfully discharge that responsibility. We build to open standards precisely so another team, or your record system's own vendor, can carry the work forward without asking us, and without you holding data on a system only we understand.
Will the product be WCAG compliant, and can you give us a VPAT?
We will not tell you a product conforms before it has been built and tested, and we do not have a VPAT to hand you - a VPAT is a document authored about a finished product, so any firm handing you theirs is handing you a document about their software, not yours. Here is what is true: the 2024 Section 1557 final rule adopts WCAG 2.1 AA for the web content and mobile apps of covered health programs, and a health system's procurement will ask about it. We build to that standard as a method - semantic structure, keyboard operability, screen-reader labelling, contrast, focus order - verify on real assistive technology rather than a checker score, and help you populate the accessibility conformance report and the security questionnaire your buyer actually reads.
Do you build a mobile app for patients, or a web portal?
We build mobile apps as a service, and we have not shipped one for anyone yet - not in healthcare, not in any sector - and we say so plainly on our mobile app development page rather than let a portal's web build imply a mobile portfolio. In practice many healthcare products need a responsive, accessible web experience far more than a native app, and the store review, offline behaviour and device fragmentation an app brings are real costs on top of the health-data ones. If you genuinely need a native app, that page sets out the honest terms and the published prices, and the same PHI-custody rules apply: the data belongs in your infrastructure, not on the device or on us.
Can you add AI to a healthcare product?
Yes, as an assistive layer grounded in your own approved material, with human-in-the-loop review and explicit non-diagnostic guardrails. The hard boundary is clinical decision-making: the moment software is intended to drive a treatment decision or a diagnosis, it can become a regulated medical device, and whether it has crossed that line is a question for your regulatory counsel. So we keep AI on the assistive side of it - drafting, summarising and surfacing your own content - and we keep patient data out of any model or prompt pipeline that would put it in front of a third party. We will also tell you when a feature is being added because it is fashionable rather than because it helps a patient or a clinician.
How do you handle GDPR for patients in the EU?
GDPR treats health data as a special category, which means processing needs both a lawful basis and a specific Article 9 condition, and it makes the institution the controller and a firm like us the processor. There is no general certificate a development company can hold to prove it behaves like a processor, so we will not claim to be a certified anything. What we build is the processor posture: data-processing terms, the mechanics that let a data subject exercise their rights, minimisation so you are not holding what you do not need, and hosting in the region where residency is required. Which conditions and bases apply to your product is a question for your counsel, and one we raise early because it shapes the data model.
What does custom healthcare software cost?
We publish one number here and refuse to invent the other. Every agency page in this sector prints a custom-healthcare-software price band, and none of them can know whether your patient data will leave the record system at all - which is the single biggest driver of the cost. So a health build enters through a paid Discovery Sprint from $1,000, which is one to two weeks and ends in a written scope, a data-flow map showing where PHI lives and who becomes a business associate, and a fixed price for the build, credited toward it. If discovery concludes your record system already does the job, you keep the scope and the recommendation, and the expensive engagement never happens. Marketing sites and mobile builds have their own published starting prices.
Do you hold SOC 2, HITRUST or ISO 27001?
No to all three, and it is worth being precise about what each one is. A SOC 2 is an attestation report a CPA firm writes about an organisation's controls, not a certificate you pass, and we have not undergone a SOC 2 examination. ISO 27001 is a genuine certification held by an organisation, and we are not certified to it. HITRUST CSF is the healthcare-specific certification, at its e1, i1 and r2 levels, held by an organisation, and we hold none of them. And there is no HIPAA certification at all for anyone to hold. We complete your security questionnaire honestly, including the parts where the answer is no, and evidence the parts that are genuinely ours - the access model, the audit logging, the data-flow diagram. If procurement gates on a supplier who carries those attestations, that is not us, and you should choose a firm that does.
Building something for healthcare?
Tell us what you're trying to do, and where the patient data has to live. We'll map it, tell you honestly whether your record system already does the job, and tell you plainly if it's a project we shouldn't take - before anyone quotes you a number.