Healthcare IT & HIPAA: frequently asked questions

What makes IT services HIPAA-compliant?

There is no such thing as HIPAA-certified software or a HIPAA-certified IT provider — HHS certifies no one. What exists is a set of required safeguards, and an IT provider is compliant when it implements them and can produce evidence on demand.

In practice that means: a signed Business Associate Agreement, encryption in transit and at rest, unique user identification with multi-factor authentication, least-privilege access, audit logging that is actually reviewed, tested backups with a documented recovery process, and workforce security training with completion records.

Be skeptical of any vendor advertising itself as “HIPAA certified.” The claim is not meaningful, and it is a reliable signal the vendor does not know the rule well.

Do you sign Business Associate Agreements?

Yes, and it is signed before any work touching protected health information begins. Under HIPAA an IT provider with access to PHI is a business associate, and the BAA is legally required — not a formality you can paper over later.

The BAA defines what we may access, the safeguards we maintain, our breach-notification obligations and timelines, and what happens to data when the engagement ends. If a prospective IT provider hesitates on this or offers to “get to it after onboarding,” treat that as disqualifying.

Can you help us pass a HIPAA audit?

Yes. Most practices fail audits on documentation rather than on technology — the controls exist but nobody can produce evidence they were implemented and reviewed.

The work covers a Security Risk Assessment (required annually, and the single most commonly missing artifact), written policies and procedures, training completion records, access-review logs, business associate inventories, and documented incident response. We produce the evidence trail alongside the controls, because an auditor asks for the record, not the intention.

What should a HIPAA Security Risk Assessment include?

A Security Risk Assessment must inventory every system that creates, receives, maintains, or transmits ePHI, identify threats and vulnerabilities to each, assess likelihood and impact, document existing controls, and produce a remediation plan with owners and dates.

Two things practices commonly get wrong: treating it as a one-time exercise when it is required at least annually and after any significant system change, and scoping it to the EHR alone while omitting email, backup, imaging systems, fax lines, and mobile devices — all of which routinely carry ePHI.

What is a healthcare MSP?

A healthcare MSP is a managed service provider that runs a practice's IT under a HIPAA business associate agreement, with the security controls and documentation the rule requires built into the service rather than sold as an add-on.

The difference from a general MSP is mostly discipline and evidence: a healthcare MSP expects to be inside an audit trail, understands that downtime during clinic hours has patient-safety implications, and knows the clinical systems — EHR, PACS, practice management, fax — well enough to troubleshoot without escalating everything to the software vendor.

How do MSPs support HIPAA compliance?

An MSP supports compliance on the technical safeguards side — access controls, encryption, audit logging, backup and recovery, patch management, endpoint protection, and email security — and supplies the documentation that proves those controls operate.

What an MSP cannot do is make a practice compliant on its own. Administrative and physical safeguards remain the covered entity's responsibility: workforce sanctions, the privacy officer role, patient authorization handling, and physical facility access. A provider claiming to deliver total HIPAA compliance is overselling.

What EHR and practice management systems do you support?

SynergyIQ supports the infrastructure layer under any EHR or practice management system — workstations, servers, network, backup, and the interfaces between systems — and has direct working experience across dental (Dentrix, Open Dental, Eaglesoft, Curve), pharmacy (PioneerRx, BestRx, Liberty), and DME/HME platforms (Brightree, WellSky CareTend, Bonafide, NikoHealth).

We are not a reseller for these products and we do not replace vendor support for in-application issues. What we do is own everything around the application, and act as the practice's advocate when an issue crosses the line between infrastructure and software — which is where most practices lose the most time.

What happens if our EHR or network goes down?

Clinical downtime is triaged ahead of everything else, because a practice that cannot access charts is a practice that cannot safely see patients. Response begins with isolating whether the failure is local (workstation, switch, internet) or upstream (the EHR vendor's hosted environment), because those have completely different fixes.

The preventable version of this question is answered before the outage: tested backups with a known recovery time, a documented downtime procedure staff have actually rehearsed, and redundant internet where the practice cannot tolerate a single-circuit failure.

Why is healthcare targeted by cyberattacks so often?

Healthcare is targeted because the data is unusually valuable and the operational pressure to restore service is unusually high. A medical record contains identity, insurance, and financial data in one place — it cannot be cancelled and reissued the way a credit card can — and a practice that cannot see patients is losing revenue every hour it stays down.

That combination makes attackers rationally confident a healthcare victim will pay quickly. Smaller practices are targeted disproportionately precisely because they hold the same valuable data with a fraction of a hospital's security budget.

How do you protect a practice against ransomware?

Ransomware defense is layered, because any single control fails eventually. The layers that matter most, roughly in order of value per dollar:

• Immutable, tested backups — the only control that reliably defeats ransomware after it succeeds. Untested backups are not backups.
• Multi-factor authentication everywhere, especially email and remote access — credential theft is the most common entry point.
• Endpoint detection and response (EDR) rather than legacy antivirus.
• Email filtering, since phishing remains the dominant delivery method.
• Prompt patching of operating systems and third-party software.
• Network segmentation so clinical systems, medical devices, and guest Wi-Fi cannot reach each other.

The backup layer deserves emphasis: it is what converts a business-ending event into a bad week.

How do you protect connected medical devices?

Medical devices are handled primarily through network segmentation, because most cannot be secured directly. Imaging systems, monitors, and diagnostic equipment frequently run unsupported operating systems that the manufacturer forbids patching, and installing security agents on them can void certification.

The workable approach is to isolate devices on their own VLAN, restrict traffic to only the destinations they legitimately need, monitor that segment for anomalies, and keep an accurate device inventory. You cannot harden the device, so you constrain what it can reach and what can reach it.

How is PHI protected in a cloud or Microsoft 365 environment?

Cloud PHI protection rests on a BAA with the cloud provider, correct tenant configuration, and controls the provider does not enable by default. Microsoft will sign a BAA covering Microsoft 365, but signing it does not configure anything — a default tenant is not a compliant tenant.

The gaps we most often find in practice: multi-factor authentication not enforced for every user, audit logging left off or never reviewed, mailbox auto-forwarding to personal accounts permitted, retention and legal hold unset, and no third-party backup of Microsoft 365 data — Microsoft explicitly does not guarantee long-term recovery of deleted content.