Skip to main content

open-syndrome-python

PyPI - Version Test

Installation

You can install it from PyPI or Docker. By default, the conversion features use Ollama running locally. Cloud providers (OpenAI, Anthropic, Mistral, DeepSeek, Gemini) are also supported and require only an API key.

From PyPi, install the package with pip install opensyndrome. Then run it with opensyndrome --help.

From Docker, you can run the following command to build the image, tagged opensyndrome:

docker build -t opensyndrome .

Run the container interactively, removing it when it exits

docker run --rm -it opensyndrome

To read a .env file, mount it:

docker run --rm -it \
  -v "$(pwd)/.env:/app/.env:ro" \
  opensyndrome

To name the container and keep it around:

docker run --name opensyndrome-cli -it opensyndrome

Usage

First, download the schema and definitions in order to work with the CLI locally.

opensyndrome download schema
opensyndrome download definitions

The files will be placed in the folder .open_syndrome in $HOME.

Using your own local definitions

The definitions published by the Open Syndrome Initiative (the community definitions) always live in ~/.open_syndrome/v1/definitions. To add definitions of your own that are not published on GitHub, point OPENSYNDROME_DEFINITIONS_DIR to a directory you maintain; it is never written to by the CLI.

OPENSYNDROME_DEFINITIONS_DIR=./my-definitions

To ignore the community definitions altogether and use only yours, also set OPENSYNDROME_LOCAL_DEFINITIONS_ONLY=1 (true, yes and on also work). Nothing is downloaded in that mode, not even with --force.

From Python, opensyndrome.artifacts.get_definition_dirs() returns the directories to read, in order:

OPENSYNDROME_DEFINITIONS_DIR OPENSYNDROME_LOCAL_DEFINITIONS_ONLY Result
unset unset [community]
set unset [community, local]
set set [local]
unset set error

It also accepts local_dir and local_only keyword arguments that override the environment variables. The former get_definition_dir() still returns the community directory only, ignoring these variables; it emits a DeprecationWarning and will be removed in a future version.

Providers and configuration

The provider and model can be set via environment variables so you don't have to pass them on every command:

OPENSYNDROME_PROVIDER=ollama   # ollama (default), openai, anthropic, mistral, deepseek, gemini
OPENSYNDROME_MODEL=mistral     # overrides the provider's default model

Copy .env.example to .env and fill in the relevant values:

Provider Required env var Default model
ollama — (runs locally) mistral
openai OPENAI_API_KEY gpt-4o
anthropic ANTHROPIC_API_KEY claude-3-haiku-20240307
mistral MISTRAL_API_KEY mistral-large-latest
deepseek DEEPSEEK_API_KEY deepseek-chat
gemini GEMINI_API_KEY gemini-1.5-flash

For Ollama, the model must be pulled before use: ollama pull mistral. You can also override the Ollama base URL with OLLAMA_BASE_URL (default: http://localhost:11434).

Ollama models tested: llama3.2, mistral, deepseek-r1. Known to not work well with structured output: qwen2.5-coder.

Convert a human-readable syndrome definition to a machine-readable JSON

If you do not pass -hr or -hf, an editor will open for you to enter the definition.

# see some examples from ECDC: https://www.ecdc.europa.eu/en/all-topics/eu-case-definitions

# pass the definition as inline text
opensyndrome convert -hr "Any person with pneumonia"

# pass the definition from a TXT file
opensyndrome convert -hf definition.txt

# use a specific provider and model
opensyndrome convert -hr "Any person with pneumonia" --provider openai --model gpt-4o

# to have the JSON translated to a specific language and edit it just after conversion
opensyndrome convert --language "Português do Brasil" --edit

# include a validation step after conversion
opensyndrome convert --validate

Enrich ontology IDs on a JSON definition

The enrich command populates ontology_id fields on criteria nodes and sets the @context to the OpenSyndrome JSON-LD context URL. It queries EBI OLS4 by default, or text2term as an alternative mapper.

# enrich an existing JSON definition (uses OLS4 by default)
opensyndrome enrich definition.json

# use text2term instead (requires: pip install opensyndrome[text2term])
opensyndrome enrich definition.json --mapper text2term

# review and adjust the result in an editor before printing
opensyndrome enrich definition.json --edit

# enrich and validate in one step
opensyndrome enrich definition.json --validate

You can also enrich directly after conversion:

opensyndrome convert -hr "Any person with fever and rash" --enrich-ontology
opensyndrome convert -hr "Any person with fever and rash" --enrich-ontology --mapper text2term

Convert a machine-readable JSON syndrome definition to a human-readable format

opensyndrome humanize <path-to-json-file>
opensyndrome humanize <path-to-json-file> --provider anthropic
opensyndrome humanize <path-to-json-file> --model mistral-large-latest --language "Português do Brasil"

Validate a machine-readable JSON syndrome definition

opensyndrome validate <path-to-json-file>

Development

To get started with development, you need to have uv installed.

Install dependencies

uv sync

To include the optional text2term mapper (and its bioregistry dependency) so the full test suite runs without skips:

uv sync --all-extras

Generate Ollama-compatible JSON

You only need to do this if you are a maintainer adding a new OSI schema or updating an existing one.

Since Ollama requires a specific, more simple, JSON format, we need to generate an Ollama-compatible schema. To do this, we use datamodel-code-generator to generate a Pydantic schema. Run the following command to update it:

make ollama_schema

It will create a schema.py file in the root of the project. Be careful when editing this file manually.

Citing & Authors

If you find this repository helpful, feel free to cite our publication: The Open Syndrome Definition

@misc{ferreira2025opensyndromedefinition,
      title={The Open Syndrome Definition},
      author={Ana Paula Gomes Ferreira and Aleksandar Anžel and Izabel Oliva Marcilio de Souza and Helen Hughes and Alex J Elliot and Jude Dzevela Kong and Madlen Schranz and Alexander Ullrich and Georges Hattab},
      year={2025},
      eprint={2509.25434},
      archivePrefix={arXiv},
      primaryClass={cs.AI},
      url={https://arxiv.org/abs/2509.25434},
}

Metadata

Release files for opensyndrome 0.5.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for opensyndrome 0.5.0
File Size Uploaded
opensyndrome-0.5.0.tar.gz 202.2 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for opensyndrome 0.5.0
File Interpreter ABI Platform
opensyndrome-0.5.0-py3-none-any.whl Python 3 none any Details

Total release size: 232.0 kB

Release files / opensyndrome-0.5.0.tar.gz

Download URL opensyndrome-0.5.0.tar.gz
Size 202.2 kB
Tags Source
SHA-256 checksum
How to use checksums
64cf5d3d1dcef9571697e7a5e44698c78facd0c5b00a5c94ba35f4782f42493f
BLAKE2b-256 checksum
How to use checksums
89741a114f8357d9638b96d0d099614b7cf99b4711afae96a12e6ad28aa2cb69
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 2, 2026.

Transparency log

Release files / opensyndrome-0.5.0-py3-none-any.whl

Download URL opensyndrome-0.5.0-py3-none-any.whl
Size 29.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
99e8c021002cfbe57a01c9e94ceae11949181811d0e4ebda10fc8668e2ca4a08
BLAKE2b-256 checksum
How to use checksums
fa167f32f6629a561e170c8f64e717e61d2fa27b9b77c978e0406eb86f45fb7e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 2, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.5.0 This release

2 release files

0.4.0

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.2

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page