Betasky

Chapter 12: Example Agency — Care Orders & Episodes


Chapter Overview

Level 5 (care orders): register every certification period for every patient as a migration care order in Betasky — then attach PDFs later.

This is simpler than it sounds:

  1. Build one care order spreadsheet (CSV) with Betasky (all episodes, all patients)
  2. Betasky imports all rows — Active, Expired, Discharged, etc. from the CSV
  3. After go-live, your admin uploads archive PDFs to each care order in Betasky when ready

Betasky does not bulk-upload every nursing note, OASIS, or POC for you. That would be thousands of PDFs. You upload them over time in the admin dashboard.


12.1 Why we build a care order CSV

Axxess does not give a clean “current episode only” export. Schedule Activity is chaotic — duplicate SOCs, death rows, wrong “Active” badges.

So Betasky and your admin hold a working session to produce one spreadsheet:

Column (example)Meaning
MRNPatient
Cert start / cert endCertification dates for that episode
StatusActive, Expired, or Discharged (as agreed for cutover)
OASIS vs Non-OASISClinical track
Go-live flagYes only for patients starting forward workflow in Betasky (small list)

Illustrative scale: ~600 care order rows across all patients; ~7 patients flagged for go-live forward workflow.

This CSV is the source of truth — not the raw Axxess “Active” flag alone.


12.2 What you provide

  • Raw cert / episode history from Axxess (Report Center listing, Schedule Activity, your knowledge)
  • Your admin confirms who is actually in care on cutover date
  • Sign-off on the final care order CSV before import

You do not need to print every PDF before care orders are imported. PDFs come after (Section 12.5).


12.3 What Betasky imports from the CSV

For each row in the approved care order CSV:

  • Creates a migration care order on that patient (cert start, cert end, OASIS track)
  • Sets status from the CSV — Active, Expired, Discharged, etc.
  • Ensures only one Active care order per patient (if CSV has multiple Active, extras become Expired)
  • Flags go-live patients for forward workflow (scheduling, new documentation)

So yes — all care orders for each patient are registered, not just the current one. Old closed episodes are there for timeline lookup and PDF attachment.

After import, Betasky may run a status reconciliation against your cutover date if spot-checks find mismatches (e.g. an episode marked Active but cert end date is in the past).


12.4 What you verify after care order import

  • Each patient’s episode list shows the cert periods you expect
  • Active patients have one Active care order (not several)
  • Discharged patients show Expired / Discharged episodes — not Active workflow
  • Go-live patients are flagged and ready for scheduling
  • No PDFs required yet — shells can exist empty until you upload

12.5 Archive PDFs — agency uploads after setup

Once care orders exist, your agency admin uploads PDFs in Betasky:

  1. Open Care Order Details for a historical (or current) episode
  2. Upload OASIS, POC, visit notes, physician orders — whatever you have for that cert period
  3. Betasky stores the PDF and may register an archive visit when the document is a visit or OASIS type (Chapter 14)

When: Anytime after migration setup — same day, same week, or over the following months. Priority order is usually:

  1. Active / go-live patients first
  2. Recently discharged patients
  3. Older retention window over time

There is no expectation that Betasky uploads every nursing note and assessment for every care order. That is your admin’s phased upload at a pace that works for your office.


Next: Chapter 13 — Example Agency: Medications