How it works

Why trust an act or a claim from HealthOS Semantics? You need not — you can verify it. This page shows the path from document to claim line, and what is verifiable at each step of it.

The document’s path through the pipeline

The document's path through the pipeline: three sources → recognition and binding → decision panels → outputs.
  1. Three intake channels — the clinical system, the web workspace, visit recordings — converge into one pipeline
  2. The pipeline recognizes text and speech, extracts candidate terms and binds them to the governed knowledge graph
  3. The material goes to the decision panels, where a human authorizes anything disputed
  4. The result — structured medical documents and the act and registry for the payer, where every line carries its lineage
The document's path through the pipelineThree intake forms — the clinical system, the web workspace and visit recordings — converge into the pipeline: recognition, term extraction, binding to the governed knowledge graph. The material then goes to the decision panels, where a human authorizes it, and from there into structured medical documents and into the act and registry for the payer.INPUTClinical systemevent integrationWeb workspaceuploads and batchesVisit recordingsin-office · telehealthdictation · fieldPIPELINERecognitiontext and speechExtractioncandidate termsBindingto the knowledge graphGoverned knowledge graphvocabulary · versions · authorsDecision panelsbinding · act · dispute · reconciliationdisputed items go to a human for authorizationStructured documentsHL7 FHIR exchangestructure instead of textAct and registryfor the payer: every linewith its lineage

Humans take part in one place — the decision panels; the rest the pipeline records automatically, with a version, an author and a digest at every step.

Input: documents and visits

Five document intake forms — one pipeline; the intake form changes neither the binding statuses nor the lineage of the result.

  1. Single upload via the web workspace: PDF, DOCX or a scan; scans go through recognition, and recognition quality is a measured input metric.
  2. Batch upload: an archive of documents for a period — the typical billing-office mode when preparing a registry.
  3. Event-driven integration with the clinic’s information system: a document is signed — the pipeline receives it immediately.
  4. Agent channel: documents and binding requests from documentation systems over the standard profile.
  5. Retrospective archive migration: one-off processing of historical documents for structuring and registry completeness.

A separate input class is the physician visit itself. Visit recordings take the common pipeline path — recognition, term extraction, binding:

Visit form How the document enters the pipeline
In-office visit ambient recording → speaker separation → draft note
Telemedicine consultation channel recording; speakers are already separated by channel
Dictation after the visit the physician dictates a summary; recognition → pipeline
Home and field visits mobile recording with deferred transfer into the protected contour
Tumor boards, rounds multi-party discussion minutes

One invariant holds across all forms: patient data and audio never leave the perimeter of the medical organization or the HealthOS cloud.

The chain of evidence

The transformation chain: document → fragment → term → descriptor → code → tariff → claim.

A document or visit recording is turned into a claim line step by step:

  1. the grounding fragment is located in the text
  2. a term is extracted from the fragment
  3. the term is bound to a descriptor in the graph
  4. the descriptor receives a code
  5. the code is assigned a tariff
  6. the tariff becomes a line on the claim.
The seven-link transformation chain The diagram shows the path of a document or visit recording through seven links: document, the grounding fragment in the text, a term extracted from the fragment, a descriptor in the graph, a code, a tariff and the claim line itself. Each link has a version, an author and a cryptographic digest. Documentor visit recording Fragmentthe grounding text Termextracted from fragment Descriptorversion · author CodeICD-10 · services Tariffservice price Claimact and registry line

Every link carries a version, an author and a cryptographic digest; the audit log is immutable and the evidence is available on request. Checking a claim line means opening it, in one click, into its full chain.

The decision core: rules and people

At the input — recognition tasks of varying difficulty; beyond that, rules and people decide.

The machine works at the pipeline input and does one job — deciphering the sources, with varying difficulty:

  1. printed documents and scans — low difficulty
  2. live visit speech with speaker separation — high difficulty, the hardest part of the pipeline
  3. extracting candidate terms — medium difficulty
  4. semantic search and ranking — medium difficulty
The decision core: rules and peopleAt the top, four recognition tasks at the pipeline input with their difficulty: printed documents and scans — low, live visit speech with speaker separation — high, candidate-term extraction and semantic search — medium. Below the boundary is the decision core: deterministic rules with a version and human authorization. No trainable models sit in the decision loop.AT THE INPUT — RECOGNITIONPrinted documents and scanslowLive visit speech with speaker separationhighExtracting candidate termsmediumSemantic search and rankingmediumbeyond this line: rules and peopleDECISION COREDeterministic rulesversion · author · digestone document — one resultthe rule can be producedHuman authorizationdisputed items are blockedand go to a humanrecorded with its authorNo trainable models sit in the decision loop.Client data is not used to train third-party models.

Live visit speech with speaker separation is hard: spontaneous speech, professional shorthand, overlapping remarks, room noise; at a tumour board speakers are many and roles shift. Telehealth is simpler — participants are already separated by channel.

Assigning the code and the tariff is not delegated to the machine. The decision core is deterministic rules and people: behind a conclusion stands a rule with a version, so the same document yields the same result, while anything disputed is blocked and goes to a human for authorization. The rules are executed by a computational pipeline: they are not interpreted on the fly but run as a program — which is where the repeatability of the result comes from. No trainable models sit in the decision loop, and client data is not used to train third-party models.

The hardest task in the system is solved not by an algorithm but by architecture: not “guess correctly” but “reliably recognise that there is no certainty”.

Binding statuses

Binding is two-staged: exact match against a descriptor first, ranked semantic candidates when that fails. The result always carries an explicit status:

Status Meaning Who decides
Exact match matches a descriptor — the binding is reliable automation; needs no attention
Semantic candidate ranked candidates with similarity scores a human — authorizes the choice between candidates
Ambiguous several equally strong candidates a human
No match the term is not in the vocabulary a human; the term becomes a vocabulary-extension candidate
Stale index the search index lags the vocabulary binding is blocked until reindexing

Disputed statuses are never silently swallowed: they queue for human authorization. Queue growth is a signal to improve vocabulary coverage, not to rush operators.

The dual-document contract

Medical and economic documents are derived from the same set of authorized terms. One visit event produces the clinical note — into the clinic’s information system — and the personified service record — into the accounting system, so a mismatch between “what the note says” and “what was billed” is impossible by construction rather than detected by inspection. The contract covers what passed through the pipeline: a service entered into the accounting system by hand, bypassing it, is not protected by the contract — such lines are worked on the act panel.

Outputs

Want to see the chain on your own document?

10-minute demo
HealthOS Semantics is not a medical device and is not intended for diagnosing conditions or selecting treatment. All decisions are made by authorized professionals.