A healthcare network coordinates administrative onboarding, clinical suppliers, internal services and investments across several sites and legal entities. EAFlow organizes each of those journeys on the Operational Graph — a named owner, a recorded decision, and confirmation from the system of record or from the authorized owner — starting from the process the organization needs to address first.
01 · The problem
A healthcare network runs across several sites, more than one legal entity, and administrative teams spread between them. Bringing someone on board, clearing a supplier of consumables, requesting maintenance work or replacing a device draws on a different mix of HR, procurement, finance, technology and site administration depending on the journey — rarely the same people, and almost never in the same place.
Coordination runs on whatever is at hand: Microsoft Excel spreadsheets with each site’s open items, a Microsoft Access database someone maintains for equipment requests, email chasing missing paperwork, and Microsoft SharePoint folders where the signed documents end up. Each of them does a useful job, and none of them records which requirement was outstanding, who had to confirm it, or on whose authority the case was closed.
Work does not stall for lack of systems. It stalls when an open item has no named owner and nobody is accountable for confirming the outcome.
02 · The solution
Each journey keeps its own rules, its own participants and its own outcome: administrative onboarding does not close the way supplier onboarding closes, and an internal service request is not decided the way an investment is decided. What they share is the context — sites, legal entities, services, roles, suppliers, contracts, assets and documents with their validity dates — declared once on the Operational Graph.
That shared context keeps every department from rebuilding the same picture: the right legal entity and the applicable authority come from the declared structure; the site connects the request to the service, the room and the relevant owner; evidence that is still valid is reused where it applies, and each legal entity keeps its own review and its own decision. BPMflow supports execution — cases, assignments, deadlines, authorizations and evidence — and each case is built from the sites, legal entities and authorities already declared, not from a standalone diagram. Max answers questions about a case within the authorized context: it explains what is missing, shows the evidence on record and names the next owner.
The scope is the network's administrative operation: the clinical system, the patient record, clinical appointment scheduling and the billing of clinical services stay with the applications and the areas responsible for that function.
03 · The journeys
The five journeys connect — a cleared supplier delivers the replacement that was approved, and a new joiner needs the space an internal service got ready — and each is scoped on its own.
When it happens
Administrative or clinical staff join, an external practitioner comes in under an agreement, or someone moves to another site or legal entity.
Who takes part and what is decided
HR, the service lead, site administration and IT agree which administrative documents and access clearances are required before the effective date.
Possible exceptions
The effective date is brought forward, or an expired document is submitted. The case is returned with a specific note on what to correct, and the tasks already scheduled are reviewed.
How it ends and who confirms it
Returning a case for correction keeps it open; rejecting it with reasons and granting administrative clearance are the two terminal outcomes. That clearance is recorded in the HR system of record, or confirmed by the authorized owner.
When it happens
A supplier of consumables, equipment or services comes on board; a certificate expires; a bank account or an invoicing entity changes.
Who takes part and what is decided
Procurement builds the file, pharmacy and the stores team define the requirements the item must meet, and the supplier submits its own documents through scoped access.
Possible exceptions
A change to sensitive data triggers the verification the organization runs through its own channel, and the case stays open until that verification produces a result.
How it ends and who confirms it
The vendor master record confirms the onboarding, the change or the restriction. If a discrepancy shows up later, document resolution, release, scheduling, payment and reconciliation remain separate states.
When it happens
A service requests maintenance work, a move, a room to be made ready, or support from another area of the network.
Who takes part and what is decided
The requesting area sets out the need, the service owner agrees priority and deadline, and the site confirms the window for the work.
Possible exceptions
The requested window is not available, or the work depends on a third party. The work is rescheduled, the reason is recorded, and the case stays open.
How it ends and who confirms it
The case closes when the requester accepts the work, with evidence of what was done. Carrying out the work and accepting it are two separate milestones.
When it happens
One rule, a document renewal or an administrative change reaches several sites or legal entities of the network.
Who takes part and what is decided
Central administration decides what is handled centrally and what each site owns; finance checks which authority applies in each legal entity.
Possible exceptions
One site has its own variant because of its license or its agreement. The variant is declared with a named owner instead of surviving as an informal exception.
How it ends and who confirms it
The result is a consolidated status per site — resolved, open with an owner, or not applicable — confirmed by each local lead.
When it happens
A device is replaced, a room is fitted out, a site is extended, or administrative or care technology is brought in.
Who takes part and what is decided
The requesting area presents the case; procurement, technology and operations record their position, and the applicable authority decides under the relevant approval threshold and policy.
Possible exceptions
Approval comes with conditions — a comparison of quotes, a technical report, a room cleared for use. Approving and meeting the conditions are two separate milestones.
How it ends and who confirms it
The decision is recorded with the approving authority. Each condition is signed off by the authorized owner or by the system agreed for that requirement, against the supporting document.
04 · Roles
Sets the scope and decides within its authority.
What they see
The status of open cases by site, legal entity and type, with the conditions that are open, due soon or overdue.
What they do
Agrees which journey goes first and signs off each condition against its evidence.
Owns the supplier file and its master record.
What they see
Onboarding, changes and expiries by category and legal entity, with the pending requirement and the deadline.
What they do
Works with the supplier and the reviewing teams, creates or updates the vendor record in the system of record, and records the confirmation.
Brings local context and accepts what is delivered.
What they see
The events, requests and interventions at their site, with the committed date and the next owner.
What they do
Provides context on the role or the space, confirms administrative documents and access clearances, and accepts the work delivered.
Coordinates the event and its case file.
What they see
A queue of events and requests by type, effective date and site, with the supporting paperwork.
What they do
Sets up the tasks for the event, sends it back with a specific request when information is missing, and records the outcome.
05 · Implementation
Implementation starts with one journey at one site, and needs only the context relevant to that process — no architecture program up front. What is declared for the first journey is reused by the ones that follow.
1 · Agree on the first journey
Which journey goes first, which sites and legal entities it reaches, who authorizes each type of case, and what counts as a confirmed outcome.
2 · Capture the operating context and connect source systems
Sites, legal entities, services, roles, the vendor master and validity dates come from the systems of record, and the document repository is connected where it is the authorized source.
3 · Test the journey and adopt it
The journey is tested on current cases at one site, and rules, deadlines and participants are then refined. The client team runs day-to-day operations before the journey reaches the rest of the network.
06 · Typical scenarios
Several sites, more than one legal entity, agreements with external practitioners and paperwork that expires — a familiar picture in provider networks and health payers alike.
Administrative work moves forward when every open item has an owner, every decision is on record, and every outcome is confirmed by the responsible system or by the authorized owner. One journey at one site is the practical way in.
Healthcare Administrative Operations is the EAFlow industry entry point on the Operational Graph, supported by BPMflow’s automation capabilities. The examples on this page are illustrative and describe journeys agreed with each organization.
