AuroraMed v0.2.0 is a synthetic-data pilot. See exactly what's built →

Portal, billing and business requirements

Revenue cycle, billing and payer connectivity

Charges, claims, remittance, denials.

How to read status labels: In the pilot (v0.2.0, synthetic data) Simulated in the pilot Coming (Wave 2, rolling out) Designed, not yet built Open decision Not offered / no claim made Planned partner integration

C0810Does AuroraMed capture charges from documentation and orders with charge master validation?

No. The specification describes it, but the pilot does not include it. For reference, REQ-1801 (a top-priority requirement, all three tiers) says the system must capture charges from documentation and orders with charge master validation. Check: charge line references active CDM version.

Designed, not yet builtPermalink

C0811Does AuroraMed generate and submit X12 837P/837I/837D with SNIP-style edits and receive 999/277CA/835?

The system must generate and submit X12 837P/837I/837D with SNIP-style edits and receive 999/277CA/835. That is REQ-1802, a top-priority requirement for the medium and large tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: claim round trip against test clearinghouse.

Designed, not yet builtPermalink

C0812Does AuroraMed support 270/271, 276/277 and 278 transactions?

Designed, not built: there is no code for this in the pilot. REQ-1803 says the system must support 270/271, 276/277 and 278 transactions. Its acceptance check: transaction logs store control numbers.

Designed, not yet builtPermalink

C0813Does AuroraMed post remittances (835), manage denials/appeals and patient statements?

REQ-1804 is a top-priority requirement for the medium and large tiers: the system must post remittances (835), manage denials/appeals and patient statements. This is on the design side of the line. Nothing in v0.2.0 does it. To verify it, the specification says 835 balances.

Designed, not yet builtPermalink

C0814Does AuroraMed support Brazil TISS XML guides with digital signature and SUS billing; Colombia RIPS/FEV/CUV; Mexico CFDI; other country billing adapters?

The revenue cycle, billing and payer connectivity part of the specification (REQ-1805) says the system must support Brazil TISS XML guides with digital signature and SUS billing; Colombia RIPS/FEV/CUV; Mexico CFDI; other country billing adapters. No. The specification describes it, but the pilot does not include it. Acceptance check: each adapter passes its authority validator in test.

Designed, not yet builtPermalink

C0815Does AuroraMed support price transparency files and Good Faith Estimates?

How would it be tested? The specification says file generated in required schema (to be verified). That is the check for REQ-1806: the system must support price transparency files and Good Faith Estimates. Not yet. It is designed in the specification and not built in the pilot.

Designed, not yet builtPermalink

C0816Does AuroraMed support payer-platform functions: contract modeling, eligibility, prior authorization APIs (CMS-0057-F)?

Designed, not built: there is no code for this in the pilot. For reference, REQ-1807 (a lower-priority requirement, the large tier only) says the system must support payer-platform functions: contract modeling, eligibility, prior authorization APIs (CMS-0057-F). Check: payer API conformance (to be verified).

Designed, not yet builtPermalink
See the synthetic-data demo first.Request a demo