Healthcare software carries more risk than most business applications. It handles protected health information (PHI), it has to fit into clinical and administrative workflows that cannot simply stop, and it usually has to exchange data with EHRs, labs, payers and other systems. Problems that would be an inconvenience elsewhere can become privacy incidents, billing errors or patient-safety issues.
This checklist covers the security, HIPAA-related and integration questions to settle before and during a healthcare software project, whether you build in-house or with a development partner.
Key takeaways
- Decide early whether the software will create, receive, store or transmit PHI; that shapes almost every other decision.
- HIPAA does not certify software. Compliance depends on how the system is designed, configured, operated and documented.
- Plan integrations (HL7 v2, FHIR, X12, vendor APIs) during discovery, not after the core build.
- Test clinical and administrative workflows end to end, with realistic but de-identified data.
1. Scope and Data Checklist
- Users and workflows: who uses the software (clinicians, front desk, billing, patients) and which workflows it supports.
- PHI inventory: which data elements are PHI, where they are created, stored, displayed and sent.
- Minimum necessary: does each role see only the data it needs?
- Data retention: how long records are kept, and how they are archived or deleted.
- Regulatory context: beyond HIPAA, consider state privacy laws, rules for specific data types (for example substance-use treatment records) and any payer or partner requirements.
2. HIPAA-Related Safeguards Checklist
The HIPAA Security Rule groups safeguards into administrative, physical and technical categories. For software teams, the technical safeguards translate into concrete design requirements:
- Access control: unique user IDs, role-based permissions, automatic logoff and an emergency-access procedure.
- Audit controls: logs of who viewed, created, changed or exported PHI, protected from tampering and reviewed regularly.
- Integrity: controls that prevent or detect improper changes to records.
- Authentication: strong authentication, with multi-factor authentication for remote and administrative access.
- Transmission security: encryption in transit (TLS) for all connections that carry PHI.
- Encryption at rest: encryption of databases, backups and file storage.
Administrative items matter too: a risk analysis, policies, workforce training, incident response and Business Associate Agreements (BAAs) with every vendor that handles PHI on your behalf, including hosting, email, support and analytics providers. No software or vendor is “HIPAA certified”; ask instead what safeguards exist and what evidence supports them.
3. Security Engineering Checklist
- Threat modeling for the main data flows during design.
- Secure coding standards and code review, with attention to the OWASP Top 10.
- Secrets stored in a secrets manager, never in code or configuration files.
- Dependency and container scanning in the build pipeline.
- Separate environments, with no real PHI in development or test.
- Backups that are encrypted, tested and restorable within agreed recovery times.
- Security testing before release, and a process for fixing findings.
4. Integration Checklist
Integration is often the most underestimated part of healthcare projects. Clarify:
- Which systems: EHR/EMR, practice management, labs, imaging, pharmacy, payers, clearinghouses, patient engagement tools.
- Which standards: HL7 v2 messages, HL7 FHIR APIs, X12 EDI transactions for eligibility and claims, or proprietary vendor APIs.
- Access: whether the vendor offers a sandbox, what the onboarding process involves and how long approval takes.
- Data mapping: how codes, identifiers and units map between systems, and who owns the mapping.
- Error handling: what happens when a message fails, arrives twice or arrives out of order, and who is alerted.
- Volume and timing: real-time, batch or both, and expected peak loads.
5. Usability and Workflow Checklist
- Shadow real users before designing screens; clinical workflows rarely match the documented process.
- Minimize clicks for frequent tasks and avoid alert fatigue.
- Design for interruptions: drafts, clear status and safe recovery.
- Consider accessibility for staff and patients.
6. Testing and Quality Checklist
- Acceptance criteria for each workflow, agreed with the people who perform it.
- End-to-end tests across integrations, using de-identified or synthetic data.
- Role and permission testing: each role can do what it should, and nothing more.
- Audit-log verification: the right events are recorded.
- Regression testing before every release.
- Performance testing for busy periods such as clinic opening hours or month-end billing.
For more detail, see our guide to healthcare software QA.
7. Operations Checklist
- Monitoring and alerting for uptime, errors and integration failures.
- An incident response plan that covers security incidents and possible breaches.
- A patching and update schedule.
- Documented support processes and who can access production data.
Questions to Ask a Healthcare Software Development Partner
- Will you sign a BAA, and which of your subcontractors will touch PHI?
- How do you keep real PHI out of development and testing?
- What integrations have you built with the systems we use, and how did you test them?
- How are access, audit logging and encryption designed into the system?
- What documentation will we receive to support our own risk analysis?
Planning healthcare software? Share your workflows, data and integrations, and we will help you scope the project and its risks before you commit.
See how we approach custom software development and our work in healthcare.
Frequently Asked Questions
01Is there such a thing as HIPAA-certified software?
No. There is no official HIPAA certification for software or vendors. HIPAA compliance depends on the safeguards in place and how the software is configured, operated and documented by the organizations using it.
02Do we need a Business Associate Agreement with our developer?
If the developer or any of its systems will create, receive, maintain or transmit PHI on your behalf, a BAA is generally required. If developers never access PHI, a BAA may not be needed, but confirm this with your compliance advisor.
03What is the difference between HL7 v2 and FHIR?
HL7 v2 is an older, widely used message format for exchanging events such as admissions or lab results. FHIR is a newer standard based on web APIs and resources, and is increasingly required for patient and third-party data access.
04Can we use real patient data for testing?
It is best avoided. Use synthetic or properly de-identified data in development and test environments, and restrict any exception to tightly controlled, documented circumstances.
05How early should integrations be planned?
During discovery. Vendor access, sandbox availability and data mapping often take longer than the coding itself, so they should shape the project plan from the start.
