Introduction

Test phase (public)

Obscyro is in test phase only: no uptime or accuracy SLA. Some endpoints are more likely to show bugs, slow responses, or schema changes—especially:

• POST /v1/normalize, POST /v1/normalize-batch, POST /v1/disambiguate, POST /v1/translate
• GET /v1/concepts/{code}/ancestors, GET /v1/concepts/{code}/descendants

Do not use responses for clinical decisions without independent verification. The same notice appears in the site banner and in the signed-in console overview.

What Obscyro is

Obscyro connects the data a health network already publishes — facility registries, capacity at permit, hourly emergency censuses, epidemiological series — into a single ontology, runs that ontology as a digital twin under an observed load, and compares what could be done about the result.

There are two halves and they are in series. Interoperability is the work of making files that were never meant to sit side by side comparable at all: different encodings, different vocabularies, different calendars. Operational optimisation is what that makes possible: putting the modelled network under pressure and ranking the responses to it.

The second is worth nothing without the first. A model fed a column whose day and month are the wrong way round will run, produce a ranking, and recommend a policy — which is why the platform reads the values in a file rather than trusting the schema that describes them.

What is in it

• Sources and syncs. REST endpoints, files and streams on a schedule, with encodings and delimiters handled inside the platform rather than in a spreadsheet before upload.
• Pipelines. A visual graph — filter, select, derive, cast, expand, join — turning rows into the objects a network actually has.
• An ontology. Object types, link types, properties, value sets and hierarchies, with lineage from any figure back to the file it came from.
• A digital twin. The modelled network put under an observed load: beds fill, patients wait, transfers move. Deterministic, so the same question always returns the same answer.
• Response comparison. Two protocols side by side on deaths, waiting and cost, ranked by Pareto dominance rather than by a weighted score.
• Dashboards. Charts offered from what the columns actually hold, and a card that says how many rows it read and how many carried no measure.

The terminology API

The SNOMED endpoints predate the platform and are still live. They are now one layer of it rather than the product:

• Concept lookup against the SNOMED CT International Edition (Feb 2026 release).
• Free-text normalization (exact, full-text, and trigram fuzzy match) into SNOMED candidates.
• Hierarchy traversal: parents, children, ancestors and descendants via recursive is-a relationships.
• Cross-terminology mappings: SNOMED ↔ ICD-10 (extended map), ICD-O, CTV3.
• Context-aware disambiguation when an abbreviation maps to several concepts.

Inside the platform, coding runs as a node in a pipeline rather than as a separate migration. Over HTTP it stays exactly as documented in the Core API section.

How it fits

Most of this is reached from the interface rather than from code. The API matters at two points:

1. Ingestion — normalize incoming free-text or partner-coded data on the way into your own database.
2. Analytics — expand concept hierarchies before running cohort queries.

Reading this documentation

• The Core API section is your reference manual — one page per endpoint, with request/response schemas and copy-paste examples in cURL, Node.js, and Python.
• Standards explains how Obscyro models each terminology so you know what to expect in responses.
• Resources lists SDKs (coming soon), our changelog, and the /v1/health readiness probe. A public status page is planned.

When you are ready, jump to the Quickstart for a 30-second integration.