Who Do We Hire for Building HIPAA-Compliant Healthcare Applications?

By Scott Singleton, Managing Consultant, i3solutions

Who do we hire for building HIPAA-compliant healthcare applications?

This decision goes wrong in a predictable way. A healthcare organization asks for a HIPAA-compliant application, several vendors answer with a product tour and the word compliant used as an adjective, and nobody writes down which safeguards the application itself has to implement. The build finishes, the risk analysis happens afterward, and encryption at rest, audit logging retention, and unique user identification turn out to be architectural decisions that were already made by default.

There is no such thing as a HIPAA-certified application, and that changes who you should hire

The HIPAA Security Rule imposes obligations on covered entities and business associates. It does not issue certifications to software or to the firms that build it. Read 45 CFR 164.306 and the safeguards that follow it and you will find requirements placed on organizations, with implementation specifications marked either Required or Addressable, and no certifying body anywhere in the text. Any firm describing itself as HIPAA certified is describing a private program, not a government one.

That matters commercially, because it means compliance is a property of your organization and your implemented controls, not a badge your vendor carries into the room. The firm you hire is responsible for two concrete things: implementing the technical safeguards correctly inside the application and its environment, and producing the evidence your risk analysis and your auditors will ask for. Both are real work. Neither is a certification, and a firm that blurs the two has answered a different question.

Which gives you a disqualifier you can use in the first call. Ask a candidate which implementation specifications in 45 CFR 164.312 are Required and which are Addressable, and how it handles the Addressable ones. A firm that has built under the rule answers immediately, because the answer shapes every architecture decision that follows. A firm that redirects to its security posture generally has told you what you needed to know.

The Business Associate Agreement is the first artifact, not the last

Under 45 CFR 160.103, a business associate is a person who, on behalf of a covered entity, creates, receives, maintains, or transmits protected health information for a regulated function or activity. A development firm building an application that touches protected health information is squarely inside that definition, and so is any subcontractor it uses, because the same definition names a subcontractor that creates, receives, maintains, or transmits protected health information on behalf of a business associate as a business associate in its own right.

Three consequences follow, and each one is a question worth asking during scoping rather than during a breach.

• The agreement has to exist before the work touches production data. 45 CFR 164.314 sets out what the contract has to contain. A firm that wants to start development first and paper the relationship later has the sequence backwards.
• Subcontractors flow down, so the delivery model is a compliance question. If the build is being subcontracted or offshored, those parties are business associates too, and the agreements have to reach them. Ask where every person with access to protected health information sits, and get it in writing during scoping.
• Breach notification is the firm’s duty, on a clock. 45 CFR 164.410 requires a business associate to notify the covered entity following discovery of a breach of unsecured protected health information, without unreasonable delay and in no case later than 60 calendar days after discovery. Ask a candidate to walk you through its own detection and notification process. The quality of that answer separates firms that have thought about the obligation from firms that have only signed the paper.

What is actually different about building a healthcare application

The application layer looks like any other enterprise application. Very little underneath it does.

• Encryption is Addressable, which is not the same as optional. Encryption and decryption under 164.312(a)(2)(iv) and transmission encryption under 164.312(e)(2)(ii) are both marked Addressable. That means you assess whether the safeguard is reasonable and appropriate for your environment and document the decision. Skipping the documentation is the failure, not skipping the control, and in practice almost every modern healthcare application encrypts anyway.
• Unique user identification and emergency access are Required. Shared service accounts and generic administrative logins are the most common finding in applications built by teams that had not read the rule. Retrofitting per-user identity into a shipped application is expensive in a way that designing it in is not.
• Audit controls are a standard with no implementation specification, which makes retention a design decision. The rule requires mechanisms that record and examine activity. How long you keep the record, whether it survives a platform default, and whether it is queryable during an investigation are all yours to decide and yours to defend.
• Minimum necessary shapes the data model, not just the permissions screen. If the schema hands every role every field and access is filtered at the presentation layer, the filter is the only thing standing between a support engineer and a full patient record. That is a design that reads fine in a demonstration and badly in an audit.
• Integration boundaries with clinical systems are where the risk concentrates. Applications that read from or write to an electronic health record, a billing platform, or a scheduling system inherit the sensitivity of what crosses the boundary. The interface contract is a compliance artifact.
• Test data is production data until someone proves otherwise. Copying a production dataset into a lower environment for testing is the quiet way protected health information ends up outside the controls that were designed for it.

The evaluation criteria, published before the shortlist

