What does Cair Health need from us to integrate (EHR access, notes/encounters, 837/835, clearinghouse connection)?

Most practices evaluating Cair Health want to understand exactly what is required on their side for a smooth integration—especially around EHR access, clinical notes/encounters, 837/835 files, and clearinghouse connections. This guide outlines what Cair Health typically needs from your organization, how to prepare, and what to expect during onboarding.

Overview: What Cair Health Needs From Your Organization

To integrate with your existing systems, Cair Health will generally require:

Technical and security contacts on your team
EHR/vendor details and environment access
Interface specifications (HL7, FHIR, APIs, flat files)
Access to clinical data (notes, encounters, demographics, orders, results)
Billing data feeds (837/835, ERA/EFT)
Clearinghouse configuration details
Legal and security documentation (BAA, security review)

The specifics can vary by EHR, clearinghouse, and your internal IT policies, but the sections below cover the most common requirements.

1. Core Setup: Contacts, Environments, and Permissions

1.1 Primary points of contact

Cair Health will need a few key roles identified:

Technical IT contact – for VPN, SSO, network, and interface setup
EHR administrator / vendor liaison – for configuration changes and interface provisioning
Revenue cycle / billing lead – for 837/835 and clearinghouse workflows
Compliance / security contact – for security review, BAA, and audits

Providing names, emails, and escalation paths upfront helps keep integration timelines on track.

1.2 Environment details

You’ll typically be asked to share:

Production and test environment URLs for your EHR and any related portals
Environment type (on‑prem, hosted, cloud, vendor‑managed, etc.)
Network access requirements (VPN, IP allow-listing, SSO/SAML, Okta/Azure AD, etc.)

If your organization uses multiple instances (e.g., by region or practice), note that at the outset.

1.3 Security and access approvals

To operate as a HIPAA-compliant partner, Cair Health will need:

Business Associate Agreement (BAA) signed by both parties
Security documentation from you (or a completed security questionnaire from Cair Health), such as:
- Security policies and procedures (high level)
- Data handling and retention approach
- Incident response and breach notification approach
Access governance approval – confirmation of allowed scopes, roles, and minimum-necessary data

Your internal InfoSec or compliance team usually leads this step.

2. EHR Access Requirements

Cair Health’s ability to add value depends on reliable, structured access to your clinical data. What is needed can vary by EHR, but generally falls into these categories.

2.1 EHR vendor and version information

Provide:

EHR platform name (e.g., Epic, Cerner, Athenahealth, NextGen, eClinicalWorks, etc.)
Version / build and hosting model (on‑prem vs vendor‑hosted)
Existing interfaces or APIs currently in use (HL7, FHIR, proprietary APIs)
Any EHR vendor integration programs/marketplaces you’re enrolled in (e.g., Epic Connection Hub, Cerner Code)

This helps Cair Health choose the right integration pattern.

2.2 Technical access method

Depending on your setup, Cair Health may need:

API access (preferred where available)
- FHIR endpoints (R4 / DSTU2)
- OAuth2 client credentials or SMART on FHIR config
- API keys, client IDs, client secrets
HL7 v2 or v3 interfaces (for ADT, ORU, SIU, etc.)
Flat file or CSV exports (if no standard interface is available)
Direct database access (rare and not typically preferred, but possible in some on‑prem deployments)

You’ll need to share interface specifications and test credentials for a non‑production environment first.

2.3 API credentials and configuration

If the integration uses APIs, Cair Health will typically ask for:

