Skip to main content

Data & Research

LOSPOR stores perioperative data for clinical documentation, audit, personal portfolio, and de-identified / pseudonymised research datasets. The dedicated lospor-api service owns the canonical PostgreSQL/API contract; web, mobile, and PWA clients map their payloads into the same field names and libraries before persistence.

What data does LOSPOR collect?

Preoperative data

  • Demographics: age, sex, height, weight, BMI, blood group, Rh factor.

  • Diagnosis: ICD-10 code with English and Bulgarian labels.

  • Planned procedure: procedure code/group/domain and description.

  • Comorbidities: ICD-10-coded tags with English/Bulgarian labels.

  • Medication history and medication allergy rows, including Medication.kind = CURRENT or ALLERGY.

  • Risk scores: ASA, RCRI, Apfel, STOP-BANG, and their component inputs.

    The component inputs are three-valued: yes, no, and not asked. A criterion nobody put to the patient is stored as null, not as a negative, and does not count toward the score — so a score is a lower bound when some of its criteria were never asked. Analyses that treat a null as a "no" are counting something the register did not measure; the component inputs are exported precisely so that distinction is available to you.

  • Airway assessment: Mallampati, mouth opening, thyromental distance, neck mobility, ULBT, Cormack-Lehane, difficult-airway history, and airway features.

  • Free-text clinical notes where needed: team notes, physical exam report, difficult-airway notes. These are character-limited and PII-checked server-side.

  • Vitals: BP, HR, SpO2, temperature, respiratory rate, including unable-to-obtain flags where available.

  • Laboratory results: canonical lab name, value, parsed numeric value, canonical unit, LOINC code, reference range, abnormal flag, source, and timestamp where available.

Intraoperative data

  • Timing: month/year, start time, end time, duration.
  • Techniques, position, airway devices/tools, ventilation modes, monitoring modalities.
  • Vascular access rows with site, size, unit, depth, lumens, and pre-existing flag.
  • Premedication rows for evening/morning entries.
  • Append-only event timeline: vitals, serum/peripheral glucose, bolus drugs, infusion starts/rate changes/stops, fluid starts/stops, inhalational agent starts/stops, fresh gas flow changes, and clinical events.
  • Fresh gas flow over time: FGF L/min, carrier gas, FiO2, calculated FiAir, and calculated FiN2O. FiO2 is clamped to 21-100%; O2-only is FiO2 100%.
  • Fluids, urine, blood products, complications, and event notes.

Postoperative data

  • Aldrete score components and total.
  • Recovery vitals: systolic BP, diastolic BP, heart rate, SpO2, temperature.
  • Pain NRS, PONV, disposition, handover checklist, complications, and notes.

What is not stored?

The following are intentionally never uploaded or stored:

  • Patient name.
  • Patient national ID / EGN.
  • Hospital file number or patient ID number.
  • Exact date of surgery; month/year and clinical timestamps are used instead.
  • Surgeon, anaesthesiologist, or nurse names as structured fields.
  • Free text that triggers the server-side PII detector.

The printable protocol leaves patient identity fields blank. Clinicians fill those fields by hand after printing if needed for the local paper record.

Canonical libraries

LOSPOR uses shared backend libraries rather than app-specific hardcoded lists.

LibrarySource of truthUsed for
ICD-10Icd10Code, Icd10Synonymdiagnoses and comorbidities
Labs/LOINCLabLoinc and canonical lab codeAI scan, manual labs, export
Drugs/ATC/INNAtc, Drug, option-library drug rowsmedication history, allergies, intraop drugs/infusions
App optionsOptionLibrarytechniques, airway, ventilation, monitoring, position, fluids, events, disposition, handover, numeric ranges
Athena/OMOP vocabularyOmopConcept, OmopVocabulary, relationships, ancestors, synonymslocal standard concept resolution
Concept mapConceptMapsource code/label preservation, mapping method/confidence, review state, and OMOP concept IDs where known

ICD-10 English and Bulgarian labels are metadata for the same ICD code. They are not duplicate clinical concepts.

Research data layers

LOSPOR keeps compatibility JSON/cache data for the apps, but research queries should use normalized rows where available.

Clinical dataSQL tableResearch columns
DiagnosesPreopDiagnosisICD code, labels, source vocabulary/code, OMOP concept ID if mapped
ProceduresPreopProcedurecode, group, domain, source mapping
ComorbiditiesComorbidityICD-10 code, labels, source mapping
LabsLabResultvalueNum, unitCanon, LOINC, ranges, abnormal flag, source mapping
Medications/allergiesMedicationkind, drugId, INN, ATC, dose, route, source mapping
Vascular accessVascularAccesssite, size, unit, depth, lumens, pre-existing flag
PremedicationPremedicationAdministrationphase, raw name, INN, ATC, dose, route
ComplicationsCaseComplicationsection, label, note, timestamp, source mapping
SelectionsCaseSelectionsection, category, value, source mapping
Intraop timelineCaseEventevent type, timestamp, typed vitals/gas/drug/fluid/agent columns, provenance
MissingnessClinicalFieldStatusfieldKey, presence, source, sourceVersion

