Cloud Based EHR

What is a cloud based EHR?

A cloud based EHR is electronic health record software that the vendor hosts on cloud infrastructure and delivers through a browser or app, usually by subscription. The vendor runs servers, backups, patching and upgrades. The practice still owns user access, configuration, workforce training and the contract terms that decide how its data can leave.

Cloud compared with on-premise hosting

• Who runs the platform: In a cloud EHR the vendor runs servers, storage and upgrades. On premise, your IT team or a hosting partner does.
• How upgrades arrive: A cloud vendor upgrades all customers on its own schedule. On-premise systems are upgraded as local projects, often a version or two behind.
• How you connect: Cloud EHRs expose web APIs and vendor-hosted interface services. Older on-premise systems often rely on local HL7 v2 feeds and direct database reports.
• Where risk moves: Hardware failure and patching move to the vendor. Account management, device security, configuration and contract terms stay with you.

What does a cloud EHR contract need to say?

A cloud EHR contract needs a business associate agreement with the required HIPAA terms, plus commercial terms on data export, fees, API access, service levels and subcontractors. The HIPAA terms are set by regulation. The commercial terms are negotiated, and they decide how easily you can connect other systems or leave.

• Business associate status: HHS guidance on HIPAA and cloud computing says a cloud service provider that creates, receives, maintains or transmits ePHI is a business associate, even if it stores only encrypted data it cannot view.
• Required agreement terms: Under 45 CFR 164.504(e), the agreement must require the vendor to safeguard ePHI under the Security Rule, report breaches and other improper disclosures, flow the same terms down to subcontractors, and return or destroy PHI at termination where feasible.
• Breach reporting: 45 CFR 164.410 requires a business associate to notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery. Many buyers negotiate a shorter window.
• Information blocking: Developers of certified health IT are actors under 45 CFR Part 171, so fees or contract terms likely to interfere with access, exchange or use of EHI can be information blocking unless an exception applies.
• Certification: The Certified Health IT Product List (CHPL) from ASTP/ONC shows which certification criteria a product version is certified to, which matters if you report to CMS Promoting Interoperability.

Commercial terms worth negotiating

Beyond the HIPAA terms, read the order form for price changes at renewal, per-provider or per-location minimums, charges for each new interface, and fees for sandbox or production API access. Ask how much notice the vendor gives before retiring a feature or an interface version. Ask, too, whether your data may be used to train the vendor's own models, and whether that use is opt-in.

Which security duties stay with the practice?

The practice keeps every duty tied to its own people, devices and settings. The vendor secures the platform, but the HIPAA Security Rule still applies to how your workforce signs in, what devices they use and how accounts are granted and removed.

• Risk analysis: Your HIPAA risk analysis must cover the cloud EHR, including how staff reach it and where exports land.
• Accounts and roles: Unique user identification is a required Security Rule specification. Shared logins at the front desk break it, and leavers need same-day removal.
• Audit review: Audit controls are required. Confirm you can search access logs by patient and user yourself, rather than asking the vendor for a report.
• Devices and networks: Clinic workstations, tablets and home devices that open the EHR need screen locks, updates and disk encryption under your policies.
• Sign-in strength: Single sign-on and multi-factor authentication are good practice. HHS proposed making MFA required in a January 2025 rule, so ask whether the vendor supports it for every role today.

The cloud EHR buyer's checklist

Use this checklist alongside the demo scorecard. Each item is something you can verify in a document, a sandbox or a reference call, not a feature claim.

