NEXUS OS / HELIX
Care decisions deserve a clear handoff.
NEXUS HELIX is a home-health workflow product direction. Before software enters a clinical journey, an agency needs to see who owns the referral, assessment, care plan, visit, and revenue handoff—and where the record can be trusted.
The agency journey
Four handoffs worth testing.
These are buyer evaluation questions, not a list of released HELIX modules. Bring one de-identified workflow; do not send patient records through this website.
- 01
Referral to admission
Who accepts the referral, confirms the agency can serve it, and records the decision?
A referral queue is only useful when ownership, missing documents, and the decision to admit or decline are visible to the right people. Map the present handoff before asking a new system to replace it.
- 02
Assessment to plan of care
Where do assessment findings, orders, and the plan diverge?
For Medicare home health, OASIS-E2 is the current instrument. The clinical team must own assessment and care decisions; a product evaluation should test version control, review, and how exceptions reach the responsible practitioner.
- 03
Visits to documentation
Can a coordinator see an uncovered visit without exposing records to the wrong role?
Compare the planned visit, the actual service, and the clinician's documentation. Ask who resolves a missed visit, a late note, or a change in condition—and what audit trail the agency requires.
- 04
Documentation to revenue
What evidence does the billing desk need before it works a claim?
Define the handoff to eligibility, authorization, notice, claim, and denial work. A clinical software discussion is not a contract for LUCA's medical billing team to perform billing labor.
Before a product decision
Proof before access.
Architecture approval is not clinical, EMR, HIPAA, payer, or regulatory certification. The applicable clinical and security reviews cannot be skipped by a marketing page.
- 01
Clinical ownership
Agency clinicians remain accountable for assessments, orders, care plans, and documentation.
- 02
Security and contract
Tenant boundaries, role access, audit, incident response, and the applicable business-associate agreement need review before any protected data is handled.
- 03
Current rules
OASIS version, payer requirements, and state-specific obligations must be verified for the agency and use case; this page is not a certification.
- 04
Actual product evidence
A demo, integration, patient portal, scheduling, EVV, or claim workflow must be proven in the approved runtime before it is described as delivered.
A first conversation
Show us where work stalls.
Describe your agency type, current systems, roles, and one de-identified exception. We can discuss fit and the evidence required before any deployment conversation. Do not include patient names, claim details, medical records, credentials, or protected documents.
Book a call
For regulatory context, see the CMS OASIS-E2 manual (opens in a new tab) and HHS cloud and business-associate guidance (opens in a new tab). These sources describe obligations and evaluation context; they do not endorse or certify HELIX.