Registration, ADT, bed management and patient access

C0573Does AuroraMed register outpatient, emergency, inpatient, observation, home-visit and virtual encounters with class, type, location and participants?

The pilot covers part of this. The rest is designed, not built. Pilot detail: Preferred name/name fields, data-quality tab, visits (AMB/IMP/EMER), edit history stores field names only with values encrypted; not the full spec model. For reference, REQ-0301 (a top-priority requirement, all three tiers) says the system must register outpatient, emergency, inpatient, observation, home-visit and virtual encounters with class, type, location and participants. Check: each class produces the right encounter states and interface events.

C0574Does AuroraMed support pre-registration and digital/kiosk check-in with identity and consent capture?

The system must support pre-registration and digital/kiosk check-in with identity and consent capture. That is REQ-0302, a high-priority requirement for all three tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: patient completes forms on a tablet or kiosk; results appear in registration queue.

C0575Does AuroraMed support ED quick registration, mass-casualty registration and unknown-patient shortcuts?

Designed, not built: there is no code for this in the pilot. REQ-0303 says the system must support ED quick registration, mass-casualty registration and unknown-patient shortcuts. Its acceptance check: eD quick registration completes with three fields; the record is completed later.

C0576Does AuroraMed support admission, transfer, discharge, cancel-admit, cancel-transfer and cancel-discharge with correct state transitions?

REQ-0304 is a top-priority requirement for all three tiers: the system must support admission, transfer, discharge, cancel-admit, cancel-transfer and cancel-discharge with correct state transitions. This is on the design side of the line. Nothing in v0.2.0 does it. To verify it, the specification says illegal transitions are refused; cancel events reference originals.

C0577Does AuroraMed emit and consume HL7 v2 ADT events and FHIR Encounter changes?

The registration, adt, bed management and patient access part of the specification (REQ-0305) says the system must emit and consume HL7 v2 ADT events and FHIR Encounter changes. No. The specification describes it, but the pilot does not include it. Acceptance check: round-trip test of A01/A02/A03/A04/A08/A11/A12/A13/A28/A31 passes.

C0578Does AuroraMed provide a bed board and census with bed status (available, occupied, cleaning, blocked) and isolation/acuity matching?

How would it be tested? The specification says assigning an isolation patient to a non-isolation room warns. That is the check for REQ-0306: the system must provide a bed board and census with bed status (available, occupied, cleaning, blocked) and isolation/acuity matching. Not yet. It is designed in the specification and not built in the pilot.

C0579Does AuroraMed provide a transfer center for inbound/outbound transfers including EMTALA documentation and acceptance recording?

Designed, not built: there is no code for this in the pilot. For reference, REQ-0307 (a high-priority requirement, the medium and large tiers) says the system must provide a transfer center for inbound/outbound transfers including EMTALA documentation and acceptance recording. Check: transport cannot be dispatched without acceptance record.

C0580Does AuroraMed track observation status with Two-Midnight clocks and notice issuance (MOON)?

The system must track observation status with Two-Midnight clocks and notice issuance (MOON). That is REQ-0308, a medium-priority requirement for the large tier only. This is on the design side of the line. Nothing in v0.2.0 does it. Test in the specification: clocks show elapsed; overdue notice raises task.

C0581Does AuroraMed record coverage with multiple payers, priority order and eligibility verification (X12 270/271, real-time and batch)?

No. The specification describes it, but the pilot does not include it. REQ-0309 says the system must record coverage with multiple payers, priority order and eligibility verification (X12 270/271, real-time and batch). Its acceptance check: eligibility response updates coverage snapshot with timestamp.

C0582Does AuroraMed capture required notices and acknowledgments (NPP, consent to treat, financial policy, IM, MOON, ABN) with signature and delivery proof?

REQ-0310 is a top-priority requirement for all three tiers: the system must capture required notices and acknowledgments (NPP, consent to treat, financial policy, IM, MOON, ABN) with signature and delivery proof. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says missing required notices block completion when site policy says so.

