# Health Services Software Development > Custom healthcare software on HIPAA-ready infrastructure: patient apps, clinician tools, EHR integration, delivered against a committed scope. Source: https://www.koombea.com/industries/health-services/ --- A clinical product has to fit how care is actually delivered, and it has to prove its handling of patient data. Both are design problems before they are engineering problems. ## What makes this different Health services products carry two constraints most software does not. The first is that the workflow already exists: clinicians have a way of working, usually under time pressure, and a product that adds steps will be abandoned regardless of how well it is built. The second is evidence. HIPAA is not a feature you add. It is a set of claims about access control, audit trails, encryption, and business associate obligations that you have to be able to demonstrate. That is easier to build in than to retrofit, and considerably cheaper. There is a third constraint that gets missed. A health organization is not one audience. Patients, clinicians, front-desk staff, billers and administrators all touch the same records with different goals and different tolerance for friction. A product built for the average of those five fits none of them. We build patient-facing and clinician-facing products on HIPAA-ready infrastructure, with the compliance evidence produced as the work happens rather than reconstructed before an audit. - HIPAA-ready infrastructure, with access control and audit trails from the start - EHR and practice-management integration, including the reconciliation it needs - Telehealth flows: secure messaging, video consultation, scheduling - One product surface per audience, because patients and clinicians do not want the same thing - Written security attestation on completion ## What we build here Nine things we are asked for repeatedly in this segment. Each one is a build with an integration surface, not a feature toggle. - **Patient-facing products**: Apps that patients will actually use between appointments, not just at them. - **Clinician tools**: Built around an existing workflow rather than replacing it. - **EHR integration**: Practice management and records systems, with drift detection. - **HIPAA evidence**: Controls and documentation produced during the build. - **Remote monitoring**: Wearables and connected devices, sized for rollout volume rather than pilot volume. - **Billing and claims**: Medical billing, payment capture, and the reconciliation behind both. - **Practice operations**: Scheduling, staff management, and the administrative load nobody budgets for. - **Outcome measurement**: Instrumented so clinical and product teams see the same numbers. - **Accessibility**: WCAG conformance, which in health is frequently a procurement gate. ## Proof from this segment Two builds in this segment, and the part of each that is publicly verifiable. - Luna, concept to market: A native app for patients and therapists, with EHR integration and GPS tracking - Therapists working on Luna: Serving tens of thousands of patients - Design Award for the Luna app: Third-party recognition rather than a self-assessment Fashioned Health runs on HIPAA-compliant infrastructure with Stripe handling PCI-compliant payments, and it was built that way from the first commit rather than corrected before launch. Founder Thomas Caraballo's aim was to reduce unequal access to care, which meant clinical information had to be legible to people without clinical training. Luna's problem was different. Outpatient physical therapy was losing people at both ends, with more than 50% of therapists reporting work-related pain and 70% of patients not completing their course of care. The obstacles were logistical rather than clinical, which is why the answer was a phone. ## How a health build runs The sequence matters more here than in most segments, because two of these steps are cheap now and expensive later. Workflow observation: We watch how the work is done before we design anything, including the parts nobody documents: the sticky note on the monitor, the second system somebody keeps open, the step that is skipped when the clinic runs late. That is where adoption is won or lost. (Before anything is priced) Compliance scoping: Which data is protected health information, which vendors touch it, who signs the business associate agreement, and how much of the regulated footprint can be engineered away. Cheapest possible moment to ask. (Same week as discovery) Experience design: Designed against the observed workflow rather than against a category convention. Patients and clinicians get separate surfaces, because a shared one means one of them is using somebody else's product. (Against the observed workflow) Architecture for year two: Scale decisions get made once. Connected devices and monitoring produce data volumes that look trivial at pilot size and structural at rollout, so the shape is chosen before the first patient, not after the thousandth. (Decided once) Build in two-week cycles: Delivered by an AI Pod against a committed scope, with a working end-to-end product loop in the first phase rather than a foundation you cannot demonstrate to a clinical stakeholder. (Delivered by an AI Pod) Quality and evidence: Testing runs through the build rather than at the end of it, and the compliance evidence is produced as the controls are written. Reconstructed evidence is how audits go badly. (Continuous, not a final gate) The build itself is priced in story points before work begins. [See how that works](https://www.koombea.com/ai-pods/how-it-works/). ## Who we build for here ### Digital health startups — Get to market before the window closes. Early-stage health companies are usually racing a funding milestone or a competitor, and the compliance work is the part that gets deferred until it cannot be. We scope it alongside the product so the first enterprise security review does not become a rebuild. Where the idea still needs proving, an MVP with a real clinical loop is a better fundraising asset than a deck. - A usable product loop in phase one, not scaffolding - Compliance scoped with the build, not after it - Wearable and connected-device flows where the product needs them ### Enterprise health organizations — Integration surface is the whole job. Payers, pharmaceutical companies and hospital groups rarely have one system of record. They have several that disagree, plus procurement, security review and accessibility gates the product has to clear before anyone uses it. We inventory what is genuinely load-bearing before quoting, because that inventory is the estimate. - Records, practice management and billing treated as three systems - Accessibility raised in scoping, where it is still cheap - Security questionnaires answered from evidence that already exists ### Practices and providers — Administrative load is the problem to solve. Practices handle a large volume of records with a small margin for administrative overhead. Patient portals move booking, records access and treatment plans off the front desk, and Health Information Exchange standards govern what happens when those records move to another authorized provider. Off-the-shelf gets most practices most of the way. Custom is for the part it does not reach. - Patient portals for booking, records and treatment plans - Records exchange that follows the standard rather than approximating it - Built around the existing practice management system, not against it ### Projects in trouble — Find out whether it can be saved first. A stalled clinical build is usually not stalled for the reason its owner thinks. Before you write off the investment, we run a technical and clinical assessment against the actual failure: adoption, integration drift, performance, or a compliance gap discovered late. Sometimes the answer is a rebuild. Often it is not, and knowing which is worth the assessment on its own. - Assessment before commitment, with an honest verdict - The failure named, rather than the symptom - Existing investment recovered where it can be Product planning sits inside all four rather than beside them. Roadmaps, opportunity analysis and market framing are part of the same engagement, because a health product that is aligned to the technology and not to the operation gets built correctly and used by nobody. ## HIPAA, treated as architecture Modern care runs on stored data. Records, imaging, monitoring streams, and increasingly the analytics built on top of them to improve treatment plans. All of it sits inside the Privacy Rule, the Security Rule and the Breach Notification Rule, and the enforcement is real. The distinction that matters is that HIPAA compliance is an organizational state, not a software property. Your policies, your training and your business associate agreements are part of it, and no development partner can hand you the whole thing. What is ours to do is make the product's handling of protected health information defensible, and produce the evidence behind that. There is also no HIPAA certification scheme. Anyone selling you HIPAA certification is selling something that does not exist. We build the controls, produce the documentation, and provide a written attestation on completion. Your counsel or your auditor owns the sign-off, because a self-assessment is not evidence. In this sector the consequence of getting security wrong is not a fine and an apology. That is why it is scoped first and why we would rather shrink the regulated footprint than defend a larger one. ### What lands on your side - A stated business associate position: Which agreements are required, and who signs them, settled before work starts - An access control and audit trail model: Documented as built, not described after the fact - Encryption in transit and at rest: With the key handling written down - A subprocessor and data residency statement: Every vendor that touches protected health information, named - Written security attestation: Covering the agreed security checks and any known critical or high-severity findings ## Product types we get asked for - Patient care and engagement apps - Telehealth: secure messaging, video consultation, scheduling - Remote patient monitoring and connected-device apps - Reminder, adherence and alerting systems - Patient portals and electronic health record software - Practice management and hospital management systems - Medical billing and claims applications - Staff scheduling and clinical workforce tools - Healthcare CRM and patient relationship systems - Patient data analysis and reporting tools - Clinical decision support and reference tools - Medical information systems and records exchange ## Where health projects usually go wrong Clinical software rarely fails on the build. It fails on adoption, and the causes are consistent enough to design against before a line is written. - The product adds steps to a workflow already running under time pressure, so clinicians route around it and usage data looks like a technical problem - HIPAA is treated as a launch checklist rather than an architecture, so access control and audit trails are retrofitted at several times the cost - EHR integration is scoped as one connection when the records system, the practice management system and the billing system all disagree - One interface is built for patients and clinicians together, so it is tolerable for both and good for neither - Accessibility is discovered during procurement, after the build is complete, because in health it is frequently a purchasing gate rather than a preference - The pilot works and the rollout does not, because monitoring data volume was sized against fifty patients rather than fifty thousand ## How health work is scoped and priced Patient-facing and clinician-facing builds are delivered by AI Pods against a committed scope, estimated in story points and priced before work begins. The estimate is built from the integration surface and the workflow observation, not from a screen count. Compliance work sits outside that. HIPAA attestation and audit support are scoped as a retainer or a fixed fee, because the deliverable is an opinion rather than a feature. When a build and a compliance engagement run together, they are two lines on two bases, and we state them separately. ## Partnerships and certifications Third-party attestations, which are the only kind worth listing. Our development unit is appraised at CMMI-DEV/3. ## Questions worth asking ### What makes an app HIPAA compliant? Not a certificate. HIPAA compliance is a set of demonstrable claims about access control, audit logging, encryption in transit and at rest, and the business associate agreements covering every vendor that touches protected health information. We produce that evidence as the work happens, because reconstructing it before an audit is where the cost lands. ### Can you make us HIPAA compliant? No development partner can, and be sceptical of one that says otherwise. Compliance is an organizational state that includes your policies, your training and your agreements, not just your software. What we can do is make the product's handling of protected health information defensible and hand you the evidence for it. ### Can you integrate with our EHR? Yes, and the honest answer is that the integration is usually more than one system. Records, practice management and billing often hold different versions of the same patient, so the work includes detecting that drift rather than assuming it away. We inventory which systems are actually load-bearing before quoting. ### How long does a telehealth build take? It depends on whether you are building the clinical workflow or wiring existing ones together. Luna reached market in three months as a native app. We scope from the workflow and the integration surface rather than quoting a category average, because those two things account for nearly all the variance. ### Do you handle accessibility? Yes, to WCAG conformance, and we raise it during scoping rather than at launch. In health services accessibility is regularly a procurement requirement, which means discovering it late does not just create rework, it can stall a sale. ### Can you build for wearables and connected devices? Yes, and the interesting part is rarely the device. It is what the stream does to your architecture once the pilot ends. We size that at rollout volume rather than at pilot volume, because that is the number that decides whether the design survives. ### Our project has stalled. Is it worth rescuing? Often, and it is worth finding out before you write off the investment. We assess against the actual failure rather than the symptom, because a clinical build that nobody uses is usually a workflow problem wearing a technical costume. Sometimes the verdict is a rebuild. We will say so if it is. ### Do you work with practices, or only with product companies? Both. The work differs more than the technology does. A practice is usually trying to remove administrative load and move patients onto a portal, and the constraint is the practice management system already in place. A product company is building something to sell, and the constraint is the integration surface of everyone it sells to. ### Who owns the compliance sign-off? You do, and your counsel or auditor does. We build the controls, produce the documentation, and provide a written security attestation on completion. We do not certify ourselves, because a self-assessment is not evidence. ### When should we bring compliance into the conversation? Before the architecture is settled. Retrofitting an audit trail, a retention policy or a data residency constraint into a live clinical system is the single most expensive way to acquire it, and it is the most common reason a health build costs more than it was quoted. ## Explore other industries - Payments and Lending - Industrial and Field Service - Retail and Commerce - Technology ## Where to go next Two builds, and the two capabilities a health product leans on hardest. - Luna: Case study: in-home physical therapy, three months from concept to market - Fashioned Health: Case study: a HIPAA-compliant telehealth product with compliance built in, not retrofitted - Governance, Risk and Compliance: The capability this segment leans on most, ending in a written attestation rather than a certificate that does not exist - Product Design: Where the workflow observation actually happens, before a clinician is asked to change how they work