01One facility
Foundation scope
A scoping pattern for identity, governed access, organisation structure, notifications and audit requirements at a single clinic or hospital.
Build this scopePricing
Your selections shape the quote
Choose the facility footprint, architecture domains, workflows, laboratory model, integrations and support you want us to review. We turn that operating scope into a written proposal—not a one-size-fits-all list price.
Interactive quote scope
Select the work. Price the real boundary.
Build the facility, domain and workflow scope you want us to review. Your choices shape a written quote; this page does not place an order or activate software.
Example selections are planning data only—not customer, deployment or pricing evidence.
01
Facility footprint
Choose the operating context and number of separately scoped facilities.
Each facility keeps an explicit commercial and access boundary.
02
Architecture domains
Choose from the same five-wing, 35-domain atlas used across the site.
Clinical continuum
0 of 12 selected in this wing
0 of 35 architecture domains selected
03
Workflow scope
Select representative operating models and describe any facility-specific flow for discovery.
For discovery and proposal scoping only. Do not include patient or clinical information.
0/1200
04
Laboratory model
Choose how laboratory work is delivered, then add architecture scoping examples.
Select an in-house, external-referral or hybrid model to add laboratory specialty and functional scope.
05
Integration & implementation
Name the external boundaries and support work that should be visible in the proposal.
Three starting frames
Start with the boundary you operate.
These frames help orient the conversation after you build a scope. They are not fixed bundles: the proposal still names every included domain, workflow, integration, implementation responsibility and support boundary.
02Multi-department operations
Hospital scope
A broader scoping pattern for department boundaries, clinical workflows, governance controls, integrations and implementation support.
Build this scope03Independently isolated sites
Multi-facility scope
A scoping pattern for several separately governed facilities, including infrastructure, identity, integration and implementation boundaries for each site.
Build this scopeHow a quote is formed
Four inputs. One written boundary.
- 01
Facility footprint
Number and type of facilities, departments, units, users and operational environments involved.
- 02
Domain and workflow scope
The architecture domains and concrete workflows included in the written proposal.
- 03
Integration boundary
Identity providers, devices, partner systems, data migration and interface responsibilities.
- 04
Implementation support
Configuration, training, validation, deployment model and ongoing support expectations.
Selection is not activation
Pricing, entitlement and access stay separate.
The public builder records what you want to discuss. A commercial proposal, purchased entitlement, facility readiness and a user’s permission answer different questions and remain independently governed.
- 01
Build the scope
This page records the facility, domains, workflows and dependencies you want to discuss.
- 02
Write the proposal
The proposal names the commercial, implementation and support boundary. The selector itself is not an order.
- 03
Provision entitlements
Approved purchased features and limits are provisioned through the governed Permissions boundary—not by this public page.
- 04
Prove runtime access
A live action still requires user permission, tenant or facility entitlement, operational capability and use-case validation.
Before a proposal
The atlas—and the selector—are not the contract.
The 35-domain atlas explains the platform’s architectural shape. The scope builder records your planning choices. Before any commercial commitment, we confirm the concrete demonstration, implementation and support boundary in writing.
Assurance 01
No invented list price
We scope the actual facility and workflow instead of publishing a number the implementation cannot support.
Assurance 02
Written boundaries before commitment
The proposal names what is included, what evidence is required and who owns each implementation dependency.
Assurance 03
Implementation stays visible
Configuration, migration, integration and support effort are quoted separately from recurring product scope.
A clearer next step
Build the scope before the quote
Select the facility, domains, workflows, laboratory model and implementation boundaries. Then send one structured brief for review.