Home/Technology
Credential OS · AI Suite · HIPAA-eligible AWS · FHIR-native

The platform underneath the service.

Most RCM vendors run their service on someone else's software. We built ours. Credential OS is our credentialing operating system. Eight specialized AI tools work the revenue cycle from eligibility to AR. Every PHI byte at rest is encrypted with AES-256-GCM, every AI call passes through a single audited LLM Gateway, and every code, claim, and credential decision carries the source evidence that produced it.

Get a free platform audit → See the 14 pillars
FHIR-native EHR integration 1,200+ payer connections 99.9% uptime SLA
The architecture

Four layers. One audit boundary.

The platform is layered intentionally. Specialist AI models live in the top layer. Every model call passes through the LLM Gateway in the third layer, which carries the audit log, cost meter, prompt registry, model router, and PHI scrubber. Below that sit the platform applications, with Credential OS as the credentialing OS that also powers Verification Network primitives across the suite. The bottom layer is the HIPAA-eligible foundation: encryption at rest, row-level RBAC, PHI access log, and signed BAAs all the way down the chain.

When the CFO asks what AI spent this month, the answer comes from one log. When the compliance officer asks for the model version behind a specific code, the answer comes from one query. When the security team asks what data left the building, the answer is none.

Layer 04 · AI models (8 specialized)
HCC Coding
Denial Pred
Eligibility
Coding AI
Discovery
Reconcile
AR Workflow
Credential OS AI
▼
Layer 03 · LLM Gateway (single choke point)
Audit log · cost meter · prompt registry · model router · rate limit · PHI scrubber
▼
Layer 02 · Platform apps
Credential OS · Credentialing OS
Reporting Cloud
AR Workflow
▼
Layer 01 · HIPAA-eligible AWS foundation
AES-256-GCM
Row-level RBAC
PHI access log
Signed BAAs
The 14 pillars

Every technology pillar, with one source of truth.

The platform decomposes into fourteen pillars. Credential OS is the credentialing OS we built in-house, featured below. The other thirteen pillars are the operating capabilities that move dollars across eligibility, denial prevention, coding, reconciliation, and AR. Each pillar links to a dedicated deep-dive page with the architecture, the metrics, and the integration map.

P-01 · v6 · Flagship

Credential OS Credentialing OS

Twelve sub-capabilities: NPI auto-enrichment, AI doc extraction, Pre-Flight Validator, Revenue-at-Risk, LLM Gateway, MCP server, RS256 Passport, Verification Network, WhatsApp/SMS, NPDB, CAQH sync.

22-day BCBA TAT →
P-02

Coding engine

CPT, HCPCS, modifier suggestions with documentation evidence. ABA-tuned for 97151 family. Three-way match against auth, supervision, and notes.

M-05 · AI →
P-03

Eligibility 270/271

Continuous coverage verification. Mid-cycle plan migration detection. Pre-visit benefit detail per appointment, by service code. Sub-300 ms round-trip.

M-04 · AI →
P-04

Denial prediction

Risk score per claim before submission. 80+ root cause patterns by payer, CPT, region. Auto-routes high-risk claims for prevention work.

M-03 · AI →
P-05

Security architecture

AES-256-GCM PHI at rest. RS256 asymmetric signing. PHI access log. Boot-time secret guard. Six §164.312 controls implemented in code.

HIPAA →
P-06

API & FHIR

RESTful API. FHIR-native bidirectional with 6 major EHRs. HL7 and 837 fallback for 12 more. Webhook events for real-time downstream sync.

REST · FHIR →
P-07

Cloud architecture

HIPAA-eligible AWS. Multi-AZ Postgres RDS. ECS Fargate compute. CloudFront edge. Secrets Manager. Reference architecture documented.

AWS →
P-08

EHR integration

Epic, Cerner, Athena, eClinicalWorks, NextGen, Greenway native. 12 additional platforms via HL7. Same-app prompts, no swivel chair.

FHIR · HL7 →
P-09

Claim status 276/277

Live status pull from clearinghouse on submitted claims. Auto-categorizes payer-side stalls. Surfaces stuck claims before they age into the next aging bucket.

Auto-poll →
P-10

Reconciliation AI

Line-level 835/837 matching. Surfaces partial payments, contractual variances, takebacks, bundling issues. 98 percent auto-post rate.

M-07 · AI →
P-11

Root cause analytics

Denial patterns by payer, CPT, provider, pod, location. Pareto rollups for monthly leadership readout. Feeds CDI and clinician education loops.

Analytics →
P-12

AR workflow AI

Follow-up queue prioritized by recoverable dollars, not days. Predicts call outcome before dial. AR follow-up productivity up 2.4x measured.

M-08 · AI →
P-13

Implementation playbook

14-day go-live framework. EHR connection, payer setup, BAA chain, user provisioning. Reference implementations documented.

14-day →
P-14

SLA & uptime

99.9 percent platform uptime SLA. Quarterly DR drills, documented RTO/RPO. Daily encrypted cross-AZ backups. Status page for clients.

99.9% →
HIPAA technical safeguards · §164.312 mapping
✓
AES-256-GCM PHI encryption at restSSN and Tax ID encrypted; mask-by-default API; audited reveal endpoint
§164.312(a)(2)(iv)
✓
Boot-time secret guardRefuses to start with default JWT secret or missing PHI key
§164.312(a)(1)
✓
RS256 asymmetric signingCredential Passport private key never published; public verify endpoint shipped
§164.312(c)(1)
✓
PHI access audit logActor, role, IP, timestamp on every PHI read across the platform
§164.312(b)
✓
Transport-layer security headersHSTS, CSP, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy
§164.312(e)(1)
✓
Row-level multi-tenant RBACSUPER_ADMIN, CLIENT_ADMIN, USER roles with team and client scoping
§164.312(a)(1)
Security by design

