EHR Integration for AI Agents: Working with Epic, Cerner, and FHIR APIs

Understanding EHR Integration for AI Agents

Integrating AI agents into electronic health records (EHRs) is fundamentally different from building chatbots or general-purpose automation. Your AI agent needs to read patient data reliably, execute clinical workflows with audit trails, and operate within strict compliance boundaries. It's not about natural language understanding—it's about deterministic data access, real-time latency requirements, and governance that survives regulatory scrutiny.

The challenge isn't building an agent that can talk to an EHR. The challenge is building one that should—one that reduces clinician burden, improves outcomes, and doesn't create liability exposure. That's why EHR integration for AI agents requires understanding three critical layers: the API standards (FHIR), the vendor-specific implementations (Epic and Cerner), and the production architecture that makes it all work at scale.

At Brightlume, we've shipped production AI agents for health systems that read live EHR data, trigger clinical workflows, and maintain full audit compliance. This guide walks through what you need to know before your team starts building.

What Is FHIR and Why It Matters for AI Agent Integration

FHIR (Fast Healthcare Interoperability Resources) is the modern standard for healthcare data exchange. Instead of proprietary formats or HL7 v2 pipe-delimited messages, FHIR uses RESTful APIs with JSON payloads. For AI agents, this matters because it means you're working with structured, predictable data models rather than parsing unstructured text.

The FHIR Specification defines resources—standardised data containers for patients, observations, medications, appointments, and dozens of other clinical entities. Each resource has a consistent structure: identifiers, status fields, timestamps, and references to other resources. An AI agent reading a patient's medication list via FHIR gets a guaranteed schema, not a surprise format change.

Here's why this matters for production deployments:

• Predictable data models: Your agent's parsing logic doesn't break when a vendor updates their system. FHIR versioning is backward-compatible by design.
• Real-time integration: FHIR APIs are synchronous. Your agent queries data and gets results in milliseconds, not batch jobs that arrive hours later.
• Audit trails built in: FHIR resources include provenance metadata—who created the data, when, and why. Critical for compliance.
• Vendor consistency: Epic, Cerner, and other major EHRs all implement FHIR. You're not writing vendor-specific parsing logic.

But here's the production reality: FHIR is a standard, not a mandate. Vendors implement it differently. Epic's FHIR API supports certain resources fully; Cerner's implementation has different coverage. Your agent needs to handle these variations gracefully, with fallbacks to vendor-specific APIs when FHIR gaps exist.

Research from expert perspectives on FHIR implementation shows that while FHIR adoption is accelerating, vendors still have inconsistent resource support. This means your integration strategy needs to account for what's actually available in your target EHR, not just what the standard promises.

Epic FHIR Integration: The Dominant Standard

Epic is the market leader in US hospitals. If your health system runs Epic, your AI agent's integration path is largely defined by what Epic offers. The good news: Epic has invested heavily in FHIR. The bad news: Epic's FHIR implementation is opinionated, and you need to understand those opinions to avoid months of integration delays.

Epic on FHIR provides the official documentation, but here's what you need to know from a production engineering perspective:

Authentication and Access Control

Epic uses OAuth 2.0 for FHIR API access. Your AI agent needs a service account with specific scopes. Epic's scopes are granular—you can request read access to medications but not diagnoses, for example. This is good for security but requires careful planning. You need to audit what data your agent actually requires, request only those scopes, and document the justification. Regulators will ask.

For production deployments, use the backend service flow (also called client credentials). This is simpler than SMART on FHIR for server-to-server integration. Your agent authenticates with a client ID and secret, receives a JWT token, and includes it in subsequent API calls. Token lifetime is typically 10 minutes; your agent should cache tokens and refresh before expiry to avoid latency spikes during high-volume workflows.

Data Access Patterns

Epic's FHIR API is read-optimised. You can query patients, fetch observations, medications, and clinical notes. Epic also exposes a custom search parameter called _lastUpdated, which lets you build incremental sync patterns—query only records modified since your last fetch. This is essential for AI agents that need to stay current without hammering the API.

One critical gap: Epic's FHIR implementation doesn't fully support writing clinical data back to the EHR via FHIR. If your AI agent needs to create orders, update care plans, or document clinical notes, you'll likely need to use Epic's proprietary APIs (Interconnect or Fhir Workflow APIs) in parallel. This is a major architectural decision. You're essentially maintaining two API clients—one for read (FHIR), one for write (proprietary). This adds complexity but is the current production reality.

