Marcus Tilden runs operations for a PE firm that owns six physician practices across North Carolina and Virginia. He is reviewing denial rates on a Wednesday afternoon, and the numbers look normal. Practice A in Raleigh shows UHC denials for 99214 up three percent this quarter. Within normal variation. Practice C in Richmond shows the same code denied at a rate four percent above baseline. Also within normal variation. Practice F in Greensboro, five percent. Each practice manager has noticed a small uptick. None of them have escalated it, because a three-to-five percent fluctuation in denial rates for a single code does not, at any individual practice, clear the threshold for alarm.
Marcus would not have caught this either. Six practices, each with its own billing workflow, each reporting denial rates in its own format on its own schedule. The portfolio-level view he assembles manually at month-end would show the aggregate, but the month-end report is three weeks away. By then, the denials will have compounded.
The cross-entity orchestration layer catches it in 72 hours. Not because any single entity’s intelligence is insufficient, but because the pattern is invisible at entity scale. An eleven-percentage-point aggregate increase in 99214 denials across six entities in two states, concentrated in UHC, starting the same week: this is not random variation. This is a payer policy change. UHC has adjusted its documentation requirements for established patient visits, and the adjustment was not announced through the standard provider communication channels. It surfaced only in denials.
Without cross-entity orchestration, Marcus discovers this at his quarterly review. By then, three months of denials have accumulated. At an average of twelve 99214 claims per practice per week, six practices, and twelve weeks, that is 864 claims. At a $150 average reimbursement and a 40% denial rate increase, the portfolio has left roughly $52,000 in uncontested denials on the table. The number is not catastrophic for a portfolio this size. But multiply it across fifteen denial patterns per year, and the annual impact crosses half a million dollars. That is the cost of not seeing patterns that exist only at portfolio scale.
Pattern Propagation Architecture#
The constraint is real and architecturally enforced: Entity A’s specific billing data does not transfer to Entity B. The revenue cycle concierge at Practice A knows that patient John Smith’s 99214 claim was denied on March 3 with reason code CO-16. The revenue cycle concierge at Practice C knows nothing about John Smith and should know nothing about him. Patient-level data stays at the entity where it was generated.
What propagates is the pattern, stripped of identifying information. Three mechanisms make this work.
Aggregate metrics are the simplest. Each entity’s revenue cycle concierge computes denial rates by payer, by CPT code, by time period. These are statistical summaries, not patient records. “UHC denial rate for 99214: 18% this quarter, up from 15% last quarter” contains no patient-identifiable information. It is a property of the entity’s billing operations, not a property of any individual patient. These metrics propagate to the portfolio layer automatically.
Anonymized pattern signatures add structure to the aggregates. A pattern signature is a structured description: pattern type (denial rate increase), affected domain (revenue cycle), payer (UHC), code cluster (E/M established patient), magnitude (11 percentage points aggregate), timing (onset week of February 24), geographic scope (NC and VA), entity count (6 of 6 entities affected). The signature contains enough information for the portfolio intelligence layer to classify the pattern and recommend a response. It contains no information that identifies which patients were denied or which specific claims are involved.
Portfolio SLMs are models trained on aggregate, anonymized patterns using federated learning principles. The portfolio does not collect raw data from entities and train centrally. Each entity’s operational agents compute local model updates based on their own data. The updates, which are gradient adjustments to model weights, propagate to the portfolio layer for aggregation. The aggregated model improves pattern detection without any entity’s raw data leaving its boundary. This is federated learning applied to operational intelligence, and the privacy guarantee is mathematical, not policy-dependent.
The distinction matters. A policy that says “we will not share your data” is a promise. An architecture that cannot share your data because the data never leaves the entity boundary is a guarantee. The membrane enforces the guarantee at the infrastructure level. No configuration change, no administrative override, and no software update can cause patient-level data to propagate through the portfolio layer, because the portfolio layer’s APIs do not accept patient-level data structures. The prohibition is not a rule. It is a type constraint.
Multi-Entity Workflows#
Not all cross-entity orchestration involves pattern detection. Some involves direct operational coordination between entities in the same portfolio.
A patient referral from Practice A to an imaging center (Center B) owned by the same PE firm is a multi-entity workflow. The referring physician at Practice A orders an MRI. The referral concierge at Practice A checks the patient’s insurance, determines that Center B is in-network, and initiates the referral. The scheduling concierge at Center B needs the referral context: the ordering diagnosis, the requested procedure, the prior authorization status, and the patient’s scheduling preferences. The referral concierge at Practice A needs the appointment confirmation to close the referral loop and update the patient’s chart.
Two entities, four agents, one coordinated workflow. The membrane governs what crosses the entity boundary. The patient’s referral context crosses because the patient consented to the referral. The patient’s full medical history does not cross because Center B does not need it for scheduling. The referral concierge at Practice A transmits a scoped context package: the information Center B needs and nothing more.
This is not data sharing. It is data scoping. The difference is architectural. Data sharing implies that Center B receives a copy of Practice A’s patient record and can use it for any purpose. Data scoping means Center B receives a referral context package that contains only the fields required for the referral workflow, that expires when the workflow completes, and that cannot be repurposed for other uses. The scoping rules are defined in the membrane’s trust tier configuration, not in a data sharing agreement that someone might or might not follow.
The multi-entity workflow also closes the loop that most referral tracking systems leave open. After Center B performs the MRI, the radiology report feeds back through the membrane to Practice A’s referral concierge, which updates the referring physician’s chart with the completion status and the report availability. The referring physician does not need to call Center B to check whether the MRI was done. The workflow handles it. For a portfolio with hundreds of internal referrals per month, the loop closure eliminates a category of administrative follow-up that currently consumes staff time at both ends.
When the referral crosses portfolio boundaries, to an imaging center not owned by the same PE firm, the multi-entity workflow degrades gracefully. The referral concierge at Practice A still initiates the referral, but without a BlueMirror adapter at the external center, the coordination is limited to fax or portal-based communication. The system tracks the referral as pending and monitors for a result through whatever channel the external center uses to return reports. The intelligence is partial but still better than the fully manual process it replaces.
The Trust Tier Interaction#
Cross-entity orchestration does not operate at a single permission level. The trust tier framework described in BOI-05.01 governs what intelligence flows across entity boundaries, and the orchestration layer adapts to the current tier per entity.
At Tier 1, the minimum trust level, only aggregate financial metrics propagate. Denial rates, collection rates, days in A/R, charge capture ratios. These are the metrics a PE firm needs for basic portfolio oversight. No operational intelligence flows. No pattern signatures. No federated learning updates. The entity is on the platform, but the portfolio sees only the numbers.
At Tier 2, anonymized pattern signatures begin propagating. The portfolio layer can detect cross-entity patterns like the UHC denial increase. But it cannot drill into entity-specific context. It knows six entities are affected; it cannot examine any individual entity’s denial details through the portfolio layer.
At Tier 3, operational intelligence flows with entity consent. The portfolio layer can request specific operational context from an entity when investigating a pattern, and the entity’s governance configuration determines whether to grant the request. A center manager who wants the portfolio to help investigate a denial pattern can consent to temporary context sharing. A center manager who prefers to handle it internally can decline.
At Tier 4, real-time operational intelligence flows continuously. This is full portfolio-level coordination: cross-entity scheduling optimization, shared waitlist management for patients who could be served at multiple portfolio entities, coordinated payer negotiation strategy informed by real-time operational data from all participating entities.
The orchestration layer never assumes maximum access. Every cross-entity data flow checks the current trust tier for both entities involved. An entity that was Tier 4 last month and downgraded to Tier 2 this month because of a governance dispute sees its data flows restricted immediately. The restriction is not a manual process; it is an automatic response to the trust tier change. The orchestration layer reads the trust configuration on every transaction.
What Cannot Propagate#
The boundaries are explicit and architecturally enforced.
Individual patient data never crosses entity boundaries through the portfolio layer. A patient seen at Practice A and referred to Center B has data at both entities. But the portfolio layer does not aggregate patient-level data across entities. It cannot construct a cross-entity patient record. It cannot identify which patients are seen at multiple portfolio entities unless those entities share that information through a direct, patient-consented workflow (like the referral process described above).
Individual staff performance data never aggregates at the portfolio level. The staffing concierge at each entity tracks productivity metrics for its own staff. These metrics do not propagate. The portfolio cannot rank physicians across practices by productivity, because that ranking would require entity-level staff data that the membrane blocks from portfolio propagation.
Specific contract terms never share across entities. The payer contract concierge at Practice A knows Practice A’s reimbursement rate for 99214 under its UHC contract. That rate does not propagate to the portfolio layer or to any other entity. Sharing specific contract terms across entities within the same portfolio raises antitrust concerns that the architecture eliminates by making the sharing structurally impossible.
Identified physician-level quality data aggregates only with explicit physician consent. If Dr. Patel at Practice A wants her quality metrics included in a portfolio-level benchmarking report, she consents. If she does not consent, her metrics are excluded from the aggregate. The consent is per-physician and revocable. The default is non-participation.
These are not policies that the platform promises to follow. They are architectural constraints that the platform cannot violate. The membrane does not have a configuration option for “propagate patient data to portfolio layer.” The API does not accept the data structure. The prohibition is not a rule in a policy document. It is a constraint in the code.
Cross-References
BOI-02.01 The Operational Brain: the single-entity DAG architecture that generates the patterns cross-entity orchestration detects and correlates across the portfolio.
BOI-05.01 Trust Tiers: the trust tier framework governing what intelligence propagates across entity boundaries at each level of portfolio integration.
BOI-05.03 Data Sovereignty: the ownership architecture that determines which entity controls its data and under what conditions cross-entity flows are permitted.
BOI-01.18 Portfolio Intelligence: the operational concierge agent that consumes cross-entity intelligence and surfaces portfolio-level recommendations.
BMT-03.01 The Membrane: the consumer membrane architecture that BOI adapts for entity-to-portfolio data governance, enforcing propagation boundaries at the infrastructure level.
Technical Appendix BOI-02.02-A is available to partners and investors at partners.bluemirror.tech.