symprot

About

This app helps inspect and document Siemens CT/MRT exam protocols.

Why?

I have been working with Siemens (now healthineers) CT and MRI machines for many years now. When it comes to getting info about examination protocols out of these machines, it's been long and hard work all the time.

There are good reasons to get those protocols documented:

• documenting standard protocols and sync them between machines (if you have more than 1 of course)
• get a printout for SOPs
• describe your parameters when doing scientific studies
• compare and enhance your exam protocols

The Problem: Siemens machines i know can export their exam protocols as database files in a proprietary format which seem unreadable to me. There is however a way to "print" protocols in PDF or (newer machines) xml format. These printouts contain all possible settings and parameters for every single step and sequence and are therefor quite large and in esence useless for above tasks.

The Solution: Symprot

• reads those printouts
• tries to extract the protocols and parameters you need to know
• displays the results in different formatting according to your needs

You can edit the protocol parameters to be shown. You can switch output formats If you are familiar with PHP programming, you can easily

• add new converters for Phillips, GE, Samsung or Toshiba (if they do printouts as Siemens does)
• add output formatters as you like (JSON, XML, braille, you name it)

Recent enhancements:

• Stable per-device (Geraet) sorting for Parameters with move Top/Up/Down/Bottom actions that keep a contiguous sort_position. Lists now sort predictably, also when filtered by modality (Geraet).
• Visual feedback when moving a parameter: after a move, the target row is highlighted and smoothly scrolled into view.
• Content Security Policy (CSP): inline JS/CSS disabled by default; per-request nonces are used for required inline blocks (e.g., importmap). The highlight assets were moved to external files and are loaded without 'unsafe-inline'. You can toggle CSP via the APP_CSP_ENABLED env var (see README Security section).

Setup

(i assume linux and a terminal) :

prerequisites:

1. A webserver (e.g. Apache, nginx), configured and ready - i assume you have that up and running :)
2. PHP 8.2+ with modules PDO, Ctype, iconv, PCRE, Session, SimpleXML, and Tokenizer installed
3. sqlite as database (e.g. for Ubuntu `sudo apt-get install sqlite3, php-sqlite3)
4. [composer] (https://getcomposer.org/download/)

in terminal:

clone repository: git clone https://github.com/medmen/symprot.git - this will create a folder "symprot" in your working directory

cd symprot

composer install - this will install the symfony framework and and several modules used in this app

initialize the Database:

php bin/console doctrine:database:create - this will create the database file (the app uses sqlite as database). if the command fails with an error like "The database driver is not supported by the Doctrine DBAL library", you need to install the sqlite driver for php, e.g. for Ubuntu sudo apt-get install php-sqlite3

php bin/console doctrine:migrations:migrate - this will create the database tables and relations, but will not populate the database with any data if the command fails, you can try to run php bin/console doctrine:schema:update --force instead, which will also create the tables, but without any migrations.

php bin/console asset-map:compile - will pack, arrange and order all required javascript, CSS and Image files for highest performance in live environment

optional: populate the Database:

php bin/console seed:load - this will load some example data into the database, so you can test the app

Security

Symprot is a web-app, you need a webserver to run it. Web things are by design accessible from "everywhere", so security problems may lead to data loss, malfunction and potentially infecting your webserver with malware. Symprot was built to work, security is not a primary goal! But it is build on a solid foundation (Symfony framework) and comes with a CSP, so basic security measures are taken.

CSP on/off:

• By default, CSP is enabled. To disable it (e.g., for local debugging), set APP_CSP_ENABLED=0 in your environment or in .env.local.
• To explicitly enable it, set APP_CSP_ENABLED=1.
• After changing env vars in dev, clear cache or reload PHP FPM if needed.

If you happen to find an issue, please file a bug report (ideally with a bugfix pull request).

Help?

This is a one-man hobby project, please don't expect professional support. If things don't work, feel free to file a report at https://github.com/medmen/symprot/issues I would love to see enhancements and pull requests too, feel free to contribute :)

Live processing status (ProtocolController)

Symprot now logs the progress of protocol processing (converter and formatter) to a per-request status file and shows a live-updating status panel in the Protocol view.

• What gets logged

  • Milestones: request initialization, upload located, converter chosen/completed, formatter chosen/completed, success/failure, and relevant errors.
  • Converter/Formatter strategy classes selected for the current run.

• Where logs are stored

  • Files are written under var/status/{token}.log for the duration of the request.
  • The log begins with a [START] line and ends with [END OK] or [END FAIL].

• How the UI updates (AJAX polling)

  • The controller exposes a JSON endpoint at GET /status/{token} (route name status_poll).
  • The Protocol page renders a status container with data-url and data-token attributes.
  • A separate, CSP-compliant JavaScript file public/js/protocol-status.js polls the endpoint every second and renders the lines into a <pre>.

• CSP compliance

  • No inline scripts are used for the polling logic; the script is served as an external file.
  • The template tags the script with a per-request nonce generated by the CSP subscriber.
  • Works with CSP enabled (default) without requiring unsafe-inline.

• Relevant files

  • Backend
    • src/Controller/ProtocolController.php: emits progress, provides status_poll endpoint, and passes the status token/URL to the view.
    • src/Service/StatusLogger.php: small utility that manages status files: init/append/complete/read.
    • src/Strategy/ConverterContext.php and src/Formatter/FormatterContext.php: emit additional progress lines for selected strategies.
  • Frontend
    • templates/protocol/index.html.twig: includes a status panel and references the external JS file.
    • public/js/protocol-status.js: polls the backend and updates the UI.

• How to test

  1. Process a file via the Protocol UI so that ProtocolController::index runs.
  2. Watch the “Status” panel updating lines while the converter/formatter run.
  3. Inspect var/status/*.log to see raw progress entries. The final line should be [END OK] or [END FAIL].

• Notes

  • The status token is stored in the session and validated by the polling endpoint to prevent cross-user leakage.
  • Status files are created lazily; the directory var/status is created automatically if missing.