HIPAA technical safeguards, tested every release.

Most healthcare platforms list HIPAA compliance as a marketing bullet. We mapped the §164.312 technical safeguards rule to specific platform behaviors that can be tested by automated regression suites. The card to the left is the actual control list, not a roadmap. Each one is implemented in code, exercised on every release, and documented in HIPAA_SECURITY.md.

We are explicit about the boundary. Technical safeguards inside the platform are necessary but not sufficient. Hosting on HIPAA-eligible AWS, signed Business Associate Agreements with each sub-processor, organizational risk analysis, and workforce training are required to call an operation HIPAA-compliant. We document those organizational responsibilities so they do not silently become your problem post-signing.

The stack

What runs under the hood.

Mature, boring, well-instrumented technology choices. No bleeding-edge platforms in production. Every component below is widely deployed and well understood by experienced engineering teams.

Application layer

  • FrontendReact + Vite + TS
  • BackendSpring Boot · Java 17
  • DatabasePostgreSQL 15+
  • MigrationsFlyway · 70+ versioned
  • API styleREST + FHIR
  • MobilePWA · iOS + Android
  • MCPJSON-RPC 2.0 native

Infrastructure

  • CloudAWS · HIPAA-eligible
  • ComputeECS Fargate
  • DatabaseRDS Multi-AZ
  • EdgeCloudFront + WAF
  • SecretsSecrets Manager
  • BackupDaily encrypted · cross-AZ
  • Uptime SLA99.9%

AI & integrations

  • Model providerAnthropic Claude
  • GatewayIn-house LLM Gateway
  • AuditPer-call log · cost · latency
  • EHR integrationsFHIR · HL7 · 837
  • Payer connections1,200+ via clearinghouse
  • CredentialingCAQH · NPDB · NPPES
  • MessagingTwilio · WhatsApp + SMS
Common questions

Frequently asked questions: the technology platform.

What is the technology stack you actually run?
The platform stack is: a React/Vite frontend, a Spring Boot Java 17 backend, a PostgreSQL 15+ database with Flyway-managed migrations, hosted on HIPAA-eligible AWS. The AI layer is built on Anthropic's Claude API through our own LLM Gateway with full audit. EHR integration is FHIR-native with HL7 and 837 fallback. Mobile is delivered as an installable PWA so a single codebase serves iOS, Android, and desktop without a separate native track.
How does the platform integrate with our EHR?
FHIR-native bidirectional integration with Epic, Cerner, Athena, eClinicalWorks, NextGen, and Greenway, plus 12 additional platforms via HL7 or 837 fallback. AI prompts surface inside the clinician's existing chart workflow. Eligibility runs continuous 270/271 verification. Claim status pulls live from the clearinghouse. Denial prediction scores claims before submission. No swivel-chair workflows; the platform meets the chart where it lives.
What is Credential OS and how does it fit into the platform?
Credential OS is our credentialing operating system. Twelve sub-capabilities: NPI auto-enrichment from NPPES, AI document extraction, Pre-Flight Validator, Revenue-at-Risk engine, LLM Gateway, MCP server, conversational assistant, RS256 Credential Passport, Verification Network, WhatsApp/SMS automation, NPDB integration, and CAQH ProView sync. It runs the credentialing service we sell and is the network primitive on top of which several other platform features run, including provider verification across the AI Suite.
How do you handle PHI and HIPAA?
HIPAA technical safeguards required by §164.312 are implemented in code and exercised by regression tests: AES-256-GCM PHI encryption at rest with mask-by-default API responses, audited reveal endpoints, security headers (HSTS, CSP, X-Frame-Options DENY), boot-time secret guards, and a PHI access log capturing actor, role, IP, and timestamp on every read. The AWS HIPAA-eligible reference architecture is documented for client review. BAAs are signed with every sub-processor.
What are the platform performance benchmarks?
Eligibility verification round-trip is under 300 ms at the 95th percentile. Denial prediction scoring runs synchronously on claim submission with under 200 ms median latency. Credential OS Pre-Flight runs 20 deterministic rules in under 100 ms. AI document extraction completes in under 8 seconds for typical license PDFs. Real-time dashboards refresh under 2 seconds. We publish these because we measure them; CFOs ask, and we answer with numbers.
What about uptime and SLAs?
99.9 percent uptime SLA on platform services. Quarterly disaster-recovery drills with documented RTO and RPO. Daily encrypted backups across availability zones. Status page available to clients. SLA is in writing in the master agreement, not in marketing copy.
Can we audit the platform before signing?
Yes. Pre-engagement we share the AWS HIPAA-eligible reference architecture document, the §164.312 control mapping, the sub-processor BAA register, and CTO walkthrough of the codebase. Post-engagement, the audit log is yours to query. The PHI access log is yours to query. The AI Trust Framework attaches model version and evidence to every AI suggestion. We treat audit-readiness as a deliverable, not a defense.
Do we get our data out if we leave?
Yes. Data export is a contracted right. Provider records, claim history, denial taxonomy, AR aging, and credentialing artifacts export in standard formats (CSV, FHIR, 837/835). Transition support is included for 90 days post-termination. The platform was built so leaving is operationally clean; the alternative would be a lock-in that the contract does not promise.

We built the platform. Let us show you the code.

A free technology audit. CTO walkthrough of the architecture, the §164.312 control mapping, and the LLM Gateway audit pattern. No NDA wall, no sales deck. The same documents we share in serious diligence.

Get the CTO walkthrough See Credential OS in depth