By Dafe Ofoh, CEO, Fanoni Lab
LinkedIn: DAFE OFOH
LinkedIn: Fanoni Lab
Healthcare organizations often evaluate interoperability by asking whether data can move from one system to another. That is necessary, but it is not enough. A workflow is not complete when information arrives. It is complete when the right person can see the evidence, understand the current state, make the required decision, and hand the work forward with a traceable record.
The CMS Interoperability and Prior Authorization Final Rule illustrates this shift. Its prior-authorization API requirements include documentation requirements, requests and responses, approval or denial status, reasons, and requests for more information. Those elements describe more than transport. They describe a sequence of evidence and decisions that must remain understandable across organizational boundaries.
The Handoff Is the Unit of Work
A clinical note may support an order, an authorization request, a coding review, a claim, or a follow-up task. Each downstream team needs a different view of the same underlying record. The clinician needs the patient context and the rationale for care. An authorization specialist needs the payer requirement, supporting documentation, deadline, and submission status. A revenue-cycle reviewer needs to understand what was documented, what was coded, what was transmitted, and what still requires human judgment.
When these views live in separate queues, staff can receive the same data without sharing the same context. The practical design problem is therefore not just interoperability. It is preserving accountability as the work changes hands.
Three Elements of an Accountability Layer
First, preserve evidence lineage. A reviewer should be able to identify the source document, the relevant section, the person or system that introduced it, and the point in time it was used. A summary can help with navigation, but it should not replace access to the underlying evidence.
Second, make state and ownership explicit. Labels such as draft, ready for review, returned for information, approved, denied, submitted, and closed should have defined meanings. Every active state should have an owner, a next action, and an escalation path. A queue without those fields is a list, not a managed workflow.
Third, separate assistance from authority. Software can assemble information, check for missing fields, highlight conflicting data, or recommend a next step. The workflow should still identify which decisions require an authorized human, how that review is recorded, and what happens when the reviewer disagrees with the recommendation.
A Practical Evaluation Checklist
Source evidence: Can a reviewer open the original evidence behind a summary or recommendation?
Workflow ownership: Does each workflow state have a defined owner and next action?
Information requests: Are requests for additional information linked to the evidence they require?
Human authority: Can staff distinguish a machine suggestion from an authorized human decision?
Audit history: Does the audit trail show what changed, who approved it, and what was transmitted?
Design for Decisions, Not Just Data Movement
APIs and standards create the foundation for connected healthcare workflows. The next design task is to keep evidence, status, ownership, and human decisions connected after the data arrives. Organizations that map these accountability requirements before selecting or configuring technology will be better prepared to evaluate how work actually moves from the clinical record to operational and revenue-cycle review.