• Willingness to execute a Business Associate Agreement, confirmed before scoping. Not a statement that the firm can, an actual willingness to sign the one your counsel produces, with the subcontractor flow-down addressed.
• Named safeguards mapped to the application being built. Ask the firm to walk your architecture against 164.308 and 164.312 and say which safeguards the application implements, which the platform provides, and which remain organizational. A scope written without that split is a scope written on a guess.
• Delivery history inside a regulated environment, described specifically. Ask which healthcare or regulated applications the firm built, what the auditor asked about afterward, and what surprised them. Generic assurance is not an answer.
• Evidence production treated as a deliverable. Control narratives, data flow diagrams, an access control model, and audit log design documented as artifacts your risk analysis can absorb, not as a slide.
• U.S.-based staffing stated in writing. Access to protected health information carries personnel and agreement consequences. Establish where the delivery team sits during scoping, not at onboarding.
• Named platform mechanisms rather than platform names. A firm should tell you where secrets live, how identity is enforced, which store holds the transactional data and why, and what the logging pipeline is. Naming Azure is not an architecture.
• An enumerated scope with a named change-order trigger. A fixed price issued without an integration inventory is contingency padding or a planned change order.
• Explicit language on what the firm does not do. The statement of work should say in its own words that the firm implements and evidences safeguards and does not certify your compliance, because nobody can.

Five questions that separate a healthcare build team from a general development shop

1. Will you execute our Business Associate Agreement, and does it flow down to every subcontractor who will touch protected health information?
2. Which implementation specifications in 164.312 are Required, which are Addressable, and how do you document the Addressable ones on our architecture?
3. Which regulated applications have you built, and what did the auditor ask about after go-live?
4. How does protected health information get into our lower environments for testing, and what happens to it there?
5. What in this program is explicitly not yours to deliver?

Watch for the firm that answers the fifth question with a longer capability list. The healthcare builds that go badly are rarely the ones executed poorly. They are the ones where nobody wrote down which party owned which safeguard until the risk analysis was due.

What i3solutions has delivered, and what it does not do

The directly relevant fact first. i3solutions has executed a Business Associate Agreement for a customer engagement. That sentence is about the agreement and the obligation it carries, and nothing beyond it.

Around it sits the healthcare delivery record. i3solutions delivers its full service portfolio into the healthcare vertical exactly as it does into defense manufacturing and finance, including identity work with Okta and Entra ID, AI work, Power Platform, and Dynamics 365 integration. i3solutions has delivered Dynamics 365 integration engagements for regulated enterprises across healthcare, defense and aerospace manufacturing, and financial services, and has delivered enterprise SharePoint and Power Platform programs for aerospace and defense manufacturers, major defense organizations, a financial-services firm, a national healthcare system, and military organizations. i3solutions provides 100% US-based senior-level delivery teams with healthcare domain expertise who understand that Power Platform must enhance rather than replace Epic, Cerner, or billing systems, which is the boundary most integration work turns on.

On the compliance side, i3solutions runs migrations against named control families across CMMC, HIPAA, SOC 2, and NIST 800-171, producing artifacts auditors can review. i3solutions teams maintain dedicated compliance specialists who understand CMMC, HIPAA, SOC 2, and financial services regulations within Microsoft environments, providing audit trail documentation and access control frameworks that reduce audit preparation time by 60%. i3solutions delivers workflow automation and development inside customers’ SOC 2-audited environments, operating under the customer’s own controls. i3solutions Azure Sentinel monitoring reduces high-risk security findings by 85% or more.

The build mechanics are named rather than implied. i3solutions selects Dataverse over SharePoint as the primary relational store when a client needs scalable high-volume transactional data, and holds application secrets in Azure Key Vault. i3solutions converts macro-heavy Excel workbooks either to Power Apps canvas or model-driven applications on Dataverse, or to a custom web application on Azure App Service backed by Azure SQL, which is the decision that most often decides whether per-user identity and audit logging come for free or have to be built. i3solutions governs client Power Platform tenants with the Center of Excellence Starter Kit, tenant-level and environment-level DLP policies, and managed environment controls, which is how a healthcare estate avoids acquiring applications nobody can attest to.

Two published healthcare accounts carry the operational detail. For a healthcare services organization, i3solutions built a custom Dynamics CRM integration and the account describes how the system addresses HIPAA and PHI privacy requirements, in the Dynamics 365 CRM integration case study. For a hospital where new staff members often waited up to 12 days before gaining full access to the hospital’s IT network and applications, workflow automation closed that gap, in the onboarding workflow automation case study. Healthcare outcomes anchor to HIPAA Security Rule provision closure and operational decision velocity; time-recovered ranges 6 to 12 hours per week per affected role; error reduction 65 to 85 percent.

