Janus post-service authorization needs scope evidence
Janus Health says its prior-authorization workflow can submit authorization for rendered services that were not included in an original approval. That post-service submission must retain the original decision, actual service, added scope, payer response, and claim relationship without implying retroactive approval, coverage, or payment.
Editorial figure by Prior Auth Monitor. Source context: Janus Health AccessIQ Prior Authorization.
Freeze the original approval and service scope
The direct answer is to preserve two independently reviewable records: what the payer authorized prospectively and what the provider later rendered. The original record should retain patient and member identity under appropriate access controls, plan and payer, ordering and rendering entities, requested service and coding, quantity, units, site, dates, clinical package, submission channel, decision identifier, approved scope, conditions, validity period, and source receipt. It should not be rewritten when a later discrepancy is found.
The rendered-service record should capture the actual service, code and modifiers, quantity, date, site, clinician, source system, correction history, and reason it differs from the approved scope. That difference may reflect an added service, changed quantity, coding correction, clinical circumstance, documentation gap, or workflow failure. A generic mismatch flag is not enough for an accountable reviewer to determine which next action is permitted.
Create a distinct post-service submission
Janus Health's official page describes submitting authorization for services rendered but not included in the original approval. Model that as a new, linked request with its own submission time, payer and plan, service scope, reason, evidence bundle, channel, acknowledgement, status, determination, denial reason, appeal path, and owner. The link to the original approval should explain the discrepancy without changing what the earlier decision covered.
Use status labels that describe evidence rather than hoped-for outcomes: discrepancy identified, review required, post-service request prepared, submitted, acknowledged, pending, approved, partially approved, denied, withdrawn, or unresolved. The provider's use of reconciliation language does not establish that a payer accepts the request, applies it retroactively, waives another requirement, or pays the associated claim. Authorization and payment remain separate decisions.
Reconcile payer status to the exact request
The page says payer status updates can reach the electronic health record through 278I with portal screen-capture details. Preserve the request and decision identifiers, channel, payer timestamp, captured status text, structured status, source artifact, parser or mapping version, retrieval time, exception, and staff disposition. A screen capture can support provenance, but it does not by itself prove that the status belongs to the same service scope or remains current after a portal update.
Do not merge the post-service status with the original request merely because patient, encounter, or payer matches. Reconciliation should test member, plan, service, date, quantity, site, rendering entity, and authorization identifier. Ambiguity should remain queued for review. If a payer response conflicts with a transaction or portal record, preserve both and record the resolution rather than selecting the more favorable result.
Test a partial approval with an added service
Use a scenario in which an original request receives partial approval, an additional service is rendered, a modifier changes after coding review, the portal displays one status, the transaction feed arrives later, and the claim is submitted before the discrepancy is resolved. Reviewers should reproduce the original approval, identify the exact unapproved scope, build the post-service record, retain every response, route an appeal or correction where appropriate, and keep claim status separate.
Janus Health's official page supports the attributed claims about requirement discovery, member- and plan-specific responses, clinical bundling, automated submission, payer status updates, EHR integration, and post-service reconciliation. It does not establish payer acceptance, clinical correctness, coding accuracy, portal or transaction completeness, retrospective approval, coverage, payment, compliance, savings, or patient outcome. Clinical, utilization-management, revenue-cycle, coding, privacy, payer, legal, and patient-access owners retain those decisions.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.