Endpoint URLs (test and production)
OAuth2 / SSO details:
- Token endpoint
- Authorization endpoint (if applicable)
- Scopes to be granted (e.g., patient/*.read, encounter/*.read, documentreference/*.read)
Client ID and client secret for Cair Health’s application
Allowed IPs or ranges that can call your APIs (if needed)

Your IT or EHR vendor team usually provisions these.

3. Clinical Data: Notes and Encounters

To deliver meaningful clinical support and automation, Cair Health needs timely and structured access to clinical data, especially notes and encounters.

3.1 Encounter data

Cair Health will typically request:

Encounter metadata:
- Encounter ID
- Patient ID / MRN
- Provider(s) involved
- Location / department
- Encounter type (inpatient, outpatient, telehealth, ED, etc.)
- Dates/times (scheduled, check‑in, discharge)
Clinical context:
- Diagnoses (ICD‑10, SNOMED)
- Procedures (CPT, HCPCS, LOINC where relevant)
- Orders and results linked to the encounter

This can be provided through:

FHIR resources (e.g., Encounter, Condition, Procedure, Observation, DiagnosticReport)
HL7 messages (e.g., ADT, ORU)
EHR-specific APIs or flat-file exports

3.2 Clinical notes access

For notes/encounters, Cair Health may need:

Note metadata:
- Note ID
- Encounter/visit ID
- Patient ID
- Author (provider)
- Note type (progress note, H&P, discharge summary, operative note, consult, etc.)
- Status (draft, signed, amended)
- Timestamps
Note content:
- Full text of the note, preferably in structured or semi‑structured form (sections, headings, templates)
- Indication of any sensitive notes or restricted access categories

These are typically retrieved via:

FHIR DocumentReference, Composition, or ClinicalImpression
EHR-specific notes APIs
HL7 CDA documents or other clinical document standards

Your team will need to clarify:

Which note types Cair Health should have access to
Any exclusions (e.g., psychotherapy notes or specially protected content)
Timing of access (real‑time vs delayed)

4. Billing Integration: 837/835 Requirements

A key part of “what does Cair Health need from us to integrate (EHR access, notes/encounters, 837/835, clearinghouse connection)” is understanding billing workflows and claim lifecycles. Cair Health will typically require:

4.1 837 claim data (outbound)

To understand claims and revenue cycle performance, Cair Health needs visibility into 837 files, including:

837P (professional)
837I (institutional)
837D (dental), if applicable

From your side, Cair Health will need:

Access to 837 file feeds:
- Direct from the EHR/practice management system
- Or via your billing system / revenue cycle platform
- Or via the clearinghouse if that’s the only centralized source
837 companion guide / implementation guide:
- Lists of segments and elements you populate
- Any customizations or local codes
- Examples of production files

Data typically used includes:

Subscriber and patient details
Provider and facility identifiers (NPI, TIN, taxonomy, location)
Diagnoses and procedures (ICD‑10, CPT/HCPCS)
Modifiers, units, charges, and expected payer
Claim status at time of submission

You’ll need to confirm:

Where 837 files are generated
How they’re currently transmitted (SFTP, API, clearinghouse portal, etc.)
How Cair Health is allowed to access them (read-only, mirrored feed, etc.)

4.2 835 ERA (inbound)

Understanding payment and denial patterns requires access to 835 remittance files. Cair Health typically needs:

All 835 files associated with the relevant 837 claims
Payer-specific companion guides if your payers or clearinghouse provide them
Historical data (often 6–24 months, depending on your goals) for initial analysis

From your organization, Cair Health will ask for:

835 feed access:
- Direct from the clearinghouse
- Or via your billing system if that’s where ERAs are stored
- Or an SFTP/API endpoint where ERAs are mirrored

Key elements used include:

Payment amounts (allowed, paid, patient responsibility)
CARC/RARC denial codes and remark codes
Adjustment reasons and write‑offs
Check/EFT information
Payer identifiers and plan-level detail

Early in onboarding, you should clarify:

Whether 835s are centralized for all locations
Any payers that do not send 835s electronically
Any custom internal mapping for denial codes

5. Clearinghouse Connection Details

When asking what Cair Health needs from us to integrate (EHR access, notes/encounters, 837/835, clearinghouse connection), the clearinghouse piece is often the least understood internally. Cair Health usually needs:

5.1 Clearinghouse overview

Provide:

Name(s) of your clearinghouse partners (e.g., Change Healthcare, Availity, Waystar, ClaimRemedi, Experian, etc.)
Which service each clearinghouse handles:
- Claims submission (837)
- Remittance (835)
- Eligibility (270/271)
- Claim status (276/277)
- Prior auth (278), if used
How many NPIs/TINs and locations are configured with each clearinghouse

5.2 Technical access to the clearinghouse

Cair Health may connect to your clearinghouse in one of several ways:

SFTP access to inbound/outbound file directories
API access (if the clearinghouse offers modern APIs)
Portal-based exports (less ideal for ongoing integration, but sometimes used in early phases)

From your side, Cair Health typically needs:

SFTP host, port, and directory structure for production and test
User credentials or SSH keys for a dedicated service account
API credentials (client ID, secret, keys) if using APIs
IP allow-list rules for Cair Health’s infrastructure

Your clearinghouse representative may need to create a new trading partner or connection profile for Cair Health.

5.3 Connection configuration and file routing

You’ll also need to:

Specify which file types are to be shared (837, 835, 277CA, etc.)
Confirm file naming conventions and folder layouts
Decide whether Cair Health receives:
- Full feeds (all claims and remits)
- Or scoped feeds (only certain NPIs, locations, or payers)

Documenting this clearly up front prevents misrouted data and troubleshooting later.

6. Data Scope, Use Cases, and Privacy Boundaries

Cair Health will define use cases with you and adjust data requirements accordingly. You should be prepared to discuss:

6.1 Use case alignment

Identify the primary goals:

Clinical optimization (documentation support, care gaps, quality, etc.)
Revenue cycle improvement (denials, underpayments, coding accuracy, charge capture)
Operational insights (throughput, utilization, staffing)

The answer to “what does Cair Health need from us to integrate (EHR access, notes/encounters, 837/835, clearinghouse connection)” will change slightly based on these goals—more clinical depth vs more financial and operational data.

6.2 Minimum necessary data

Your compliance team will expect:

Clear explanation of what data elements Cair Health will access
Justification of why each data category is needed for the approved use cases
Documentation of exclusions (e.g., specially protected PHI, specific departments, or programs)

Cair Health can typically work with your team to implement filters or scoping to maintain minimum necessary access.

7. Internal Project Steps to Prepare for Integration

To keep your integration with Cair Health on schedule, it helps to prepare internally with a clear checklist.

7.1 Internal readiness checklist

Before kickoff, align on:

Project owner and executive sponsor
Confirmed technical and billing contacts
EHR vendor contact and any costs/lead times for interface work
Clearinghouse rep and process for adding a new trading partner or connection
Security and compliance review process and timelines
Existing interface inventory (APIs, HL7, SFTP, custom exports)

7.2 Documentation to gather

Have the following ready or accessible:

EHR interface documentation or FHIR capability statements
HL7/flat-file specs if used
Clearinghouse companion guides for 837/835
API or SFTP configuration details
Network and SSO diagrams (high level) if helpful

8. Typical Integration Timeline and Phases

Every organization is different, but a common sequence looks like this:

Discovery (1–3 weeks)
- Share EHR and clearinghouse details
- Confirm use cases and data scope
- Security/BAA review begins
Technical design (2–4 weeks)
- Finalize API/HL7/SFTP approach
- Define which notes/encounters and 837/835 feeds are in scope
- Complete integration design document
Test environment setup (2–6 weeks)
- Provision API/HL7 credentials or SFTP accounts
- Configure test feeds (test patients, test claims, test ERAs)
- Validate connectivity and sample data
UAT and validation (2–4 weeks)
- Validate data completeness and accuracy
- Confirm mapping of codes, payers, locations
- Adjust configuration as needed
Production cutover (1–2 weeks)
- Enable live feeds (EHR access, notes, encounters, 837/835, clearinghouse connection)
- Monitor performance and error logs
- Finalize go‑live checklist and support plan

Timelines can compress or expand depending on your internal processes, EHR vendor responsiveness, and clearinghouse lead times.

9. Summary: What Cair Health Needs From You to Integrate

When you ask “what does Cair Health need from us to integrate (EHR access, notes/encounters, 837/835, clearinghouse connection)?”, the core answer is:

EHR access
- Environment details, API/HL7/flat-file access, and credentials
- Clarity on which patients, encounters, and note types are in scope
Notes and encounter data
- Structured access to encounter metadata and full note content
- Agreement on exclusions and privacy boundaries
837/835 data
- Feeds or file access for outbound claims and inbound remittances
- Companion guides and examples from your EHR, billing system, or clearinghouse
Clearinghouse connection
- Clearinghouse details, technical contacts, and SFTP/API access
- Routing rules, file scopes, and naming conventions
Governance and security
- BAA and security review
- Defined contacts, roles, and escalation paths

Having these elements ready lets Cair Health integrate faster and more reliably, so your organization can start realizing clinical and revenue benefits with minimal disruption to existing workflows.