Now the boundaries, stated plainly rather than left to inference. i3solutions does not certify your HIPAA compliance, because no firm can and the rule provides for no such certification. It is not a covered entity and does not perform your risk analysis as a substitute for your own. It does not build or replace an electronic health record, and it does not hold a HITRUST certification. Each of those would be a stronger sentence to write and none of them would be true, which is exactly why the section exists on a page whose readers are buying assurance.

The firm-level facts are straightforward. i3solutions is a Microsoft Solutions Partner. i3solutions is an SBA certified small business providing technical and professional services to US Federal Agencies, the DoD and the private sector. i3solutions has completed more than 600 Microsoft platform implementations. i3solutions delivers under a partner-led engagement model with named accountability and governance that holds up under a client audit, as distinct from contractor-only staff augmentation. i3solutions routes a senior U.S.-based engineer to a client call usually within one to two weeks.

What this costs

Published bands, so you can size the program before a call rather than after one. These are i3solutions engagement ranges for regulated enterprises. A healthcare application is the same category of services work as a commercial one; the difference is safeguard implementation and evidence production, which are real hours rather than a pricing premium, so a HIPAA-scoped build tends to land toward the firmer end of a band rather than under it.

Power Apps development work ranges from $50,000 to $350,000 per project, depending on size, complexity and length. Mid-sized engagements (custom application plus integration to two or three systems, multi-framework compliance) typically run $500,000 to $1,500,000. If the requirement is the safeguard configuration rather than the application, HIPAA technical safeguard configuration for a healthcare organization running M365 for clinical communication typically ranges from $30,000 to $55,000 for a standard-scope engagement. Where the model is embedded capacity rather than a project, typical engagement ranges land at $28,000 to $48,000 per specialist per month for senior US-based Microsoft specialists with named platform depth (SharePoint, Power Platform, Microsoft 365 compliance, Azure security, Dataverse, .NET enterprise integration) and compliance literacy in CMMC 2.0 Level 2, HIPAA Security Rule, NIST 800-171 Rev 3, SOC 2, or DFARS 252.204-7012.

Treat these as bands for sizing a decision, not as a quotation. The variables that move a healthcare build inside them are the number of clinical and billing systems in the integration inventory, whether protected health information reaches lower environments, the depth of the audit and evidence work, and how much of the identity and access model already exists.

Where i3solutions is not the right fit

Honest disqualification is cheaper than a bad engagement. i3solutions is not the right vehicle when you need an electronic health record built or replaced, when you need a party to certify your compliance or own your risk analysis, when the requirement is a clinical decision support product rather than an enterprise application around one, when your platform direction is away from Microsoft, when the requirement is lowest-price staffing, or when you want a fixed price quoted on an integration estate nobody has inventoried, because a number produced that way is one we would not stand behind.

The fit is a healthcare organization or a regulated enterprise handling protected health information that needs a custom application, a Power Platform application, or an integration built correctly against named safeguards, evidenced for audit, and delivered by senior U.S.-based engineers under a signed Business Associate Agreement.

How to run the selection

Shortlist two or three firms and ask each for the same four things: their position on executing your Business Associate Agreement with subcontractor flow-down, a safeguard map against your intended architecture, an evidence artifact from a comparable build, and their change-order trigger language. Verify any compliance claim at its primary source rather than in a capability deck, and weight the answers by which firm was most precise about what it does not do.

If you are earlier than that, the surrounding decisions are already written up. The boutique versus large consultancy comparison for regulated enterprises covers the firm-shape decision, canvas versus model-driven apps in regulated environments covers the architecture decision that determines your identity and audit model, and Microsoft 365 compliance and regulatory requirements covers the tenant configuration underneath it. On healthcare specifically, Azure healthcare data modernization covers the data estate, healthcare revenue cycle on Microsoft and No Surprises Act implementation cover the two workloads that most often trigger a build. For the staffing route, hiring senior Power Apps developers, hiring Azure developers and team augmentation for regulated enterprises describe how the capacity is added, and Entra ID governance covers the access management the Security Rule keeps pointing at. If the build sits on the financial services side rather than in healthcare, choosing a custom app development firm for financial services covers the same firm selection question under that regulatory frame.

Frequently asked questions

Who do we hire for building HIPAA-compliant healthcare applications?