C0583Does AuroraMed support electronic signature capture (pad, tablet) with evidence and hash of the displayed document?

The registration, adt, bed management and patient access part of the specification (REQ-0311) says the system must support electronic signature capture (pad, tablet) with evidence and hash of the displayed document. Designed, not built: there is no code for this in the pilot. Acceptance check: signature verification recomputes the document hash.

C0584Does AuroraMed capture advance directive and code status with document link?

How would it be tested? The specification says banner shows code status; change requires clinician role. That is the check for REQ-0312: the system must capture advance directive and code status with document link. This is on the design side of the line. Nothing in v0.2.0 does it.

C0585Does AuroraMed calculate patient estimates and Good Faith Estimates when charge data exist?

No. The specification describes it, but the pilot does not include it. For reference, REQ-0313 (a medium-priority requirement, the medium and large tiers) says the system must calculate patient estimates and Good Faith Estimates when charge data exist. Check: estimate document lists items and disclaimers per profile.

C0586Does AuroraMed support financial clearance and financial assistance screening with sliding-fee schedules?

The system must support financial clearance and financial assistance screening with sliding-fee schedules. That is REQ-0314, a high-priority requirement for all three tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: screening result records policy version.

C0587Does AuroraMed track waiting-room status and arrival-to-rooming workflow with display boards that show minimal identifiers?

Designed, not built: there is no code for this in the pilot. REQ-0315 says the system must track waiting-room status and arrival-to-rooming workflow with display boards that show minimal identifiers. Its acceptance check: board shows first name and initial only.

C0588Does AuroraMed issue wristbands and labels (Code 128 / 2D) with two identifiers and allergy alert marks?

REQ-0316 is a top-priority requirement for all three tiers: the system must issue wristbands and labels (Code 128 / 2D) with two identifiers and allergy alert marks. The pilot covers part of this. The rest is designed, not built. What v0.2.0 does today: Wristband preview with two identifiers and allergy flag; barcode is a text/font stand-in, not a real Code 128 print. To verify it, the specification says scan of a printed band resolves the same patient.

C0589Does AuroraMed produce After-Visit Summaries and discharge instructions in the patient's language?

The registration, adt, bed management and patient access part of the specification (REQ-0317) says the system must produce After-Visit Summaries and discharge instructions in the patient's language. No. The specification describes it, but the pilot does not include it. Acceptance check: aVS includes meds, follow-up, pending results.

C0590Does AuroraMed support visitor management and visit restrictions?

How would it be tested? The specification says restricted patient hides room from directory. That is the check for REQ-0318: the system must support visitor management and visit restrictions. Not yet. It is designed in the specification and not built in the pilot.

C0591Does AuroraMed support patient transport requests and tracking inside the facility?

Designed, not built: there is no code for this in the pilot. For reference, REQ-0319 (a medium-priority requirement, the medium and large tiers) says the system must support patient transport requests and tracking inside the facility. Check: request appears on porter worklist.

C0592Does AuroraMed audit all registration edits with old/new values encrypted?

The system must audit all registration edits with old/new values encrypted. That is REQ-0320, a top-priority requirement for all three tiers. The pilot covers part of this. The rest is designed, not built. What v0.2.0 does today: Preferred name/name fields, data-quality tab, visits (AMB/IMP/EMER), edit history stores field names only with values encrypted; not the full spec model. Test in the specification: audit shows field, actor, time; values decrypt only under privacy officer step-up.

C0593Does AuroraMed run front-end claim edits at registration?

No. The specification describes it, but the pilot does not include it. REQ-0321 says the system must run front-end claim edits at registration. Its acceptance check: missing subscriber id is flagged before visit end.

C0594Does AuroraMed support Brazil SUS registration data (AIH/BPA), CNS lookup and CADSUS integration and equivalent country adapters?

REQ-0322 is a medium-priority requirement for all three tiers: the system must support Brazil SUS registration data (AIH/BPA), CNS lookup and CADSUS integration and equivalent country adapters. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says adapter validates CNS checksum and returns registry data when connected.