One shared episodeEvery enabled workflow starts from the same reviewed implant record.
Synorthopic · integrated operations demo
One implant episode.
Every operational step in view.
Start one supervised run and let the case move through intake, benefits, documentation, authorization, denial recovery, coordination, planning, and governance. The system prepares the work automatically, then stops once for final review.
COREImplant lifecycle intelligenceEvidence · automatic preparation · final human review
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.
Connection boundary
Every live port is simulated 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.
AccessCore
Workforce identity
Simulated onlyMaps 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
Clinical sourceCore
EHR clinical record
Simulated onlyReads 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
Evidence sourceCore
Document content
Simulated onlyRetrieves 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
Reference dataCore
Implant and coding providers
Simulated onlyKeeps 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
ImagingCore
PACS and imaging
Simulated onlyPackages 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
Revenue accessCore
Payer and clearinghouse
Simulated onlySeparates 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
Loop closureCore
Scheduling and messaging
Simulated onlyCreates 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
Runtime controlCore
Private data, keys, and audit
Simulated onlyProvides 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.
Current activityReady to start
Idle0 / 4 automatic steps0%
- AutomaticValidate source contextQueued
Confirm the case binding and authorized read-only 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.
One run · one review
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.
Final packet includes
- Surgeon metrics
- Biller metrics
- Developer metrics
- Automatic steps
- 4
- Intermediate approvals
- 0
- Final human reviews
- 1
This demonstration processes fictional evidence locally. It does not contact an EHR, payer, patient, PACS, or coding system.
Fictional case workspace
See the full episode without losing module boundaries.
Switch cases, inspect required evidence, and see why a module can proceed or must stop.
Service lineTrauma · lower extremity
HardwareSyndesmotic screw construct
Lifecycle statehuman confirmed removal plan
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.
Review ready8
Evidence gaps0
Disabled0
Demo connectors8
Front door
Review readyReferral intake
Turn a referral packet into a structured, exception-first intake record.
Workflow covered
Document ingestion, referral triage, and missing-item chase
Required evidence
referral reason
referring provider
clinical note
imaging report
coverage record
Prepared outputs
- Structured referral summary
- Missing-document checklist
- Human intake queue item
Adapter boundary
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.
Human gate
Intake staff confirms identity, destination, and clinical completeness.
Hard stop
No referral acceptance, rejection, or patient scheduling.
All eight modules and eight fictional connector slots are enabled. No real EHR, payer, patient, or planning system was contacted.
Practice integration
Connect the same modules to the practice EHR.
All connector slots are switched on in this fictional demo. The registration plan uses only the FHIR resources and SMART scopes required by the modules currently enabled.
AuthorizationSMART Backend Servicesprivate_key_jwt · customer-held key
Enabled modules8Scopes are derived only from these modules
FHIR read surface15R4 read/search capability checked at startup
Approved write surfaceTask onlyNo autonomous EHR write is permitted
Demo connection mode
The packet contains module IDs, resource types, scopes, and adapter slots—never credentials, patient IDs, or source text.
What a real practice supplies
- 01
Register the SMART clientSupply the tenant FHIR base, assigned client ID, redirect or JWKS, and customer-held key.
- 02
Grant exact module scopesApprove the generated 16-scope set; disabled modules request nothing.
- 03
Load tenant mappingsMap local documents, codes, queues, owners, and consent semantics to normalized evidence.
- 04
Connect supporting servicesProvide the selected X12, clearinghouse, DICOMweb, messaging, coding, and governance adapters.
- 05
Pass the canariesRun capability negotiation, audit verification, positive-control reads, and a representative pilot before activation.
ModuleEHR read surfaceExternal plug-inActivation
Front doorReferral intake
ServiceRequest · DocumentReference · DiagnosticReport · Coverage
document intake
Demo enabledPatient accessEligibility & benefits
Coverage · CoverageEligibilityResponse
eligibility 270 271
Demo enabledClinical administrationDocumentation & coding
ServiceRequest · DocumentReference · Condition · Procedure · Device · DeviceUseStatement
spinecpt private
Demo enabledPatient accessAuthorization evidence
ServiceRequest · Condition · DiagnosticReport · DocumentReference · Device · DeviceUseStatement · Coverage
authorization network
Demo enabledRevenue cycleDenial recovery
Claim · ExplanationOfBenefit · DocumentReference · DiagnosticReport
claim status 276 277
Demo enabledLoop closurePatient coordination
Patient · ServiceRequest · Consent · Appointment · Task
patient engagement
Demo enabledOrthopaedic planningSurgical-planning handoff
ImagingStudy · DiagnosticReport · DocumentReference · ServiceRequest · Device · DeviceUseStatement
dicomweb planning
Demo enabledSafety systemRuntime governance
Provenance · AuditEvent
governance telemetry
Demo enabledFully enabled here does not mean connected to a real chart.
Every module, FHIR resource set, external connector slot, and the human-only Task path is visible in this demonstration. A real deployment still requires the practice’s registration, credentials, local mappings, validation, and approvals.
Demo boundary
Everything is visible. Nothing reaches a live chart.
The connector plan shows how a practice could register each module, but voice calls, payer submissions, patient messaging, image planning, and EHR writes still require credentials, validation, and an accountable human.
- 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.
Generative boundaries0Untrusted proposal paths
Deterministic engines3Extractors, verifiers, rules, and policies
Enabled model calls0Public release truth
Customer data enabled0Requires customer proof
External actions0Production authorization required
Online learning0Prohibited by current policy
Deterministic extractorImplemented
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
Human gate
Quarantined records and conflicts remain visible for human reconciliation.
Inspect controls and operating envelope
Deterministic checks
- Case binding
- Verification state
- Alias map
- Duplicate rules
- Length and record limits
Abstains when
- Wrong case
- Unverified record
- Conflicting duplicate
- Unknown evidence type
Prohibited actions
- Inventing missing evidence
- Resolving clinical conflict
- Using wrong-case records
Evaluation state
- Subgroups: not applicable
- Overrides: local test only
- Incidents: not established
- Rollback: Discard normalized output and review the original synthetic packet.
Deterministic rulesetImplemented
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
Human gate
The responsible operational user reviews each prepared output before any downstream action.
Inspect controls and operating envelope
Deterministic checks
- Known evidence types
- Fixed required-evidence maps
- Closed status enum
Abstains when
- Missing required evidence
- Disabled module
- Unsupported evidence type
Prohibited actions
- Clinical decision
- Final coding
- Coverage decision
- Imaging interpretation
- External write
Evaluation state
- Subgroups: not applicable
- Overrides: local test only
- Incidents: not established
- Rollback: Show the verified source checklist without module readiness assessment.
Orchestration policyImplemented
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
Human gate
One final human review is required after all automatic preparation stages complete.
Inspect controls and operating envelope
Deterministic checks
- Input contract compatibility
- Verified evidence only
- All eight modules present
- Fixed step order
Abstains when
- Contract mismatch
- Unverified evidence
- Missing module assessment
Prohibited actions
- Intermediate external action
- Automatic final approval
- EHR or payer write
Evaluation state
- Subgroups: not applicable
- Overrides: local test only
- Incidents: not established
- Rollback: Bypass automation and review each module assessment directly.