Aubreigh Lee Daculug
Curogram connects to Oracle Health through OAuth-authenticated FHIR APIs, reads clinical data in real time, and applies segmentation logic inside an encrypted, SOC 2 Type II audited environment.
Your IT team avoids storing credentials. Your clinical operations team avoids spreadsheets.
The result: campaigns launch in under 24 hours instead of 3–5 days, audit trails capture every patient and every broadcast, and compliance reviews pass without remediation findings.
Imagine this. Your population health team needs to send a recall message to 12,000 diabetic patients by Friday.
The data lives inside Oracle Health. But Oracle's FHIR APIs only let you read it, not broadcast from it. So someone on your team exports a patient list, drops it into a spreadsheet, scrubs it for opt-outs, emails it to a vendor, and waits for approval.
That process takes 3–5 days. Sometimes longer.
By the time the message goes out, a patient has already missed their screening window. Another patient on the list has revoked SMS consent.
A third was duplicated across two clinic locations. Your IT director reviews the audit log and sees a problem: patient data left the EHR in a CSV file.
That's a compliance flag waiting to happen.
This is the quiet inefficiency hiding inside most enterprise EHR environments. Oracle Health FHIR patient segmentation for SMS campaigns sounds straightforward. It isn't.
Not when you're juggling unencrypted exports, manual list-building, missing consent records, and audit gaps that show up only when the auditor arrives.
The cost adds up fast. IT teams burn 8–10 hours per campaign on setup. Clinical operations staff maintain patient cohorts in Excel. And roughly 30–40% of campaigns lack proper consent documentation when audited.
There's a better way to handle this. One that keeps the data inside a secure pipeline, automates consent filtering, and gives your IT team a clean audit trail for every patient included in every broadcast.
This guide walks you through how that works.
We'll cover FHIR architecture, segmentation use cases, and the compliance details your IT and clinical operations leaders actually care about.
Why Oracle Health FHIR APIs Need a Broadcast Layer
Oracle Health's FHIR APIs give you read-only access to clinical data. That's a security strength, not a flaw.
But it also means broadcasting messages from segmented patient lists requires a separate platform that can pull data securely, apply logic, and execute outreach without breaking compliance.
Curogram's segmentation engine connects directly to Oracle Health, applies clinical criteria in real time, and runs broadcasts inside an encrypted environment.
Your IT team gains visibility. Your clinical operations team gains speed.
Here's how the architecture works in practice.
Secure OAuth Authentication With Oracle Health
Curogram connects to Oracle Health FHIR APIs using OAuth 2.0 with refresh tokens. Your IT team grants Curogram permission to read patient data without ever sharing credentials or API keys.
The OAuth token is scoped tightly:
- Read-only access to FHIR operations (no write or delete capability)
- Automatic expiration with managed refresh cycles
- Revocable at any time from your IT admin panel
Setup happens through Curogram's Org Integrations panel. One-click authentication, OAuth scope verification, and token expiration tracking are built in. There's no custom coding and no API documentation to translate.
If a connection fails or credentials expire, Curogram alerts your team immediately.
This architecture meets HIPAA standards for secure communication and aligns with modern healthcare compliance and care delivery models, removing one of the biggest compliance risks in patient outreach: unencrypted API keys living on external platforms.
Mapping FHIR Resources to Real Clinical Criteria
Curogram's segmentation engine reads four core FHIR resources from Oracle Health:
| FHIR Resource | What It Captures |
|---|---|
| Patient | Demographics, contact info, language preference |
| Condition | Active diagnoses, ICD-10 codes |
| Medication | Active prescriptions, drug classes |
| Procedure | Historical and scheduled procedures |
Your clinical operations team defines segmentation criteria in plain language inside Curogram. The platform translates those rules into FHIR queries and runs them against Oracle Health in real time.
Say you want to target patients with diabetes who are due for preventive screening.
Your team writes the rule as "ICD-10 codes E11* OR E10* + no preventive screening code in past 12 months."
Curogram converts that into a FHIR query, executes it, and returns a matching patient list with contact information.
Every query is logged, timestamped, and stored for audit review. If a compliance officer asks which patients were included in a flu shot campaign and why, your team pulls the segment definition, the FHIR logic, and the matching patient list in one export.
Encryption That Meets HIPAA in Transit and at Rest
All data flowing between Oracle Health and Curogram is encrypted using TLS 1.2 or higher. Patient data is never logged or cached in plaintext.
Once a segment is created, patient names and phone numbers stay encrypted at rest. Access is controlled by role-based permissions defined inside your organization.
For IT teams, this means HIPAA's encryption requirements are handled by Curogram's infrastructure rather than managed manually by your staff.
Curogram's platform is SOC 2 Type II audited, so third-party reviewers verify these controls on an ongoing basis. That's one less audit finding to chase down later.
Real Segmentation Use Cases for Population Health Teams
The architecture matters. But what does it actually do for your team on a Tuesday morning when 8,000 recall messages need to go out?
Let's walk through three of the most common segmentation patterns we see across enterprise healthcare networks, plus the time savings they unlock.
Recall Campaigns That Run on Due-Date Logic
Patient recalls are time-sensitive. Colonoscopy. Mammogram. Annual diabetic retinopathy screening. Pediatric immunizations.
Curogram tracks procedure history from Oracle FHIR and identifies patients overdue based on clinical protocol intervals. Your team defines the protocol once, like "colonoscopy every 10 years" or "annual flu shot," and Curogram applies it continuously.
When you run a monthly recall broadcast, the platform handles four things in sequence:
- Queries all overdue patients matching your protocol
- Filters for active phone numbers
- Applies SMS consent filters automatically
- Produces a broadcast-ready segment in under 60 seconds
No manual list compilation. No copy-paste errors. No accidental messages to patients who opted out last week.
The audit trail captures the segment creation time, the FHIR query that ran, the patient count matched, and the broadcast timestamp.
If a patient disputes a recall message, your team can confirm they were correctly identified and had opted in to SMS.
What This Means for Your Team
When segmentation moves from spreadsheets to a FHIR-native platform.
The operational math shifts in measurable ways:
| Workflow Step | Manual Process | With Curogram |
|---|---|---|
| Segment creation | 8–10 hours per campaign | 2–3 hours per campaign |
| Time to launch | 3–5 days | Under 24 hours |
| Consent tracking | Often incomplete | 100% logged |
| Audit findings | 30–40% of campaigns flagged | Pass without remediation |
A 70% reduction in setup time means a five-person operations team gets back roughly 30–35 hours every campaign cycle.
Across 12 campaigns a year, that's more than 400 hours redirected to higher-value work like protocol design, outreach analysis, and patient engagement strategy.
For your team, that's the difference between reacting to recall lists and actually running a population health program.
Chronic Disease Cohorts That Update Themselves
Population health programs usually focus on specific chronic disease populations: diabetes, COPD, hypertension, congestive heart failure, obesity.
Curogram segments these cohorts by reading ICD-10 codes from Oracle FHIR, filtering for active diagnoses (not historical), and layering in optional secondary criteria like age, location, or payer type.
For example: patients with ICD-10 code E11 (Type 2 Diabetes) plus age 60 and older might receive a campaign on diabetes-related complications. Patients with J44* (COPD) plus a medication list that includes long-acting bronchodilators might receive a campaign about pulmonary function testing.
You can nest criteria as deeply as your clinical strategy requires, enabling more precise patient population segmentation
What makes this useful in practice is that segments refresh on a schedule you control: daily, weekly, or monthly. Patients who transition out of the cohort, like when a diagnosis resolves or a medication is discontinued, are removed automatically.
Newly diagnosed patients are added in the same way. Your clinical operations team simply reviews segment size monthly to confirm accuracy.
Demographic and Location-Based Targeting
Large enterprises often need to run location-specific or demographic-specific campaigns. All patients at the Downtown Clinic.
All Medicare patients in rural ZIP codes. All Spanish-speaking diabetic patients at a specific facility.
Curogram pulls demographics and location data from Oracle FHIR, including patient address, assigned clinic, insurance type, and language preference. You can stack demographic and clinical criteria in a single segment.
A query like "All Medicaid patients with diabetes at Downtown Clinic who speak Spanish" runs as one segment. Curogram applies each filter sequentially and logs the count at every step, so you can see exactly where dropoff occurs.
This kind of segmentation is especially powerful for equity-focused work. You can identify underserved populations, test multilingual messaging, and measure engagement disparities across race, ethnicity, language, and socioeconomic status.
Ready to See It in Action? Schedule a Demo
Most enterprise teams discover the same thing when they audit their current process. The patient data is there. The clinical criteria are clear. The campaigns are well-designed.
What's missing is a secure, FHIR-native bridge between Oracle Health and the people who need to receive the message.
That bridge changes the math. Setup time drops from 8–10 hours to 2–3 hours. Campaign launch moves from 3–5 days to under 24 hours. Consent tracking goes from a 30–40% audit gap to 100% logged. And your IT team finally gets a real audit trail instead of a stack of CSV files.
The point isn't to add another platform to your stack. The point is to eliminate the workarounds that create compliance risk in the first place.
When segmentation lives inside an encrypted, OAuth-authenticated, SOC 2 Type II audited environment, your IT director stops worrying about export logs and your clinical operations team stops fighting with spreadsheets.
If you're managing population health across an enterprise EHR like Oracle Health, the right segmentation tool isn't a nice-to-have.
It's the difference between a program that scales and a program that stalls.
Schedule a demo with the Curogram team. We'll walk you through a live FHIR query, show how segments are created, and let your IT team see exactly how the audit trail works in real time.
Frequently Asked Questions