Why healthcare software development requires different due diligence
When you hire a development partner for a retail platform or a SaaS analytics tool, a failed project means lost time and money. When you hire a development partner to build a HIPAA-regulated healthcare product, a failed project can mean a federal investigation, civil monetary penalties between $100 and $50,000 per violation (up to $1.9 million per violation category per year), potential criminal charges for willful neglect, notification of every patient whose data was exposed, and reputational damage that can end a company.
Healthcare software development partners become your Business Associates under 45 CFR §164.308. That is a legal relationship, not a label. It means they are subject to the HIPAA Security Rule, must execute a BAA before accessing any PHI, must safeguard PHI with technical controls that meet the same standards as yours, and bear direct legal liability for breaches that result from their failure.
The technical evaluation criteria below are not abstract compliance boxes. Each one maps to a real engineering decision made early in architecture, deeply expensive to retrofit, that determines whether your product is defensible in a federal audit, whether your patients' data is actually protected, and whether your engineering team will spend the next 18 months building features or fixing compliance architecture.
The 14 criteria at a glance
Use these as your opening framework in the first conversation with any vendor.
The 14-point technical due diligence checklist
Will you sign a Business Associate Agreement before accessing any of our data, and can you walk me through the specific engineering controls your team implements to satisfy the HIPAA Security Rule, not just the policy language?
Vendor executes BAA before any PHI engagement and can articulate specific technical safeguards: AES-256 encryption at rest and in transit, role-based access controls enforced at the data layer, PHI access audit logging at the row level, workforce HIPAA training documentation, and an incident response plan with documented 60-day notification SLA.
Vendor offers a BAA template but cannot explain the technical controls behind it. States "we are HIPAA compliant" as a credential rather than describing engineering practices. Cannot differentiate between encryption (reversible) and data masking (irreversible). Treats the BAA as a legal formality.
The HIPAA Security Rule (45 CFR §164.312) requires specific technical safeguards: access controls, audit controls, integrity controls, and transmission security. These are engineering requirements with engineering implementations, a BAA is only as meaningful as the controls that back it.
How do you protect PHI in development, testing, QA, and ML training environments, and can you explain why your approach is different from encryption?
All non-production environments use irreversible, deterministic PHI masking or synthetic data generation. Vendor names the tooling. The vendor can explain that masking is irreversible by design, while encryption requires key management and is vulnerable to key compromise.
Vendor treats database-level encryption as equivalent to PHI masking. Uses production data in development environments with only access controls for protection. Cannot explain what deterministic masking means or why referential integrity matters in a masked test database.
PHI exposure in non-production environments is one of the most common HIPAA violations in healthcare software development. Deterministic masking preserves the data's structural properties while making reconstruction of the original PHI impossible. Encryption can be reversed with a key. Masking cannot.
How does your audit trail work at the record level, not the session level, and can a compliance officer query it independently without filing a ticket to engineering?
Audit trail captures every create, read, update, and delete event at the individual record level. Logs are immutable, time-stamped with sub-second precision, attributed to specific user identities and roles, and queryable through a compliance dashboard without engineering involvement. Architecture satisfies HIPAA §164.312(b) audit controls.
Audit logging is at the session, batch, or application event level, not the record level. Logs are stored in mutable tables that engineers can alter. The compliance team must request log extraction from engineering for every audit query. Cannot demonstrate the ability to pull a specific patient's data access history on demand.
HIPAA Security Rule (45 CFR §164.312(b)) requires mechanisms to record and monitor activity across all information systems that contain PHI. If your compliance team must submit an engineering ticket every time they need to answer audit questions, your audit trail is operationally insufficient regardless of whether it technically exists.
Which version of FHIR have you implemented in production, R4, R4B, or R5, and can you walk me through a production EHR integration you've shipped?
Vendor has production FHIR R4 or R4B implementations. Can demonstrate SMART on FHIR authorization flows, Bulk FHIR ($export) for analytics, and CDS Hooks for clinical decision support embedding. Has integrated with at least one major EHR (Epic, Cerner, Athena, NextGen, AllScripts) in production, not just sandbox testing.
Vendor has "worked with FHIR" in a proof-of-concept or sandbox environment. Cannot demonstrate a production EHR integration. Conflates HL7 v2 experience with FHIR R4 capability (they are different standards with different engineering requirements). Cannot explain SMART on FHIR OAuth 2.0 authorization scopes.
A vendor who has only sandbox-tested FHIR will discover the gap between sandbox behavior and production EHR behavior inside your project timeline.
Not sure which FHIR version your product needs? NonStop's healthcare engineers can assess your specific EHR integration requirements and recommend the correct FHIR version, SMART scopes, and integration pattern in a 45-minute architecture call before any engagement begins.
Schedule a Free FHIR Architecture Review →Are access controls enforced at the data storage layer, not just the application layer, so that a direct database query by an unauthorized user returns masked or access-denied results regardless of how the data is accessed?
Access controls are enforced at the data platform layer. A user with a database client who attempts a direct SQL query against PHI columns without appropriate role permissions receives either masked values or an access-denied response.
Access controls exist only at the application API layer. Any user with direct database access, a DBA, a contractor, or a developer with elevated permissions, can query PHI without restriction.
Application-layer access controls are necessary but structurally insufficient for HIPAA compliance. HIPAA's minimum necessary standard (45 CFR §164.514(d)) requires that PHI access be restricted to the minimum necessary for each user's role.
Which cloud services in your standard architecture are covered under the cloud provider's HIPAA BAA, and how do you enforce PHI data residency requirements to prevent cross-region replication?
Vendor can enumerate, by name, which cloud services in their standard architecture are covered under the relevant cloud provider's HIPAA BAA. Uses AWS Service Control Policies, Azure Policy, or GCP Organization Policies to enforce region-locking. Customer-Managed Encryption Keys (CMEK) are in place to prevent PHI from being decrypted by the cloud provider.
The vendor cannot name which specific cloud services are HIPAA-eligible. Using an uncovered service to process or store PHI constitutes a HIPAA violation regardless of the BAA your development partner has signed with you. Common uncovered services include analytics, logging, and developer tooling.
AWS, Azure, and GCP each publish explicit lists of services that are and are not covered under their HIPAA BAAs. Common uncovered services include analytics, logging, and developer tooling used in software development.
Has your team built a product that required FDA Software as a Medical Device classification? If so, can you walk me through your Design History File process and how you structured the IEC 62304 software development lifecycle?
Vendor has completed at least one SaMD engagement requiring FDA classification. Can describe the Design History File (DHF) structure, Software Requirements Specification, Verification and Validation (V&V) protocols, and traceability matrix. Understands Class I, II, and III SaMD risk classification. Has incorporated FDA AI/ML-based SaMD guidance (2021) into AI product development.
The vendor has never built a product requiring FDA SaMD classification. Uses "FDA compliant" loosely to mean HIPAA or general data security. Does not understand that AI/ML-based clinical decision support tools may require FDA clearance before commercialization.
The FDA Software as a Medical Device regulation applies to any software function intended to diagnose, treat, cure, or prevent disease. AI-powered clinical decision support tools, AI diagnostic aids, and risk prediction algorithms frequently fall under SaMD classification. The FDA published specific guidance on AI/ML-based SaMD in January 2021; any vendor claiming FDA experience should be able to cite it.
Do you hold a current SOC 2 Type II certification, and will you share the most recent audit report under an NDA before we proceed with the contract?
Vendor holds a current SOC 2 Type II certification covering a sustained 6–12 month audit period and will share the complete report under NDA during vendor evaluation, not after contract signature. Can explain the difference between Type I (point-in-time) and Type II (sustained operational controls).
Vendor holds only SOC 2 Type I. Has a SOC 2 audit "in progress" with no committed completion date. Will share the report only after contract signature, making the evaluation incomplete.
SOC 2 Type II covers the same security domains as Type I but over an extended period, typically six to twelve months, providing evidence that security controls are operational and consistently maintained. For a healthcare development partner who will have persistent access to your PHI environment, Type I provides no meaningful assurance about ongoing operations.
How does your team handle the data infrastructure layer for AI healthcare products specifically? Who builds the FHIR-native data pipelines, feature stores, and training data quality frameworks that your ML models depend on?
Vendor has dedicated data engineering capability separate from application engineering, with experience building FHIR-native data pipelines, PHI-safe feature stores, and training data quality frameworks. Can describe how PHI is handled at every stage of the ML training pipeline: ingestion, feature engineering, training, validation, and post-market monitoring.
Vendor's data engineering is limited to ETL and database integration. Data scientists build their own training pipelines without oversight from infrastructure teams.
AI healthcare products fail before production at extraordinarily high rates, industry estimates range from 70% to 85%. The failure point is almost never model accuracy; it is data infrastructure. PHI in training environments (a HIPAA violation), inconsistent feature engineering across training and inference, missing data quality gates, and absent model versioning are all data engineering failures.
Can you provide your incident response plan during this evaluation, and what is your specific documented SLA for notifying us in the event of a potential PHI breach?
Vendor produces a documented incident response plan during vendor evaluation. The plan includes a PHI breach notification SLA significantly shorter than the HIPAA 60-day legal maximum, best practice is 24–48 hours from discovery. The plan has been exercised through a tabletop simulation within the past 12 months. IR runbooks are documented, not dependent on individual employee memory.
The vendor cannot produce an IR plan during evaluation. States the HIPAA 60-day legal maximum as their target notification timeline. Has never conducted a breach simulation. The IR process is undocumented and contingent on specific staff being available.
The HIPAA Breach Notification Rule (45 CFR §164.400–414) requires that Business Associates notify covered entities no later than 60 calendar days after discovery. The 60-day limit is the legal ceiling. IBM's 2023 data shows healthcare breaches take an average of 204 days to identify and 74 days to contain. A vendor who has never tested their IR process has no evidence that it works.
What percentage of your engineering team has built and shipped HIPAA-regulated systems in production, not consulted on compliance separately, but designed compliant architecture as part of their engineering role?
The majority of engineers on healthcare engagements have direct prior experience building HIPAA-regulated systems. Compliance is embedded in architecture decisions from the beginning, PHI handling, audit trail design, access control granularity, masking architecture, without requiring a separate compliance review step.
The team has one compliance consultant attached to the project who reviews engineering decisions after they are made. The core engineering team is generalist and encounters HIPAA requirements for the first time in your engagement. Compliance is a post-development layer, not an architectural discipline.
Healthcare software compliance embedded in engineering culture is a fundamentally different capability than compliance added to engineering. A team with embedded compliance experience makes architecture decisions at the whiteboard, preventing expensive rework, rather than at the code review stage, where they generate it.
After go-live, how does your team monitor for compliance drift, specifically, how do you detect when a new field added by a source system contains PHI that your existing masking rules don't cover?
Continuous monitoring includes: automated PHI detection on new datasets (AWS Macie, Microsoft Presidio), schema change alerting that triggers masking rule review for every new field added to any source system, access control drift review on a quarterly cycle, and data observability monitoring for freshness and volume anomalies.
Vendor treats compliance as a project deliverable documented at handoff and then owned by the client. No ongoing schema monitoring. New fields containing PHI are discovered through audits or breaches, not proactively. Access control review requires a manual engagement request.
Schema drift is the most common post-deployment compliance failure in healthcare data systems. An EHR vendor releases an update that adds a new field containing patient identifiers, each change is a potential PHI exposure vector if masking and governance rules don't automatically detect and adapt. A development partner who declares the project complete at go-live has transferred all future compliance risk back to your team.
Does your standard contract give us full ownership of all source code, algorithms, and clinical IP developed during the engagement, and what are our rights to the codebase if we terminate the relationship?
The MSA explicitly grants work-for-hire ownership of all IP, including source code, documentation, clinical algorithms, and data models. PHI handling obligations are incorporated into the MSA (not just a separate BAA attachment). Vendor provides a code escrow or guaranteed handoff protocol with a reasonable notice period (30–60 days). Liability cap has explicit carve-outs for PHI breach damages.
Contract retains a "background IP" license covering the client's clinical algorithms developed during the engagement. PHI obligations exist only in a separate BAA not cross-referenced in the MSA. Exit provisions require 6+ months' notice with penalties. Liability cap applies equally to PHI breach damages, effectively capping the vendor's exposure for compliance failures.
If our product handles genomic data, clinical diagnostics, pharma R&D data, or precision medicine applications, does your team have specific experience with those data types and their regulatory frameworks?
Vendor has production experience with genomic file formats (FASTQ, BAM, VCF), multi-omics data integration, LIMS integration (HL7 v2 / FHIR R4), and the regulatory frameworks that apply: CLIA 42 CFR Part 493 for diagnostics labs, 21 CFR Part 11 for pharma systems, GxP data integrity requirements. Can distinguish CLIA compliance from HIPAA compliance and explain the engineering requirements of each.
Vendor conflates general "healthcare experience" with life sciences experience. Has built patient portal applications and telehealth products but has never handled genomic data, LIMS integration, or GxP-regulated environments. Cannot explain what CLIA requires of a software system.
The technical requirements for life sciences healthcare products are substantially different from clinical provider-facing products. Genomic data platforms must handle petabyte-scale sequencing data, process bioinformatics file formats with specific pipeline tools, satisfy CLIA test result traceability requirements, and comply with 21 CFR Part 11 for FDA-regulated environments, none of which overlap with building a patient portal or a telehealth application.
How three types of vendors compare across the 14 criteria
Before running this checklist against specific vendors, it helps to understand where each vendor type typically sits. This reflects the pattern that most health tech leaders encounter.
| Criterion | Generalist agency | Healthcare-specific agency | NonStop |
|---|---|---|---|
| HIPAA BAA | Signs on request, legal template | Yes, with standard technical controls | BAA + documented engineering safeguards before any PHI access |
| FHIR implementation | May have some FHIR experience | R4 integration standard | R4/R4B/R5 + SMART on FHIR + Bulk FHIR + CDS Hooks; production integrations with Epic, Cerner, Athena |
| PHI data masking | Encryption treated as equivalent | Masking in non-production environments | Delphix deterministic masking; DataSunrise dynamic masking; Tonic.ai synthetic data for ML training |
| AI explainability | Black-box ML models standard | Mentions explainability in scoping | Model explainability by design; FDA AI/ML SaMD guidance-aligned; SHAP/LIME integration in clinical AI builds |
| FDA SaMD experience | No FDA product experience | May have completed one SaMD project | DHF documentation, IEC 62304 lifecycle compliance, 510(k) pre-submission preparation |
| Data engineering depth | Separate engagement or not offered | Basic ETL and database integration | End-to-end data platform engineering (Databricks, Snowflake, Delta Lake, Kafka, Great Expectations) |
| Audit trail architecture | Application-layer logging | Row-level logging | Row-level immutable logs (Delta Lake); Unity Catalog column access audit; OpenMetadata full lineage |
| Post-launch monitoring | Ticket-based support model | SLA-based maintenance | Continuous PHI detection; schema change alerting; data observability; quarterly access control reviews |
Generalist agencies learn your compliance requirements on your timeline and your budget. Healthcare-specific agencies satisfy the standard compliance stack but often lack the depth required for AI-powered products, life sciences subspecialty requirements, or data engineering sophistication. NonStop's practice is built specifically for the intersection of all three.
Frequently Asked Questions
What is a Business Associate Agreement, and why does a software development company need to sign one?
What HIPAA technical safeguards should a healthcare software development company implement?
What is FHIR and why does it matter for healthcare software development?
What is the difference between SOC 2 Type I and SOC 2 Type II certification?
What is FDA Software as a Medical Device (SaMD), and which healthcare software products require FDA clearance?
What does PHI data masking mean, and why is it different from encryption?
How much does it cost to build a HIPAA-compliant healthcare software product?
What makes NonStop different from other healthcare software development companies?
Talk to NonStop
Use This Checklist in Your Active Vendor Evaluation
If you're currently evaluating development partners for a HIPAA-regulated healthcare product, NonStop will run this 14-point framework against any vendor on your shortlist and provide a written technical assessment, at no cost, with no obligation to engage NonStop. We do this because the healthcare software development market needs better vendor evaluation, and because we are confident in how NonStop performs against every criterion.
Request a Vendor Assessment Call →