Latency and Rate Limiting

Epic's FHIR API has rate limits (typically 10 requests per second per OAuth token). Your agent needs to batch queries intelligently. If you're processing 100 patients, don't make 100 separate API calls. Use FHIR's _include and _revinclude parameters to fetch related resources in a single request. This reduces latency from seconds to milliseconds.

For production agents handling real-time clinical workflows (like a triage bot that routes patients to specialists), you need to understand Epic's infrastructure. Epic's on-premises deployments have different latency profiles than cloud-hosted instances. Test with realistic data volumes and patient loads before going live.

Cerner Integration: Oracle Health's FHIR-First Approach

Cerner (now Oracle Health) has taken a different path than Epic. While Epic layered FHIR onto an existing architecture, Cerner built FHIR-first APIs from the ground up. For AI agents, this can be simpler—fewer vendor-specific workarounds—but Cerner's ecosystem is smaller, and you'll encounter fewer reference implementations.

Oracle Health API Platform documentation outlines the Ignite API suite, which is Cerner's modern FHIR implementation. Key differences from Epic:

Event-Driven Architecture

Cerner exposes webhook-based event notifications. When a patient is admitted, a lab result arrives, or a medication is prescribed, Cerner can push an event to your agent rather than your agent polling for changes. This is powerful for real-time workflows but requires your agent to expose an HTTP endpoint that can receive and process events reliably.

For production, you need idempotency handling. If Cerner sends the same event twice (due to network retries), your agent should recognise it and not double-process. Implement event deduplication using unique event IDs and a short-lived cache (Redis or in-memory store).

Resource Coverage

Cerner's FHIR coverage is broader than Epic's in some areas (better support for care plan resources, for example) but narrower in others. Before designing your AI agent, map the specific clinical workflows you're automating against Cerner's FHIR resource support. The guide to FHIR implementation with Epic, Cerner, and other EHRs breaks down these gaps in detail.

Authentication

Like Epic, Cerner uses OAuth 2.0, but with different token endpoint configurations. Cerner's tokens are typically longer-lived (1 hour vs Epic's 10 minutes), which reduces refresh overhead. However, Cerner's implementation is less standardised across deployments. You may need to adjust authentication logic per client. This is a production risk—test authentication thoroughly before deployment.

FHIR API Fundamentals: Building Your Agent's Data Layer

Regardless of vendor, your AI agent needs to understand FHIR API patterns. Here's what production agents actually do:

Resource Queries

FHIR uses RESTful endpoints. To fetch a patient, your agent makes a GET request to /Patient/{id}. To search for observations, it queries /Observation?patient={id}&code={system}|{code}&date=ge2024-01-01. The search syntax is standardised, but vendors implement different search parameters. Epic supports _lastUpdated; Cerner might support _sort.

Your agent should build a query abstraction layer—a function that constructs FHIR search queries from high-level clinical requirements. Instead of hardcoding /Observation?code=http://loinc.org|2345-7&date=ge2024-01-01, your agent should call something like query_observations(patient_id, code='2345-7', date_range=('2024-01-01', None)). This makes it easier to adapt to vendor differences without rewriting agent logic.

Pagination and Bulk Operations

FHIR search results are paginated. A query for "all patients with diabetes" might return 10,000 results. FHIR returns them in pages (typically 50-100 per page) with a next link. Your agent needs to iterate through pages intelligently. If you're processing all diabetic patients for a batch workflow, fetch pages asynchronously. If you're serving a real-time clinical decision, fetch only the first page and optimise the query to reduce result set size.

For bulk operations (e.g., updating care plans for 1,000 patients), use FHIR's bulk export and batch APIs if available. Don't make 1,000 individual API calls. This is a common production mistake—agents that work fine at pilot scale (10 patients) suddenly become bottlenecks at production scale (10,000 patients).

Error Handling and Retries

EHR APIs are mission-critical infrastructure. They're also complex systems with occasional failures. Your agent needs robust error handling. FHIR uses standard HTTP status codes: 200 for success, 400 for bad requests, 401 for auth failures, 429 for rate limits, 500 for server errors.

