Founder & CEO, ArkCloud Health LLC·Atlanta, GA·Open to select projects

Building ArkCloud Health: one connected record, from referral to claim

Most therapy practices do not have a software problem. They have a handoff problem — four systems and a fax machine standing between a referral and a paid claim. ArkCloud Health is my attempt to collapse that distance.

The ArkCloud Health homepage: the headline 'From referral to claim, on one connected record' over a therapy practice's reception desk
The thesis on the front page of arkcloudhealth.com, stated as plainly as it can be: from referral to claim, on one connected record.

I have spent my career on the data layer of systems that cannot afford to be wrong — production databases at eBay, ActiveCampaign, Disney, McKesson, and today RegEd. That work teaches a specific kind of impatience: you stop believing that a process is fine just because it has always been done that way.

ArkCloud Health is what happened when I pointed that impatience at outpatient rehabilitation. The platform’s thesis fits in one sentence: from referral to claim, on one connected record. Everything else about the product follows from taking that sentence seriously.

Jamaurice Holt, Founder and Chief Architect of ArkCloud Health LLC, building the platform
Designing and building the platform myself — tenant isolation, PHI encryption, and the EDI claims architecture underneath the screens.

The handoff is the problem

A therapy practice runs on continuity: a referral arrives, an authorization is checked, an episode of care opens, a plan of care is written, visits are scheduled and documented, notes are signed, charges are built, claims go out, payments come back, denials get appealed. Nine steps, usually spread across four or five systems that were never designed to talk to each other.

Each boundary between those systems is a place where information is retyped, where an authorization lapses unnoticed, where a note is signed a week late and the claim waits on it, or where a denial is discovered long after the visit. None of that is exotic. It is the ordinary tax a practice pays for fragmented records — and it lands hardest on small and mid-sized practices that cannot afford a billing department to absorb it.

So the design decision was not "which module do we build first." It was that the patient record is the unit of truth, and every function reads and writes to that one record.

What ArkCloud Health actually is

Outpatient rehab and revenue cycle software, built as a connected platform rather than a suite of integrations:

  • ArkCloud Rehab — referrals, episodes of care, plans of care, scheduling, therapy documentation, signed notes, and outcome measures.
  • ArkCloud RCM — charges built from signed notes, authorization checks, 837P claim creation, payment posting, denials and appeals, patient statements, and balances.
  • The wider platform — ArkCloud Access, Care, Insights, Workforce, and Clinical, so a practice can add capability without changing systems.

It serves physical, occupational, and speech-language therapy practices, outpatient rehab groups, revenue cycle and billing teams, and multidisciplinary care teams — the practices where a missed authorization or a late note is the difference between a clean claim and a written-off one.

Underneath, it is a claims and data problem

The interesting engineering is not the calendar. It is the part nobody sees: tenant isolation, so one practice’s PHI can never be visible to another; PHI encryption at rest and in transit; and the EDI claims architecture that turns a signed note into a compliant 837P and reconciles what comes back.

ArkCloud Health platform screen: one synthetic patient's journey from referral through documentation, billing and remittance, with the ArkCloud Rehab, RCM and Access applications handling each stage
One record, four stages: the platform’s synthetic-patient walkthrough showing which application handles each step — ArkCloud Access, Rehab and RCM working off the same episode of care.

That framing is the reason I insisted on building this platform around its data model instead of around its screens. When the record is one thing, an authorization check happens before the charge exists, the note that justifies a claim is the same note the clinician signed, and a denial can be traced back to the exact visit that produced it. When the record is five things, all of that becomes reconciliation work — which is to say, people.

What the AI does — and what it does not

The platform ships with substantial AI assistance: 36 live AI-assisted features and 9 live rule-based automations, with 8 more in development. But the guiding rule is stated on the site as plainly as I can put it: assistance inside the work, with a person deciding.

Clinicians sign every note. A person approves financial actions. The system does not diagnose and does not make clinical decisions. And there is a category you rarely see on a product page: seven capabilities marked "deliberately not offered."

I put that list there on purpose. In healthcare, the honest question about an AI feature is not whether it is impressive but whether a clinician can defend it to a payer, an auditor, or a patient. Where the answer was no, the feature does not ship — and saying so out loud is more useful to a practice than a longer feature list. It is the same instinct behind the AI governance work at EVE CoreGuard: automation has to be bounded by something a human can inspect.

Where the platform honestly stops

ArkCloud Health is a young product, and I would rather a practice discover its limits from me than from an implementation call. What is live today covers the core loop: referral, scheduling, signed notes, authorization checks, charges, and 837P claim creation.

What is not yet live is transactional: sending claims and receiving remittance requires a clearinghouse connection, and that connection is built but not yet wired to the service. Payer enrollment can also take weeks, and a practice that takes card payments will need a Stripe account. Eligibility checks depend on a vendor account. And the licensed outcome measures a practice may want to use are not yet published on the platform.

None of that is a secret, and none of it changes the underlying argument. It is simply the difference between "what the software does" and "what your practice can do on Monday morning" — and conflating the two is how healthcare software earns a reputation it does not deserve.

Compliance sits in the same honest category. The platform is built with HIPAA safeguards throughout — access control, encryption, auditability, tenant isolation — and the site documents those controls directly rather than asserting a certification badge it has not earned.

Who it is for, and how to see it

If you run a physical, occupational, or speech therapy practice — or a revenue cycle team that spends its week chasing the gap between a signed note and a paid claim — the fastest way to judge this is to look at the product, not the pitch. There is a 14-day trial with no card required at arkcloudhealth.com.

I work on the platform alongside Johnny Magee, who serves as President & Operating Partner. I am the Founder & Chief Architect — which in practice means I still write the schema, review the security model, and argue about the claims pipeline.

Why this belongs next to the rest of the work

People occasionally ask why a database administrator is building healthcare software. The answer is that the hardest part of healthcare software was never the healthcare part for me — it is the guarantees. Correctness under load. Isolation between tenants. A record that can be trusted because it is one record. That is the same discipline as running production data platforms that cannot go down, aimed at a domain where the consequences are human rather than financial.

— Jamaurice Holt, Founder & CEO of ArkCloud Health LLC

Building something in healthcare?

If you are working on clinical software, PHI handling, or the data layer underneath either one, I am always glad to compare notes.