• Check 1, Business associate agreement: Signed before any PHI moves, covering subcontractors, breach reporting time and return or destruction of data at termination.
• Check 2, Data exit terms: The contract names the export format, what it includes (discrete data, documents, images, audit logs), the delivery time and any fee.
• Check 3, Subcontractor list: Hosting provider, regions, support locations and any AI or analytics services that see your data, with notice of changes.
• Check 4, CHPL listing: The exact product version and the certification criteria it holds, matched to your CMS reporting needs.
• Check 5, API terms: Which FHIR resources and scopes are available, rate limits, per-connection or per-call fees, and how third-party apps are approved.
• Check 6, Interfaces: HL7 v2 lab, ADT and imaging interfaces, X12 270/271, 837 and 835 connections, and NCPDP SCRIPT e-prescribing, with who builds and who maintains each one.
• Check 7, Service levels: Uptime commitment, maintenance windows, incident history and how credits are claimed.
• Check 8, Recovery: Backup frequency, how often restores are tested and whether the vendor fails over between regions.
• Check 9, Accessibility: An accessibility conformance report for the patient portal and app, measured against WCAG 2.1 Level AA.
• Check 10, Real-world speed: Scripted visit types timed on your own clinic network, browsers and tablets.

Questions for reference calls

• Upgrades: How much notice did you get before the last major upgrade, and did any interface break?
• Support: When an interface failed, who found it first, your team or the vendor?
• Exports: Have you requested a full export, and how long did it take to arrive?
• Outages: What happened during the last outage, and did the downtime copy work?

Why accessibility belongs on the list

The HHS Section 504 rule at 45 CFR 84.84 adopts WCAG 2.1 Level AA for the web content and mobile apps of recipients of HHS federal financial assistance, which includes most providers that take Medicare or Medicaid. A May 2026 interim final rule moved compliance to 11 May 2027 for recipients with 15 or more employees and 10 May 2028 for smaller ones. A portal the vendor runs for you is still your patient-facing content.

How do you test a vendor's API before signing?

Ask for sandbox credentials and run a short, scripted test of the API you will rely on. A vendor that cannot provide a sandbox before signing is telling you something about integration support after it.

• 1. Register an app: Time how long it takes to get client credentials and which scopes are offered.
• 2. Launch in context: Run a SMART App Launch from the EHR and confirm the app receives the patient and encounter.
• 3. Read core data: Pull Patient, Condition, MedicationRequest, AllergyIntolerance and Observation resources and check they conform to US Core.
• 4. Request a Bulk Data export: Start a group export, poll the status endpoint and inspect the NDJSON files for completeness.
• 5. Test writing: The certified 45 CFR 170.315(g)(10) API is a read API, so ask which vendor write APIs or HL7 v2 interfaces exist for orders, notes or results your apps must send back.
• 6. Check limits and errors: Hit the rate limit on purpose and confirm the API returns clear errors and retry guidance.

Planning for outages and an eventual exit

Plan for two events before go-live: a vendor outage and the day you leave. The HIPAA Security Rule at 45 CFR 164.308(a)(7) requires a contingency plan with data backup, disaster recovery and emergency mode operation, and that duty does not move to the vendor.

• Downtime view: Keep a read-only copy of today's schedules, medication lists, allergies and problem lists that staff can open when the EHR is unreachable.
• Paper fallback: Print-ready forms for orders and notes, and a defined process for entering them once the system returns.
• Communication: A named contact at the vendor, a status page to check, and an internal call tree.
• Regular exports: Scheduled Bulk Data or report exports stored under your own controls, so a dispute never leaves you without your data.
• Exit rehearsal: Request a sample full export in year one and confirm another system can load it, rather than discovering gaps during a switch.

How Agnotic can help

Buying the EHR is the start of the integration work, not the end. Agnotic Technologies helps practices, health systems and digital health teams test a shortlisted vendor's API in its sandbox, then builds what connects to the chosen cloud EHR: SMART on FHIR apps, Bulk Data pipelines, HL7 v2 and X12 interfaces, downtime copies and the migration and reconciliation from the old system.

Sources

• HHS: Guidance on HIPAA and Cloud Computing
• 45 CFR 164.504: Business associate contract requirements
• 45 CFR 164.410: Notification by a business associate
• 45 CFR 164.308: Administrative safeguards, including contingency plans
• 45 CFR Part 171: Information blocking
• ASTP/ONC: Certified Health IT Product List (CHPL)
• ASTP/ONC: Standardized API for patient and population services, 45 CFR 170.315(g)(10)
• Federal Register: Section 504 web and mobile accessibility compliance date extension (11 May 2026)