For production agents, implement exponential backoff for retryable errors (429, 500-503). Don't retry immediately; wait 1 second, then 2, then 4, capping at 60 seconds. For non-retryable errors (400, 401), log the error and alert your operations team—these indicate bugs or configuration issues that need human intervention.

Authentication and Security: Non-Negotiable in Production

EHR integration touches patient data. Your AI agent's authentication and authorisation strategy determines whether you're compliant or liable.

OAuth 2.0 Backend Service Flow

For server-to-server integration (agent-to-EHR), use OAuth 2.0 client credentials. Your agent has a client ID and secret. It exchanges these for a JWT token, then uses the token to authenticate API requests. This is simpler than SMART on FHIR (which involves user interaction) and appropriate for background agents.

Secrets management is critical. Never hardcode credentials. Use your infrastructure's secret management system (AWS Secrets Manager, Kubernetes Secrets, HashiCorp Vault). Rotate secrets regularly. For production deployments, rotate every 90 days. Your agent should fetch secrets at startup and refresh them before expiry.

Scope Minimisation

Request only the FHIR scopes your agent needs. If your agent reads patient observations but never writes medications, don't request write access. This is both a security best practice and a regulatory requirement. During audits, you'll need to justify every scope you requested.

Audit Logging

Every API call your agent makes should be logged with the timestamp, endpoint, HTTP method, response code, and user/service account. HIPAA requires audit trails for all PHI (Protected Health Information) access. Your agent's logs are part of your compliance story. Use structured logging (JSON) and centralise logs to a secure store. Don't log request/response bodies (they contain PHI), but log enough detail to reconstruct what happened if something goes wrong.

For deeper security considerations, AI agent security: preventing prompt injection and data leaks covers how to prevent your agent from leaking patient data through prompt injection or misconfigured outputs.

Designing Your Agent's Data Access Layer

Your AI agent shouldn't directly call FHIR APIs. It should call a data access layer—a service that abstracts FHIR complexity and enforces security policies.

Here's the architecture:

Agent Layer

Your AI agent (running Claude Opus 4, GPT-4, or Gemini 2.0) calls tools or functions. Instead of tools that directly query FHIR, it calls high-level clinical functions: get_patient_medications, get_recent_labs, get_active_diagnoses. The agent doesn't know about FHIR; it knows about clinical concepts.

Tool Layer

Tools translate clinical requests into FHIR queries. get_patient_medications becomes a FHIR Medication + MedicationStatement query with appropriate filters. Tools handle pagination, error handling, and response formatting. If the FHIR API returns a 429 (rate limit), the tool retries. If it returns a 400 (bad query), the tool logs the error and returns a user-friendly message.

API Client Layer

The actual HTTP client that calls FHIR endpoints. This layer handles authentication, token refresh, request signing, and low-level error handling. It's vendor-agnostic—the same client can call Epic or Cerner APIs with different configuration.

Data Cache

