HIPAA Compliance for New Software Applications
HIPAA compliance for a new software application requires the developer and deploying organization to identify where electronic Protected Health Information is created, received, maintained, or transmitted and implement appropriate safeguards before the application handles real patient information. A functioning prototype is not evidence that the application satisfies the HIPAA Privacy Rule or HIPAA Security Rule. The application also needs to account for access controls, authentication, vendors, Business Associate Agreements, credentials, logging, data storage, backups, integrations, AI services, and incident response.
These requirements are particularly relevant to applications created using AI coding tools. AI can generate an interface, database, authentication process, and application logic quickly, but generated code can contain architectural decisions that were made to make the application function rather than to satisfy healthcare privacy and security requirements.
Determine Whether HIPAA Applies to the Application
The first compliance question concerns the relationship between the software application and the organizations using it. HIPAA can apply when software creates, receives, maintains, or transmits PHI on behalf of a HIPAA Covered Entity or Business Associate.
A software developer providing a service to a healthcare provider can therefore become a Business Associate when the service involves PHI. The contractual and technical environment needs to reflect that relationship before real patient information is introduced.
A consumer health application that operates independently of a HIPAA Covered Entity does not become subject to HIPAA solely because it contains health information. Other federal or state privacy and breach notification requirements can apply to consumer health information outside HIPAA.
Map Every Location Where Electronic PHI Exists
A new application can distribute electronic PHI across more systems than the development team initially expects. Patient information can exist in the primary database, cloud storage, backups, application logs, error reports, analytics systems, email services, authentication platforms, and third-party integrations.
AI-generated applications create an additional concern because development tools can automatically create databases, storage locations, logging services, and connections while generating the application. A developer who examines only the main database can therefore overlook other locations containing electronic PHI.
The security risk analysis should identify these locations and examine the risks and vulnerabilities affecting them. This process establishes the information environment that needs to be protected rather than assuming that PHI exists only where it appears on the application’s interface.
Review Every Vendor That Can Access PHI
A compliant hosting provider does not make the complete application compliant. Each third party that creates, receives, maintains, or transmits PHI needs to be assessed according to the service it performs.
A software stack can include hosting, database, analytics, monitoring, email, authentication, customer support, AI, and backup providers. A vendor that is suitable for ordinary software development might not offer services appropriate for handling PHI.
Business Associate Agreements should be executed when required. Developers also need to establish which products and service tiers are covered because a vendor can make a Business Associate Agreement available for one service without extending it to every product or feature.
Separate Prototyping From Production
AI coding platforms can provide an efficient environment for developing and testing application concepts. That does not establish that the same platform should receive real PHI.
Prototype development can use synthetic patient information that does not identify real individuals. This allows developers to test workflows and application functionality without introducing PHI into services that have not completed the organization’s privacy, security, and vendor review.
Moving from prototype to production should therefore involve more than changing the application’s status or domain name. The underlying architecture, vendors, credentials, access controls, data flows, logging, and security configuration need to be reviewed before real patient information is processed.
Enforce Access Controls on the Server
An application should restrict access to PHI before information is transmitted to the user’s device. Hiding unauthorized records within the browser does not prevent access if the underlying information has already been delivered to the browser.
This can occur when an application retrieves a complete patient dataset and uses front-end code to display only the records assigned to the current user. The screen can appear correct while unauthorized patient information remains visible through browser development tools or network traffic.
Server-side access controls prevent unauthorized records from being transmitted in the first place. The server should establish which records the authenticated user can access before returning information to the application interface.
Combine Role and Relationship-Based Access Controls
Healthcare access decisions can require more than identifying an employee’s job role. Role-based access controls can determine whether a user is a physician, nurse, administrator, or another type of workforce member, but that does not establish which individual patients the person should access.
Relationship-based controls can add another layer by determining whether the user has an appropriate relationship with a particular patient or record. A clinician can therefore receive the permissions associated with the clinical role while remaining restricted to the patients the clinician is authorized to access.
These controls should operate within the application’s back end rather than depending on instructions in the interface or assumptions about how employees will use the system.
Protect API Keys and Other Credentials
Database credentials, API keys, service credentials, and other secrets should not be exposed through front-end application code. A credential sent to the user’s browser can potentially be extracted and used independently of the application’s intended controls.
Broad service credentials create additional risk because they can bypass restrictions that apply to ordinary users. Credentials should be limited to the permissions required for the particular service or function.
Developers also need to consider source-control history. Removing an exposed credential from the current application does not necessarily remove earlier copies stored in Git history.
An exposed credential should therefore be treated as a security event requiring investigation. The response can include revoking or rotating the credential, reviewing available access logs, determining what information the credential could access, and evaluating whether an impermissible use or disclosure of PHI occurred.
Prevent Patient Identification Through Account Functions
Authentication features can disclose sensitive information even when they do not display a medical record. A password reset function that confirms whether a particular email address exists can allow an attacker to determine whether an individual has an account with a healthcare organization.
An attacker can automate requests using lists of email addresses and compare the responses. Different messages for valid and invalid accounts can effectively reveal part of the organization’s patient or user population.
Uniform responses reduce this disclosure. The application can state that instructions will be sent if an account exists without confirming whether the submitted identifier belongs to an actual account.
Set Appropriate Session Controls
New applications should account for the environment in which authenticated sessions will remain open. Long-lived sessions can create exposure when healthcare personnel use shared workstations or devices accessible to other people.
Session duration should reflect the application’s risks and operating environment. Authentication and automatic session termination controls can reduce the possibility that one workforce member accesses another user’s active session after a device is left unattended.
Session design should be considered during development rather than inherited from default settings chosen for consumer applications where convenience can receive greater weight.
Use Tokenization Where Appropriate
Tokenization can reduce the number of systems that require direct patient identifiers. An application can replace identifying information with a generated token and maintain the connection between the token and the individual in a separately protected environment.
The main application can then process information associated with the token without continuously processing the patient’s name, telephone number, or other direct identifiers. Access to the identity mapping can be restricted to the functions that require it.
Tokenization does not replace the safeguards required for PHI. It can form part of an architecture designed to reduce unnecessary exposure of identifying information.
Control PHI Sent to AI Models
Applications incorporating large language models need to identify exactly what information is transmitted to the AI provider. Sending an entire patient record because only a small portion is required creates unnecessary exposure.
Data can sometimes be transformed before transmission while retaining information required for the AI function. For example, an application that requires age-related clinical context might calculate an age or age range rather than transmitting an exact date of birth.
The appropriate approach depends on the function being performed and the information required to perform it. Removing information without considering its clinical relevance can impair the output, while transmitting unnecessary identifiers increases privacy exposure.
Check Each AI Service Before Sending PHI
An agreement with an AI provider should not be interpreted as permission to send PHI through every feature offered by that provider. Different APIs, models, tools, web functions, logging arrangements, and data retention settings can operate under different conditions.
The organization should establish which services are covered by the applicable Business Associate Agreement and whether the selected configuration can be used with PHI. Data retention and secondary processing also need to be examined.
This review should occur when features change. Adding a new AI tool to an existing application can create a new data flow even when the application already uses another service from the same provider.
Restrict What AI Agents Can Retrieve
Prompt instructions should not serve as the primary access control for an AI agent. An instruction telling an LLM to access only the current patient’s information does not technically prevent the model from requesting other records if its tools provide broader database access.
The application should restrict the credentials and tools available to the AI so the model cannot retrieve information outside the authorized scope. If the user is permitted to access one patient’s information, the AI tool used for that request should not possess unrestricted authority over the complete patient database.
This architecture also limits the effect of prompt injection. Malicious instructions contained in user input or retrieved documents cannot obtain records that the AI system is technically unable to access.
Apply Authorization Before RAG Retrieval
Retrieval-Augmented Generation creates a particular access-control issue because the application automatically selects documents that appear relevant to a user’s request. Similarity does not establish authorization.
A vector search could determine that another patient’s psychiatric record is mathematically similar to the subject of a clinician’s query. That does not provide a permissible basis for retrieving the record and placing it in the LLM context.
Access restrictions should therefore apply before the retrieval process searches for relevant information. The RAG system should search only the records the requesting user is authorized to access rather than searching the complete dataset and attempting to filter the results afterward.
Test Backups by Restoring Them
Creating backups does not establish that an application can be recovered successfully. Backup procedures should include testing whether stored information and systems can actually be restored.
A restoration test can identify corrupted backups, missing configuration information, incomplete dependencies, authentication problems, and other failures that remain hidden while backups are merely being created and stored.
Recovery planning should also account for dependencies outside the primary database. An application can require configuration files, encryption material, identity services, integrations, and other components before restored patient information becomes operationally usable.
Design for Healthcare Interoperability Early
A new healthcare application that will exchange information with electronic health record systems should account for interoperability during architectural design. Healthcare data standards can influence how information is represented and exchanged throughout the application.
FHIR and other healthcare interoperability standards should not automatically be treated as translation problems that can be addressed after the application’s internal data model has been completed. Late changes to the underlying data structure can require substantial redevelopment.
The expected EHR integrations and information flows should therefore be identified while the application’s data model is still being designed.
Prevent Clinical Messages From Disappearing
Healthcare integrations need to account for failures that occur after information has been received but before it has been processed. A critical laboratory result, for example, should not disappear because the receiving application crashes during processing.
A queue can allow the application to preserve an incoming message before processing it. If processing fails, the retained message can be retried rather than being permanently lost after the sending system believes delivery succeeded.
This type of reliability control extends beyond ordinary application performance. Missing clinical information can affect decisions made during patient care.
Test the Application Under Realistic Workloads
Generated code can function correctly with a small demonstration dataset while performing poorly when exposed to production volumes. Inefficient database queries, missing indexes, and repeated retrieval operations can become apparent only when the application contains large numbers of patient records.
Performance therefore needs to be tested under conditions that reflect the expected clinical workload. An application used during patient care cannot be assessed solely by whether each feature functions during development.
Availability and performance can affect access to electronic PHI when clinicians depend on the application during treatment. Scalability should therefore form part of production readiness rather than being deferred until usage increases.
Assess Whether Clinical AI Creates Additional Regulatory Requirements
HIPAA compliance does not establish that an AI healthcare application satisfies every regulatory requirement that can apply to the software. Functionality that analyzes patient information and provides clinical recommendations can raise separate questions concerning regulation of medical devices.
The intended user and the function performed by the software can affect the analysis. Software that assists a healthcare professional in reviewing information can present different regulatory issues from software that provides patients with diagnostic or treatment outputs.
The ability of a clinician to independently review the basis for a software recommendation can also affect the regulatory analysis for certain clinical decision support functions. Product teams should therefore consider the intended clinical function while the software architecture and interface are being designed.
Document the Application’s HIPAA Compliance Decisions
Technical controls should be supported by documentation explaining how the organization evaluated risks and implemented safeguards. The security risk analysis provides one part of this record, but documentation can also address vendor reviews, Business Associate Agreements, access-control decisions, security configurations, incident procedures, backup testing, and changes to the application.
Documentation becomes particularly relevant when the organization needs to reconstruct why a particular safeguard was selected or determine what controls existed when an incident occurred.
Development records should also distinguish experimental functionality from approved production functionality. A feature that is safe to test with synthetic information should not enter production with PHI merely because it performed correctly during development.
AI-Generated Code Still Requires Human Compliance Review
AI coding tools can reduce the time required to create a healthcare software prototype, but they do not transfer responsibility for HIPAA compliance to the AI system. Generated code needs security review, testing, risk analysis, and architectural assessment before it is used to process PHI.
The distinction between a prototype and a production healthcare application is therefore based on more than whether the software works. Production readiness requires an architecture that restricts access before information is disclosed, controls third-party data flows, protects credentials, supports recovery, manages AI access, and continues to operate securely at the scale expected in healthcare.
Human oversight remains responsible for deciding whether those controls satisfy the application’s regulatory and operational requirements. AI can generate the code, but the organization deploying the software remains responsible for how PHI is handled.
Software Publishers Can Be HIPAA Business Associates
Software publishers that create, receive, maintain, or transmit PHI on behalf of a HIPAA Covered Entity are generally HIPAA Business Associates and need to comply with the HIPAA requirements that apply to their activities. This can include SaaS providers, EHR vendors, cloud-based healthcare applications, patient management platforms, and other software services that maintain PHI for healthcare customers. Business Associate status can apply even when a software publisher does not routinely view the PHI maintained by its service.
A software publisher that qualifies as a Business Associate needs its own HIPAA compliance program rather than relying solely on the security capabilities built into its product. The program should address the HIPAA Security Rule, applicable provisions of the HIPAA Privacy Rule, the HIPAA Breach Notification Rule, security risk analysis and risk management, workforce training, policies and procedures, incident management, contingency planning, and required documentation.
Software publishers also need to manage their Business Associate Agreements. This includes entering into Business Associate Agreements with HIPAA Covered Entities where required and identifying subcontractors that create, receive, maintain, or transmit PHI while providing services to the software publisher. Appropriate Business Associate Agreements are also required with Business Associate subcontractors.
Managing these requirements can involve substantial documentation, particularly as a software company adds employees, healthcare customers, cloud services, and other subcontractors. HIPAA compliance software can be used to manage the compliance program by organizing compliance activities, risk assessments, policies, training records, vendor management, documentation, and other ongoing HIPAA requirements in a structured system.
A documented compliance program can also support customer due diligence. Healthcare organizations evaluating a software vendor can request evidence that the vendor has assessed its risks, trained its workforce, established appropriate safeguards, and implemented procedures for responding to security incidents. The technical security of the application and the HIPAA compliance of the organization publishing it therefore need to be assessed separately.