A healthtech founder came to me with a product that had been in development for 11 months. Patient engagement platform - appointment reminders, care plan tracking, secure messaging between patients and providers. Real clinical need, solid early interest from a regional health system.
The health system's legal team sent over a vendor questionnaire. Forty-seven pages. Business Associate Agreement requirements, HIPAA security rule documentation, encryption standards, audit log specifications, breach notification procedures.
The engineering team had never heard of most of these requirements. The product had been built to work - not to be HIPAA compliant. The founder had assumed compliance was "mostly documentation" and that they would figure it out before signing any enterprise contracts.
They were four months from their first major deal potentially falling through because of an 11-month oversight.
This is the most common healthtech story I encounter. Compliance is not documentation. It is architecture.
HIPAA Is an Architecture Requirement, Not a Checkbox
The HIPAA Security Rule has specific technical safeguards that constrain how you design your system, not just how you document it. Understanding these early - and building to them from the start - is dramatically cheaper than retrofitting.
The critical technical requirements:
Access controls. Every piece of Protected Health Information (PHI) must be accessible only by authorized users with a legitimate need. This means role-based access control is not optional, and it needs to be enforced at the data layer, not just in the application logic. I have seen systems where the frontend enforces access control but the API returns all data regardless of role. That is a HIPAA violation waiting for an audit to find it.
Audit logging. Every access to PHI must be logged - who accessed what, when, from where. Not application logs that get rotated every 30 days. Tamper-evident, durable audit records. This is an architecture decision: your logging infrastructure needs to be designed to capture these events, and your data model needs to make it possible to associate every PHI access with an authenticated user.
Encryption. PHI must be encrypted at rest and in transit. At rest means your database encryption is on, your backups are encrypted, and any temporary files containing PHI are not sitting in plaintext on disk. In transit means TLS everywhere, including internal service-to-service communication inside your own infrastructure.
In the case above, we had to retrofit all three. Access control required a significant data model change and a rewrite of the authorization layer. Audit logging required a new service. Encryption at rest meant migrating the database. Six weeks of work that should have been six days if it had been designed in from the start.
EHR Integrations: The Technical Reality
Every healthtech startup eventually has to connect to an Electronic Health Record system. Usually multiple EHR systems, because the market is fragmented across Epic, Cerner, Athena, eClinicalWorks, and dozens of others.
The good news: HL7 FHIR (Fast Healthcare Interoperability Resources) is now the regulatory standard for EHR data exchange, and most major EHR vendors have FHIR R4 APIs. The CMS Interoperability and Patient Access rules have pushed the industry toward standards-based integration significantly faster than would have happened otherwise.
The reality: even with FHIR standardization, EHR integrations are hard. Individual EHR implementations vary in what FHIR resources they support and how. Authentication varies - some use OAuth 2.0 with SMART on FHIR scopes, others have proprietary approaches. Rate limits and data freshness vary. Error handling and edge cases vary.
My standard recommendation for healthtech startups: do not build your EHR integration layer from scratch. There are middleware vendors - Redox, Particle Health, Smile Digital Health, 1upHealth - that abstract the variation between EHR systems and give you a normalized integration surface. The cost is real, but it is almost always less than the engineering cost of building and maintaining direct EHR integrations across multiple systems.
The build vs buy decision for EHR integration is one of the clearest ones I encounter. Buy the middleware. Build the clinical logic that differentiates your product.
Build vs Buy in HealthTech: The Framework
Health tech has more expensive buy decisions than most verticals because of the compliance infrastructure that comes with them. But it also has more situations where building is the wrong call.
The framework I use:
Buy when the component is a compliance requirement and not a differentiator. HIPAA-compliant cloud infrastructure (AWS GovCloud or HIPAA-eligible services with a signed BAA), EHR integration middleware, identity verification for clinical users, secure messaging - these are necessary but not the thing that makes your product better than a competitor's. Buying them lets you focus engineering on what actually differentiates.
Build when the component is the core of your clinical value proposition. The care protocol logic, the patient matching algorithm, the clinical decision support rules, the care gap identification - these are what you are selling. You need to own them.
The mistake I see most often is a healthtech team spending three months building their own secure messaging infrastructure when they could have bought HIPAA-compliant messaging APIs from Twilio or Vonage for $500/month. That is three months of engineering that could have been spent on the clinical logic that actually differentiates.
The Timeline Problem: Compliance Takes Longer Than You Think
The most consistent feedback I give healthtech founders: your compliance timeline is probably wrong by a factor of two or three.
Getting a BAA signed with a cloud provider: days to weeks. Getting a BAA with every sub-processor your system touches: weeks to months if you have not inventoried them all. Documenting your security controls to satisfy a health system's vendor questionnaire: two to four weeks if you have been building with compliance in mind, two to four months if you have not. Completing a third-party HIPAA risk assessment: four to eight weeks. Responding to a health system's security review with their specific questions: variable, but health systems are slow.
The implication: if you are targeting enterprise health system customers, you need to start your compliance documentation work before you have a customer to document it for. The moment an enterprise deal appears, you will not have time to build the compliance infrastructure from scratch.
I typically recommend healthtech companies start their HIPAA compliance program at the same time they start their first enterprise sales conversations - not after. The sales cycle will be long enough that you can finish it in parallel.
What a Fractional CTO Does in HealthTech Specifically
The value of fractional CTO engagement in healthtech is concentrated in three areas.
Architecture review with compliance in mind. I look at the data model, the access control patterns, the logging infrastructure, the encryption posture, and the integration design - and I tell you what would fail a HIPAA risk assessment and what would not. Most teams cannot evaluate their own system against these standards because they have not internalized the standards.
Build vs buy decisions for compliance infrastructure. The market for HIPAA-compliant infrastructure components has matured significantly. I know what exists, what the pricing looks like, and when it makes sense to buy vs build. This knowledge alone is worth multiple engineering weeks for a team that would otherwise evaluate from scratch.
Vendor questionnaire and due diligence support. When the health system sends the 47-page questionnaire, someone with executive technical credibility needs to own the response. That is not a task you can hand to a junior engineer. I have answered hundreds of these across dozens of clients.
The goal in every healthtech engagement is to keep the engineering team focused on the clinical product while making sure the compliance infrastructure does not become the reason a deal falls through.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr