Architecture review of a health plan’s prior-auth API

Views in this map

1. 1
   The proposalThe design as submitted: what is new, changed, retired or unchanged.
2. 2
   Against the patternsEach part tagged with the approved pattern it follows. Two need exceptions.
3. 3
   Review findingsEight findings from the board’s reviewers, pinned where they apply.
4. 4
   ApprovedApproved with three conditions: the fixes in place, seven findings closed.

The proposal ‹ › Against the patterns ‹ › Review findings ‹ › Approved

Flows to play

• ▷
  A prior-auth requestAn expedited request for a knee MRI, from the EHR to an approval, as proposed. In The proposal view: the request as submitted, with the 72-hour clock running.
• ▷
  The same request, reviewedWhere the knee-MRI request meets the reviewers’ findings. In the Review findings view: the same request, stopping at each finding on its path.
• ▷
  The same request, approvedThe knee-MRI request through the design the board approved. In the Approved view: the same request through the private link, the replica and masked logs.

The model behind it

62 records of 7 types. Every box on the map is one of them, so the filters and the record panel read the same data.

• Components 27
• Findings 8
• Approved patterns 8
• Standards and NFRs 8
• Teams 7
• Conditions 3
• Board decision 1

Filters

Change and Severity and Review domain: pick a value and everything else fades.