Runs on its ownThe standalone demo needs no credentials, account, or external system.
Synorthopic · standalone operations demo
The same module engine.
No external integrations.
Run the same fictional cases from source check through final summary without loading an EHR, payer, PACS, messaging, or coding connection. Intermediate preparation is automatic; the human reviews once at the end.
Automatic preparationEvidence checks, module evaluation, and summary assembly advance without intermediate approval prompts.
One final reviewAn accountable human reviews the consolidated result before anything can leave the system.
No live port is loaded here.
The same 8 replaceable connection contracts move into the customer-private runtime. A live deployment remains blocked until the customer owner supplies registration, mappings, canaries, security controls, and dated operating evidence.
Workforce identity
Not loadedMaps the signed-in workforce user to an approved tenant, environment, role, and session before private data can be shown.
- Port
- OIDC / OAuth 2.0 + PKCE
- Owner
- Customer identity and security
EHR clinical record
Not loadedReads the customer-approved cohort or launched chart through least-privilege FHIR resources; the browser never receives a backend credential.
- Port
- SMART on FHIR R4 / SMART Backend Services
- Owner
- EHR integration and clinical informatics
Document content
Not loadedRetrieves the actual customer-authorized note and report bodies needed for cited evidence, including same-server Binary attachments.
- Port
- FHIR DocumentReference / FHIR Binary / customer document intake
- Owner
- Health information management
Implant and coding providers
Not loadedKeeps licensed SpineCPT content and customer implant mappings behind private provider interfaces; no licensed library is copied into the public app.
- Port
- private provider port / customer implant catalog / UDI reference adapter
- Owner
- Customer coding, supply chain, and SpineCPT license owner
PACS and imaging
Not loadedPackages source imaging and the surgeon question for a separately validated planning system without interpreting images or generating a surgical plan.
- Port
- DICOMweb / customer PACS gateway / validated planning-system API
- Owner
- Radiology, PACS, and imaging security
Payer and clearinghouse
Not loadedSeparates eligibility, authorization, claim-status, and appeal transports from FHIR chart reads; every submission remains human-owned.
- Port
- X12 270/271 / X12 276/277 / X12 278 / Da Vinci CRD/DTR/PAS/CDex
- Owner
- Patient access, revenue cycle, and clearinghouse
Scheduling and messaging
Not loadedCreates a reviewed work item or outreach draft only after plan, recipient, consent, channel, language, and timing are confirmed.
- Port
- EHR scheduling adapter / portal / SMS or voice provider
- Owner
- Practice operations and patient communications
Private data, keys, and audit
Not loadedProvides tenant-scoped persistence, injected key custody, tamper-evident events, retention controls, monitoring, rollback evidence, and restore testing.
- Port
- PostgreSQL / KMS or HSM / append-only audit / observability export
- Owner
- Customer platform, security, and compliance
Supervised run
The work runs automatically. Review once at the end.
Start one run and watch the case move through source validation, evidence mapping, module evaluation, and summary assembly. No approval prompts between those steps.
- AutomaticValidate source contextQueued
Confirm the local case packet and verified source set.
- AutomaticMap verified evidenceQueued
Normalize the evidence types and preserve their source boundaries.
- AutomaticEvaluate enabled modulesQueued
Run each module contract and keep missing evidence visible.
- AutomaticAssemble final summaryQueued
Combine prepared outputs, evidence gaps, and hard stops in one review packet.
- Human · final onlyFinal human reviewQueued
Review the consolidated result once; confirm it or return it for revision.
Let the system handle the middle.
It checks the source packet, maps the evidence, evaluates every enabled module, and prepares one consolidated result. The human sees the complete picture instead of approving each internal transition.
- Surgeon metrics
- Biller metrics
- Developer metrics
- Automatic steps
- 4
- Intermediate approvals
- 0
- Final human reviews
- 1
Fictional case workspace
Test the module logic without an integration layer.
Switch cases, inspect required evidence, and see why a module can proceed or must stop.
A fictional ankle-hardware episode includes every required referral, coverage, documentation, authorization, denial, coordination, planning, and governance input. All eight modules are ready for staff review.
Referral intake
Turn a referral packet into a structured, exception-first intake record.
Document ingestion, referral triage, and missing-item chase
referral reason
referring provider
clinical note
imaging report
coverage record
- Structured referral summary
- Missing-document checklist
- Human intake queue item
FHIR DocumentReference + customer fax/document intake
- SMART interactive chart-context readImplemented
A read-only SMART chart-context flow is implemented and synthetic-tested; no customer EHR is registered, connected, or verified.
- Enterprise document repositoryConcept
An enterprise-document adapter boundary is documented; no customer repository is connected.
Intake staff confirms identity, destination, and clinical completeness.
No referral acceptance, rejection, or patient scheduling.
All eight modules are enabled in standalone mode. No integration is loaded and no external system was contacted.
Standalone boundary
The workflow stays entirely inside this demo.
No EHR, payer, PACS, messaging, clearinghouse, coding, or scheduling connector is loaded. The demo assesses fictional evidence and prepares local handoffs only.
- 0
Patient contactsNo SMS, call, or portal message was sent.
- 0
Payer actionsNo eligibility check, authorization, claim, or appeal was transmitted.
- 0
Clinical actionsNo imaging interpretation, plan, order, or disposition was generated.
How the workflow moves
Start once. Watch every step. Review the complete result.
- 01
Lifecycle coreFind the unresolved implant plan and cite the record.
- 02
Automatic evidence passValidate, normalize, and map the available evidence without approval prompts.
- 03
Automatic module passEvaluate each enabled workflow and consolidate every output or gap.
- 04
One final reviewConfirm the complete summary or return the run for revision.
Automation truth
Operations automation operating envelope
These three local engines normalize messy synthetic records, assess evidence readiness, and sequence preparation. They do not invoke a model, use customer data, learn online, or act on an external system.
Messy-source normalization rules
Deterministic messy-source normalization is implemented and synthetic-tested; ambiguity is quarantined rather than inferred away.
- Contract
- synorthopic.operations-source-normalization.v1
- Engine
- Repository deterministic code
- Identifier
- operations-source-normalization
- Current runtime
- Synthetic fixture
- Release decision
- local demo only
- Test dataset
- operations-messy-source-packet.v1
Quarantined records and conflicts remain visible for human reconciliation.
Inspect controls and operating envelope
- Case binding
- Verification state
- Alias map
- Duplicate rules
- Length and record limits
- Wrong case
- Unverified record
- Conflicting duplicate
- Unknown evidence type
- Inventing missing evidence
- Resolving clinical conflict
- Using wrong-case records
- Subgroups: not applicable
- Overrides: local test only
- Incidents: not established
- Rollback: Discard normalized output and review the original synthetic packet.
Operations module assessment rules
Eight deterministic evidence-readiness modules are implemented and synthetic-tested; all downstream decisions and actions remain human-owned.
- Contract
- synorthopic.operations-module-assessment.v1
- Engine
- Repository deterministic code
- Identifier
- orthopedic-operations-modules
- Current runtime
- Synthetic fixture
- Release decision
- local demo only
- Test dataset
- operations-messy-simulation.v1
The responsible operational user reviews each prepared output before any downstream action.
Inspect controls and operating envelope
- Known evidence types
- Fixed required-evidence maps
- Closed status enum
- Missing required evidence
- Disabled module
- Unsupported evidence type
- Clinical decision
- Final coding
- Coverage decision
- Imaging interpretation
- External write
- Subgroups: not applicable
- Overrides: local test only
- Incidents: not established
- Rollback: Show the verified source checklist without module readiness assessment.
Supervised operations run policy
A deterministic supervised-run policy is implemented for synthetic data: preparation is automatic, one final human review remains, and no external action occurs.
- Contract
- synorthopic.operations-supervised-run-bundle.v1
- Engine
- Repository deterministic code
- Identifier
- operations-supervised-run
- Current runtime
- Synthetic fixture
- Release decision
- local demo only
- Test dataset
- operations-supervised-run-synthetic.v1
One final human review is required after all automatic preparation stages complete.
Inspect controls and operating envelope
- Input contract compatibility
- Verified evidence only
- All eight modules present
- Fixed step order
- Contract mismatch
- Unverified evidence
- Missing module assessment
- Intermediate external action
- Automatic final approval
- EHR or payer write
- Subgroups: not applicable
- Overrides: local test only
- Incidents: not established
- Rollback: Bypass automation and review each module assessment directly.