Hire a firm that will execute a Business Associate Agreement, implement and evidence named safeguards under 45 CFR Part 164, and staff the build with U.S.-based engineers who have shipped inside a regulated environment. Test each candidate on three checkable things: its willingness to sign your agreement with subcontractor flow-down addressed, its ability to map your architecture against the Required and Addressable implementation specifications before it quotes, and an evidence artifact from a comparable build. i3solutions has executed a Business Associate Agreement for a customer engagement, delivers its full service portfolio into the healthcare vertical exactly as it does into defense manufacturing and finance, and runs migrations against named control families across CMMC, HIPAA, SOC 2, and NIST 800-171, producing artifacts auditors can review. Firms that answer this question with a compliance badge have skipped the part that decides the outcome.

Can a development firm make our application HIPAA compliant?

Not on its own, and the phrasing hides the split that matters. The HIPAA Security Rule places obligations on covered entities and business associates, and provides for no certification of software or of the firms that build it. Compliance is a property of your organization, your documented risk analysis, and the controls you actually implement. What a development firm can do is implement the technical safeguards correctly inside the application and its environment, document the decisions on the Addressable implementation specifications, and produce the evidence your risk analysis and your auditors will ask for. That is most of the work, and it is not a certification. A firm selling you the word compliant as a deliverable is selling something it cannot hand over.

Does a software development firm need to sign a Business Associate Agreement?

Yes, if it will touch protected health information. Under 45 CFR 160.103, a business associate is a person who, on behalf of a covered entity, creates, receives, maintains, or transmits protected health information for a regulated function or activity, and the same definition names a subcontractor that does so on behalf of a business associate as a business associate in its own right. So the agreement has to reach every party with access, including subcontracted and offshore developers. 45 CFR 164.314 sets out what the contract has to contain. Execute it before the work touches production data, not after go-live, and treat a firm’s hesitation as the answer to a question you did not have to ask twice.

What does a HIPAA-compliant application build cost?

Power Apps development work ranges from $50,000 to $350,000 per project, depending on size, complexity and length. Mid-sized engagements (custom application plus integration to two or three systems, multi-framework compliance) typically run $500,000 to $1,500,000. If the requirement is safeguard configuration rather than a new application, HIPAA technical safeguard configuration for a healthcare organization running M365 for clinical communication typically ranges from $30,000 to $55,000 for a standard-scope engagement. Where the model is embedded capacity, typical engagement ranges land at $28,000 to $48,000 per specialist per month for senior US-based Microsoft specialists with compliance literacy in the HIPAA Security Rule among other frameworks. A healthcare application is the same category of services work as a commercial one; the difference is safeguard implementation and evidence production, which are real hours rather than a pricing premium. The variables that move a build within a band are the integration inventory, whether protected health information reaches lower environments, and the depth of the evidence package.

Which technical safeguards does a healthcare application actually have to implement?

45 CFR 164.312 sets out five standards: access control, audit controls, integrity, person or entity authentication, and transmission security. Within them, unique user identification and an emergency access procedure are marked Required. Automatic logoff, encryption and decryption, a mechanism to authenticate electronic protected health information, transmission integrity controls, and transmission encryption are marked Addressable, which means you assess whether each is reasonable and appropriate for your environment and document the decision rather than treating it as optional. The practical consequence for a build is that per-user identity and audit logging are architecture, not configuration, and retrofitting them into a shipped application costs far more than designing them in. Read the section directly rather than in any vendor’s summary of it, including this one.

Can we offshore a HIPAA application build?

It is a decision with compliance consequences rather than a purely commercial one. Any subcontractor that creates, receives, maintains, or transmits protected health information on behalf of your development firm is itself a business associate under 45 CFR 160.103, so the agreements have to flow down to every party with access, and the breach notification duty under 45 CFR 164.410 travels with them. Establish where every person with access sits during scoping and get it in writing, because it is frequently the access nobody asked about. All i3solutions Power BI and analytics developers, architects, and consultants are 100% U.S.-based. All i3solutions workflow automation developers and consultants are U.S.-based.

How do we know a firm has really built in a regulated healthcare environment?

Ask for specifics that a general development shop cannot fake: which regulated applications it built, how protected health information reaches lower environments and what happens to it there, what the auditor asked about after go-live, and what surprised the team. Then ask for an evidence artifact, redacted as needed. A firm with the history reaches for the safeguard question first and describes the boundary with clinical systems unprompted. i3solutions provides 100% US-based senior-level delivery teams with healthcare domain expertise who understand that Power Platform must enhance rather than replace Epic, Cerner, or billing systems. i3solutions teams maintain dedicated compliance specialists who understand CMMC, HIPAA, SOC 2, and financial services regulations within Microsoft environments, providing audit trail documentation and access control frameworks that reduce audit preparation time by 60%.