Healthcare data for ambulatory surgery centers

Fictix includes an opt-in clinical content pack for ambulatory surgery centers (ASCs). It creates a coherent synthetic facility, procedure schedule, safety-event history, and dictated incident reports for testing healthcare workflows, extraction pipelines, and evaluation harnesses.

The ASC pack is synthetic test data, not a clinical system. It contains no real patients, patient names, dates of birth, medical-record numbers, or data from healthcare systems. Do not use it for patient care, clinical decision-making, or as a compliance certification.

Create an ASC company

In the Console, select Ambulatory Surgery Center when generating a company.

For an approved server-to-server demo-job integration, use the canonical industry value in company.industry:

{
  "company": {
    "name": "Lakeside Surgery Center",
    "domain": "lakeside-surgery.example",
    "industry": "asc_surgical",
    "employee_count": 48,
    "selected_services": ["qbo", "gusto"]
  },
  "generation": {
    "employees": 48,
    "months_of_history": 18,
    "quality_preset": "realistic"
  }
}

asc_surgical is an industry profile, not a standard financial archetype. Set company.industry rather than relying on company.archetype for this vertical. The pack is additive: non-ASC companies retain the ordinary business dataset and expose no clinical records.

Clinical entity families

ASC companies add four canonical entity families. They use the same paged entity and export routes as the rest of the dataset.

patient_ref is an opaque synthetic reference such as PT-00042; it is never a real patient identifier. Clinical records have deterministic references: rooms link to cases, cases can link to incidents, and dictation scripts link to their incident.

Read a runtime page with the project API key:

curl -sS \
  "$FICTIX_API_ORIGIN/api/v1/orgs/$FICTIX_PROJECT_SLUG/data/clinical_incidents?limit=100&offset=0" \
  -H "X-API-Key: $FICTIX_PROJECT_API_KEY" | jq

Approved partners can use the normalized equivalent:

GET /api/v1/demo-jobs/{job_ref}/entities/clinical_incidents
GET /api/v1/demo-jobs/{job_ref}/entities/dictation_scripts/export?format=json

Check dataset_summary.record_counts or the public entity catalog before loading. A zero count means the selected company is not an ASC company, or no records of that family were generated.

Ground truth for extraction and evaluation

Each dictation_scripts record is rendered from its structured incident, so its labels object is the extraction answer key by construction. This makes it useful for testing speech-to-structure, incident triage, and safety/compliance workflows without having to infer a hidden answer from prose.

ASC scenario templates can add harder known conditions to the scenario manifest:

• ambiguous-time-reference
• duplicate-staff-name
• unstated-harm-level
• mid-sentence-correction
• late-report-gap

For those scenarios, evidence.expected_extraction is the graded answer-key convention. Preserve the scenario manifest with your test result, and use the answer key only in your evaluation pipeline—not in a user-facing workflow.

Load order and exports

Load the usual financial entities first. For clinical records, use this order:

1. operating_rooms
2. surgical_cases
3. clinical_incidents
4. dictation_scripts

Use JSON when your integration needs the nested labels, factors, or staff references. CSV is useful for flat export workflows, but it does not replace the full structured evaluation payload.

Next: Entities And Exports, Entities And Lineage, and Simulation, Scenarios & Events.