EHR APIs have rate limits. Your agent shouldn't query the same patient's medication list 10 times in a single workflow. Implement a cache (Redis, in-memory, doesn't matter) with short TTLs (5-30 minutes depending on data freshness requirements). Cache misses go to the API; hits return instantly.

This architecture has several benefits:

• Agent simplicity: Your agent focuses on clinical logic, not API mechanics.
• Auditability: All API calls are logged at the client layer.
• Vendor flexibility: Swap Epic for Cerner by changing the API client configuration.
• Testability: Mock the tool layer in unit tests; mock the API client in integration tests.

Real-World Integration Patterns: From Pilot to Production

You've designed your agent. You've chosen Epic or Cerner. Now you need to actually build and deploy it. Here's what production health system integrations look like.

Development and Sandbox Access

Both Epic and Cerner provide sandbox environments. Your team starts here. Sandbox has test data, no rate limits, and no compliance requirements. You'll spend 2-4 weeks here building and testing basic queries.

The trap: sandbox doesn't behave like production. Epic's sandbox has 1,000 test patients; production has 100,000. Cerner's sandbox doesn't enforce rate limits; production does. Design your agent assuming production constraints from day one. If you build assuming unlimited API calls, you'll hit rate limits in production and have to rewrite.

UAT and Staging

Once sandbox testing passes, move to UAT (User Acceptance Testing) in a production-like environment. This is where clinicians see the agent for the first time. They'll ask for features you didn't anticipate, find edge cases in your logic, and discover that the "simple" workflow you automated has 47 exceptions.

UAT typically takes 4-8 weeks. Your agent needs to handle real patient data (de-identified if possible, but often real). This is where latency and reliability become real constraints. Your agent might work fine with 10 test patients but struggle with 10,000 real patients. You'll discover API performance issues, data quality problems, and gaps in your FHIR understanding.

Compliance and Governance Review

Before production, your agent goes through compliance review. Your health system's legal, security, and clinical teams will audit:

• Data access justification: Why does your agent need access to patient diagnoses?
• Audit trail completeness: Can we reconstruct every decision your agent made?
• Failure handling: What happens if your agent crashes mid-workflow?
• Bias and safety: Could your agent harm patients through incorrect recommendations?

This isn't theatre. Health systems have been fined millions for inadequate AI governance. Your agent's integration strategy must account for these reviews. Build audit logging from the start. Document every design decision. Have answers ready for "what if your agent makes a mistake?"

Phased Rollout

Production deployment isn't a big bang. You roll out to one unit, then one hospital, then the entire system. Start with low-risk workflows. If your agent routes patient messages, start with informational messages ("here are your test results") before clinical decisions ("you should see a specialist").

Monitor obsessively. Track agent accuracy, latency, error rates, and user feedback. Set clear success metrics: "agent responds in <2 seconds 99% of the time", "agent accuracy >95%", "clinicians adopt agent in >80% of eligible workflows". If metrics miss targets, pause rollout and investigate.

For guidance on moving AI pilots to production, our capabilities outline how production-ready AI differs from proofs of concept. The jump from "agent works in sandbox" to "agent handles 1,000 patients per day" is where most health system AI projects fail.

Handling Vendor-Specific Variations and Gaps

You've read the FHIR spec. You've read Epic's docs. You've built your agent. Then you deploy to a Cerner customer and nothing works.

This is normal. Here's how production teams handle it:

API Variation Mapping

Create a vendor-specific configuration file that maps clinical concepts to vendor APIs. For Epic, querying medications uses one FHIR endpoint; for Cerner, it might use a different resource or custom search parameter. Your agent shouldn't care. It calls get_medications(patient_id), and the data layer translates to the right vendor API.

Example:

epic:
  medications:
    resource: MedicationStatement
    search_params:
      patient: patient
      status: status
    filters:
      active_only: status=active

cerner:
  medications:
    resource: MedicationRequest
    search_params:
      patient: subject
      status: status
    filters:
      active_only: status=active|on-hold

This abstraction layer is tedious to build but essential for multi-vendor deployments.

Fallback Strategies

Sometimes FHIR APIs are incomplete. You need clinical data that FHIR doesn't expose. Build fallback logic: try FHIR first, fall back to vendor-specific APIs if needed. Log every fallback. Over time, you'll see patterns—"Cerner doesn't expose care plan resources via FHIR, so we always fall back to Ignite APIs"—and you can optimise.

Testing Against Real Systems

Sandbox testing is insufficient. Before production, test against the actual vendor system your customer runs. This means getting access to their test environment and running realistic workflows. It's time-consuming but prevents production surprises.

For multi-vendor deployments, automated integration tests are critical. Write tests that run against both Epic and Cerner sandboxes. If a test fails, you catch vendor differences before production.

Compliance, Governance, and Audit Trails

AI agents in healthcare aren't just software—they're regulated devices. Your integration strategy must account for this.

HIPAA Compliance

Your agent touches PHI (Protected Health Information). HIPAA requires:

• Encryption in transit: All API calls must use HTTPS. No exceptions.
• Encryption at rest: Patient data stored by your agent (caches, logs) must be encrypted.
• Access controls: Only authorised users/services can access patient data.
• Audit logs: Every PHI access must be logged and auditable.
• Breach notification: If your agent leaks data, you must notify affected patients within 60 days.

Your EHR integration architecture must enforce these from day one. Don't treat them as afterthoughts.

State and Federal Regulations

Beyond HIPAA, individual states have healthcare AI regulations. California, for example, has specific requirements for algorithmic accountability. Some states require explicit patient consent before AI systems make clinical recommendations. Your agent's integration strategy must account for these.

Documentation and Traceability

When something goes wrong—your agent recommends the wrong medication, misses a critical lab result, causes a patient to be routed incorrectly—regulators will ask: "How did this happen?" You need to answer with logs, not guesses.

Every decision your agent makes should be traceable:

• What data did it access?
• What logic did it apply?
• What was the output?
• Who reviewed it before it affected patient care?

This requires comprehensive logging at every layer—agent decisions, API calls, data transformations. It also requires human oversight. Your agent shouldn't make clinical decisions unilaterally. It should recommend actions that clinicians review and approve.

For deeper governance guidance, AI model governance: version control, auditing, and rollback strategies covers how to maintain audit trails and rollback capabilities in production AI systems.

Clinical Workflow Automation: Where EHR Integration Creates Value

Integration is a means, not an end. The real value comes from automating workflows that reduce clinician burden and improve patient outcomes.

Here are production-tested patterns:

Triage and Routing

Your agent reads a patient's presenting symptoms and recent labs, then routes them to the appropriate specialist. It queries the EHR for patient history, applies clinical logic, and updates the patient's care plan. This reduces manual triage time from 15 minutes to 30 seconds. Clinicians review and approve the routing before it's final.

Documentation Assistance

Your agent reads clinical notes and EHR data, then drafts documentation for clinicians to review. It pulls relevant labs, medications, and prior notes, then generates a summary that clinicians can edit and sign. This doesn't replace clinician judgment; it accelerates documentation.

Medication Safety Checks

Your agent queries a patient's medications and allergies, then checks for interactions and contraindications. When a clinician prescribes a new medication, your agent alerts them if there's a conflict. This is real-time decision support, powered by EHR data.

Follow-Up Coordination

Your agent monitors patients after discharge. It queries the EHR for scheduled appointments, recent labs, and medication compliance. It sends reminders to patients and alerts clinicians if someone misses a critical follow-up.

For more patterns, 10 workflow automations you can ship this week with AI agents outlines automations that are shipping in production now.

Evaluating and Monitoring Agent Performance

Once your agent is in production, you need to know if it's working. This isn't just uptime monitoring. It's clinical performance monitoring.

Accuracy Metrics

For agents making clinical recommendations, measure accuracy against ground truth. If your agent recommends specialists, measure the percentage of recommendations that clinicians approve. If it's >90%, the agent is aligned with clinical judgment. If it's <70%, something's wrong—the agent logic is flawed, or it's not accessing the right data.

Latency Monitoring

Your agent's response time matters. If it takes 30 seconds to triage a patient, clinicians won't use it. Monitor API latency, agent processing time, and end-to-end latency. Set targets: agent should respond in <2 seconds 99% of the time. If you're missing targets, investigate: is it the EHR API? Your agent's logic? Network latency?

Error Tracking

Every error your agent encounters should be logged and tracked. API failures, invalid data, logic errors—all of it. Categorise errors: transient (network blip, retry and succeed) vs persistent (bad data, needs investigation). For persistent errors, alert your team. Don't let errors silently accumulate.

User Adoption

The best agent is useless if clinicians don't use it. Track adoption: what percentage of eligible patients have the agent's recommendation? Do clinicians approve recommendations or ignore them? If adoption is low, the agent isn't solving a real problem. Go back to clinicians and ask why.

Comparing EHR Integration Approaches: SMART on FHIR vs Backend APIs

There are two fundamental approaches to EHR integration: SMART on FHIR and backend service APIs. Understanding the trade-offs is critical.

SMART on FHIR

SMART (Substitutable Medical Applications and Reusable Technologies) on FHIR is designed for user-facing applications. A clinician launches your app from within the EHR, and the EHR passes the current patient context to your app. Your app can then query that patient's data and make decisions.

For AI agents, SMART on FHIR is appropriate when your agent is user-initiated. A clinician clicks "get AI recommendations for this patient", and your agent springs to life with the patient already in context.

Backend Service APIs

Backend service APIs (client credentials flow) are for server-to-server integration. Your agent runs independently, queries whatever patient data it needs, and makes decisions without user interaction.

For background workflows (batch processing, automated monitoring, scheduled tasks), backend service APIs are simpler and more efficient. Your agent doesn't need user context; it operates on a schedule or triggered by events.

For production health systems, the comparison of SMART on FHIR vs backend integration breaks down the architectural trade-offs in detail. Most production agents use backend service APIs, with SMART on FHIR for user-facing features.

Implementation Timeline and Resource Planning

How long does it actually take to integrate an AI agent with an EHR?

Honest answer: it depends. But here's a realistic breakdown:

Weeks 1-2: Planning and Access

• Determine which FHIR resources your agent needs
• Request sandbox access from the EHR vendor
• Plan authentication and security architecture
• Estimate: 2 weeks

Weeks 3-6: API Integration

• Build FHIR API client and data access layer
• Test basic queries against sandbox
• Handle vendor-specific variations
• Estimate: 4 weeks

Weeks 7-10: Agent Development

• Build agent logic and tools
• Integrate with your LLM (Claude Opus, GPT-4, etc.)
• Unit and integration testing
• Estimate: 4 weeks

Weeks 11-14: UAT and Clinical Testing

• Deploy to health system's UAT environment
• Clinicians test with real workflows
• Iterate based on feedback
• Estimate: 4 weeks

Weeks 15-18: Compliance and Governance

• Security review
• Legal and compliance sign-off
• Documentation and audit trail verification
• Estimate: 4 weeks

Weeks 19-20: Production Rollout

• Phased deployment to production
• Monitoring and support
• Estimate: 2 weeks

Total: 20 weeks (5 months)

This assumes you're integrating with one EHR vendor. Multiple vendors multiply the effort. Brightlume ships production-ready AI solutions in 90 days, which aligns with this timeline for single-vendor deployments with clear clinical workflows.

The biggest variable is clinical validation. If your health system has a thorough UAT process, add 4-8 weeks. If they have extensive compliance requirements, add another 4-8 weeks. Plan accordingly.

Building Your Team and Choosing Partners

EHR integration requires specific skills. You need:

• FHIR and healthcare IT expertise: Someone who understands HL7, FHIR, and EHR architecture. This person is worth their weight in gold.
• Backend engineers: Building robust APIs and handling production reliability.
• AI/ML engineers: Designing agent logic and integrating with LLMs.
• Security engineers: Ensuring HIPAA compliance and data protection.
• Clinical advisors: Ensuring the agent actually solves clinical problems.

If you're building in-house, recruiting healthcare IT engineers is hard. The talent pool is small, and salaries are high. Many organisations choose to partner with specialists. When evaluating partners, ask:

• Have they shipped production AI agents in healthcare?
• Do they have FHIR expertise and EHR vendor relationships?
• Can they handle compliance and governance?
• What's their timeline for production deployment?
• How do they handle post-launch support?

Brightlume's capabilities include custom AI agents for healthcare workflows with full compliance and production support. We've shipped agents that integrate with Epic, Cerner, and other EHRs, handling everything from API integration to clinical validation to compliance review.

Conclusion: From Integration to Impact

EHR integration for AI agents is technically feasible today. FHIR is mature. Epic and Cerner have production APIs. LLMs can handle clinical reasoning. The barrier isn't technology—it's execution.

Production health system integrations succeed when you:

1. Understand your vendor's FHIR implementation before you start building. Don't assume the standard; test against the actual system you're integrating with.

2. Build a robust data access layer that abstracts FHIR complexity and enforces security policies. Your agent shouldn't directly call APIs.

3. Plan for compliance from day one. Audit logging, encryption, access controls—these aren't add-ons. They're part of the architecture.

4. Test extensively in production-like environments. Sandbox testing catches syntax errors; production testing catches design flaws.

5. Iterate with clinicians. The best agent design comes from understanding real workflows, not from reading documentation.

6. Monitor relentlessly. Track accuracy, latency, errors, and adoption. If something's wrong, find it fast.

For health system leaders exploring agentic workflows, AI automation for healthcare: compliance, workflows, and patient outcomes covers the broader strategic context—when to use agents, how to prioritise workflows, and how to measure success.

The health systems shipping production AI agents today aren't waiting for perfect technology. They're shipping with good-enough technology, learning from production, and iterating. That's the path to real impact. Your EHR integration strategy should reflect that pragmatism—build for production constraints, test relentlessly, and iterate based on clinical feedback.

If you're moving a healthcare AI pilot to production, contact Brightlume. We ship production-ready AI solutions in 90 days, with an 85%+ pilot-to-production rate. We've built agents that read Epic and Cerner data, handle clinical workflows, and pass compliance review. Let's talk about what's possible for your health system.