CaseEvent is append-only. Edits supersede older rows and deletes tombstone rows, so the current chart can be projected from active rows while preserving history for audit.

Missingness and provenance

Research exports must distinguish blank data from negative data. ClinicalFieldStatus records whether key fields are:

  • PRESENT
  • ABSENT
  • UNKNOWN
  • NOT_APPLICABLE
  • NOT_DOCUMENTED

Normalized rows also carry source/provenance metadata such as user input, web/mobile source, AI scan, backfill, migration, or relational sync where available. Field-status coverage is intentionally broad so normalized rows can serve as the research/export authority while UI JSON remains a compatibility cache.

OMOP export

The OMOP export is an OMOP CDM v5.4-oriented research export. It now reads normalized rows and active event rows instead of raw legacy blobs.

The export includes:

  • care site as its own table, referenced by visit occurrence through care_site_id
  • person and observation period, the CDM root tables
  • visit occurrence
  • condition occurrence from diagnoses and comorbidities
  • procedure occurrence from every planned procedure, the anaesthesia technique, vascular access, and the act of placing an instrumented airway
  • measurement rows for preop/postop vitals, labs, intraop vitals, glucose, and gas settings, carrying value_source_value for results the laboratory reported as text and range_low / range_high for the reference range the result was judged against
  • drug exposure rows for medications, bolus drugs, premedication, agents, and infusions, with drug_exposure_end_date paired from stop events for continuous administrations
  • observations for ASA, scores, selections, complications, handover, disposition, the preoperative history and airway examination, airway devices and ventilation, drug allergies, and other app-local concepts

Clinical yes/no questions are exported for a recorded "no" as well as a "yes". No row means the question was never asked, which is a different claim about a patient than a negative finding.

An allergy is exported as an observation, never as a drug exposure. A substance a patient reacts to is not one they were given.

Known OMOP concept IDs are stored/exported where confidently mapped. Filtered Athena CSV import can enrich LOINC, ICD-10, and ATC mappings through local OMOP vocabulary tables without storing the full Athena bundle. Otherwise LOSPOR exports source vocabulary, source code, and source labels with an explicit source-only/unmapped status. Fake OMOP IDs are not used.

Each export includes a manifest with app/schema version, concept-map version, row counts, mapping summary, de-identification notes, and quality warnings. Governed export manifest v2 also freezes the parent clinical/event/relational revisions and every section revision for each finalized case. App exports warn rather than block when source-only mappings, missing field-status rows, exact timestamps, or institution linkage are present. Downloadable research artifacts are retained for 30 days by default; their checksum, row count, source version, and audit history remain after the file expires.

An OMOP request that matches more than 5000 cases is rejected with HTTP 422 and reports the matching count, limit, and complete: false. LOSPOR never returns the first 5000 cases as if they were the full research dataset. Narrow the export or use the future resumable institution-to-datacentre export workflow for larger cohorts.

De-identification / pseudonymisation

Each case receives a generated case code such as 2026-0001. This is the visible case-level pseudonym used in the UI and exports.

Internally, LOSPOR stores operational linkage needed for access control, audit, governance, and research quality: user ID, institution ID, timestamps, role/audit information, and finalisation snapshots. These are not patient identifiers, but they mean LOSPOR data should be described as de-identified / pseudonymised, not fully anonymised.

Data quality tools

The backend includes tooling for release and research checks:

  • scripts/seed-vocabularies.ts seeds ICD-10, ICD-10CM synonyms, ATC, and Drug rows.
  • scripts/seed-athena-vocabularies.ts --filtered-lospor imports only LOSPOR-needed local Athena/OMOP rows for vocabulary-backed mapping.
  • scripts/seed-lab-loinc.ts seeds the canonical lab/LOINC catalogue.
  • scripts/seed-option-library.ts seeds shared app option libraries.
  • scripts/seed-concept-maps.ts seeds local bilingual concept maps and enriches them from Athena when available.
  • scripts/backfill-relational.ts rebuilds normalized rows and typed event columns from existing cases.
  • scripts/data-quality-report.ts reports relational drift, unmapped/source-only concepts, invalid ranges, impossible timestamps, and missing key research fields.
  • scripts/wipe-dev-clinical-data.ts can wipe dev clinical data while preserving accounts, institutions, vocabularies, option libraries, and configuration.

Research access

The standalone LOSPOR Database Research Browser provides governed cohort queries, comparisons, pseudonymous case inspection, data-quality review, benchmarks, saved cohorts, and complete audited exports. It uses read-only /v1/research/* API projections and never connects to operational tables directly. See Research Browser.

Citing LOSPOR

If you use LOSPOR data in a publication, cite:

LOSPOR - Large Open Source Perioperative Register. Available at https://lospor.org. Licensed under AGPL-3.0.