Manage a clinic network without giving every branch full access
For Clinic owner / hospital operations manager · Compare approaches
TL;DR — what you’ll learn
- Decide which masters belong to the network and which records require branch or entity scope.
- Version local rates and exceptions instead of overwriting a shared value.
- Shared identity does not imply unrestricted access to every encounter.
- Test cross-branch corrections and support responsibilities before expanding the rollout.
Three clinics share a service code. Two have different approved rates, and one belongs to a different operating entity. A central update replaces all three prices. Staff notice only after a receipt is issued at the wrong rate.
Multi-clinic management software needs a shared-service model, not simply a combined dashboard. Agree which information is published centrally, which can vary by branch and who may see or change each record.
Standardise meaning before standardising values
The network can agree a common service identifier while allowing approved prices to differ. Keep service definition, branch availability, price version and legal entity as separate attributes. A shared code is useful because it lets the network compare like activity; it need not force every local commercial term to be identical.
In this illustrative example, service S-10 is offered at branches A, B and C. A has an approved rate of ₹700, B ₹800 and C ₹750. The rate selected for a transaction should resolve to its branch, applicable date and approved version. These are teaching amounts, not pricing recommendations.
Scroll horizontally to see all columns.
| Decision | Proposed central responsibility | Proposed local responsibility |
|---|---|---|
| Service definition | Maintain shared meaning and identifier | Request a scoped addition or correction |
| Price publication | Approve the applicable governance model | Apply only authorised branch rates |
| User access | Define roles and approval process | Confirm current assignment and need |
| Daily collections | Define reconciliation categories | Explain branch receipts and exceptions |
The network’s legal-entity structure, price authority and correction rights are required inputs to the design. Ask finance and the relevant governance owners to document them before choosing central or local controls; this guide does not supply a cross-entity accounting policy.
Separate identity from permission to read
In the evaluation, sharing an identity reference and sharing access to a record are separate requirements. Ask clinical and privacy owners to supply an access matrix by role, site and purpose, then test permitted and denied cases. No cross-branch access entitlement is assumed here.
Bahmni's registration documentation describes patient and visit information. For network evaluation, take the distinction further: test recognition of an existing identity separately from permission to open a particular visit or document.
Use synthetic identities and staff roles. A branch receptionist should not gain access to unrelated clinical records simply because a central search finds the person. Equally, a support operator should not use unrestricted administrator access for routine help.
Make a local exception explicit
Suppose branch B needs a temporary rate approved for a particular contract. Record its scope, effective period, approving authority and relationship to the shared service. When the exception expires, the system should follow the approved rate-selection rule rather than guess from whichever value was edited last.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepCentral master proposal
- B · StepAuthorised network review
- C · StepPublish version with branch scope
- D · DecisionTransaction has applicable local exception
- E · StepValidate approved exception and period
- F · StepUse applicable standard version
- G · DecisionScope resolves unambiguously
- H · StepBranch finance review queue
- I · StepRecord selected version on transaction
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Central master proposal | Continue | B: Authorised network review |
| B: Authorised network review | Continue | C: Publish version with branch scope |
| C: Publish version with branch scope | Continue | D: Transaction has applicable local exception |
| D: Transaction has applicable local exception | Yes | E: Validate approved exception and period |
| D: Transaction has applicable local exception | No | F: Use applicable standard version |
| E: Validate approved exception and period | Continue | G: Scope resolves unambiguously |
| G: Scope resolves unambiguously | No | H: Branch finance review queue |
| G: Scope resolves unambiguously | Yes | I: Record selected version on transaction |
| F: Use applicable standard version | Continue | I: Record selected version on transaction |
The version stored with the transaction allows later reconciliation without recalculating history using today's rates.
Roll out one handover across two branches
Add an effective-date case to the rollout. In this synthetic example, branch B has an approved rate of ₹800 before 10:00 and ₹840 from 10:00. A transaction entered at 10:05 relates to an event at 09:55. Finance must specify which event and applicable terms determine the rate; the software should retain that basis and the selected version. It should not use entry time simply because that field is easiest to read.
Test a historical reprint after the new rate is active. The earlier transaction should remain explainable using its recorded version. A correction needs its own approved treatment, not a refresh of every old transaction to the latest master value. This is network governance beyond the single-clinic front-desk evaluation, even when both use the same product.
Choose a transaction such as registration-to-receipt and test it at two sites. Include a shared identity, different approved rates, a revoked role and an attempted cross-branch refund. A refund requires the appropriate commercial and finance authority; a shared patient record does not grant it.
Compare a central suite with controlled connections between branch systems. Require demonstrations of the intended tenant, site and entity boundaries, including denied access. A branch filter on a screen is not evidence that the same boundary is enforced through exports and APIs.
Track incorrect rate selection, unauthorised access attempts rejected in testing and unresolved cross-site transactions. Agree who supports a branch when central services are unavailable, including how temporary work is reconciled.
A well-managed network shares definitions and useful information while keeping authority explicit. That is a stronger foundation for expansion than granting broad access and expecting staff to avoid the wrong records.
Next actions
- Map central masters, local exceptions and entity boundaries for two branches.
- Test role restrictions and historical rate selection using synthetic visits.
- Approve support and correction ownership before adding further sites.
Discuss this workflow
Request a two-branch workflow assessment covering shared masters, local rates, role access and cross-site correction ownership.
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- Network COO, finance controller and legal adviser: Entity map, approved pricing/delegation policy and cross-site refund/accounting procedure.
- Clinical governance and privacy lead: Approved identity/access model and synthetic tests of branch-specific permissions.
- CIO and system vendor: Current configuration, access tests, versioned pricing demonstration and outage/support plan.
References
- Bahmni patient registration — Distinction between demographic/identity information, visits and attached documents; not authority for identity merging or privacy compliance.
Topics: multi clinic management software · multi branch clinic software · clinic chain management · centralised clinic operations