** Still in Alpha trials **

Usage no npm install needed!

<script type="module">
  import flynotesCarestreamServerHotfixConnectSql from 'https://cdn.skypack.dev/@flynotes/carestream-server-hotfix-connect-sql';


Carestream Server

** Still in Alpha trials **

A library for carestream R4 interop that is run on R4 servers by the carestream-r4-installer project.

The windows service that wraps this project has very minimal logic, and basically just installs a known stable version of this library, and calls the main entry function. This is where all the magic is.

 Processing logic

Entry point is start in ./src/index.ts.

  1. Initialise application scope using licence key. This should test SQL server connectivity and that Flynotes recognises the licence key provided. Flynotes will provide us with SQS credentials which are valid for 36 hours.
  2. Check we're at the right version. Update and crash if not.
  3. Bulk upload basic details (name, address etc.) for all patients in the R4 database.
  4. Poll for SQS messages for 1 hour, handling each message with the appropriate handler function.
  5. If we've been running less than 24 hours, go to 2. Otherwise, exit.

We can rely on the windows service to restart the process whenever we crash.

The main message types are:

  • patient-sync. Sync a patient's full record (including medical history) to Flynotes. This is triggered just before a patient's screen opens in the main Flynotes app.
  • bulk-upload-patients. Perform a bulk upload of all patients to Flynotes outside the normal hourly schedule (e.g. for a scenario when a patient has just walked in the door of the practice and needs to be consented immediately)

We also have some debugging messages:

  • restart. Restart the process
  • test. Log a test message to rollbar
  • questionnaire-questions-upload. Log all unique patient questionnaire questions for this practice to Rollbar (we might want to manually map them in Flynotes).
  • questionnaire-answers-upload. Upload all unique patient questionnaire answers for this practice to Rollbar (we might want to manually map them in Flynotes). Note - this does not leak any patient data, as it only logs the pre-set answers, not the patient notes (e.g. 'Yes', 'True')

Publishing / npm permissions

On a successful build, the project is published to @flynotes/carestream-server, a private NPM package. This library is puled in by the R4 windows service (the start function in ./src/index.ts being the main entry point), and is also used by flynotes-server in order to ensure that the message types are consistent.

The carestream-r4-service has a baked-in npm access key which has read-only access to just this package inside our NPM organisation (login details in shared 1password vault).


We will only get one shot at installing software on an R4 server in a practice. Whatever we installed needed to be able to update itself on command so that we could fix bugs and add features.

As mentioned above, flynotes-server has this project installed as a library. When a running instance of carestream-server asks for basic information relating to its licence key, flynotes returns the installed version of carestream-server in this data. The R4 server then checks what version it is, and upgrades (or downgrades) to match it if it's out of sync. After installing the new version, the process exits so that the windows service can restart it.

This version check is run on startup, and then every hour subsequently.

 Database Authentication

R4 uses Sql Server 2008 (sigh). We worked out the schema by playing around with an installed version on an AWS windows server instance, and by working with Anup.

We rely on this being run as a user which can access the R4 database using Windows authentication to SQL Server. This seems to be good enough so far (connection string ends up looking like server=.;Database=sys2000;Trusted_Connection=Yes;Driver={SQL Server Native Client 9.0}).


The intention is for all logs/errors to be sent to the R4 Service Rollbar Project.

Any errors/stdout which aren't caught will end up in the service out/err logs on the R4 server, and these are much harder to get our hands on. Given this, we attempt to catch all errors we can and push them up to rollbar, even if we then tell the process to exit regardless.

 Future work

  • Testing - we managed to get a local SQL server instance running inside a docker container, and to bootstrap it with some data. We ran out of time to implement a full test suite, and were concerned that our assumptions about the shape of data may not even be correct. Investing time in testing this would be wise, even though it is quite a simple system.
  • Patients must have an address to be considered valid. We no longer require this inside Flynotes, so could try to relax this restriction.