wardle/pc4

PatientCare v4

pc4's Issues

CI/CD

Needs continuous integration pipeline as well as deployment.

Main deployment use cases are manual - so just need simple artefacts that can be installed within a private intranet (no automated deployment from the internet given the constraints) and to a cloud provider with a managed PostgreSQL eg AWS s3 and ec2/lightsail.

Finely-grained authorization

In the legacy rsdb, authorisation was finely-grained and relatively straightforward to implement as there was a single route (essentially) to access a patient record. That meant patient data might have been made available in other contexts such as a list of encounters, but that list was only accessible through authorized access.

For the graph API, things are slightly more complex as it is based on attributes and a graph. As such, client applications should query for an authorisation property which will provide information about whether a user is authorized or not, informing the use of the results from other properties.

For example, we need to make authorisation a first-class property for most entities. For example, resolving attributes for a given patient is subject to authorisation; any client requesting those attributes may not get results or only partial results. As such, an attribute :t_patient/authorization will provide information about whether the current session's user is authorized to access data. For a patient, there will need to be support for 'break-glass functionality so that the workflow of the legacy pc3 is replicated: patient access is attempted, the client shows a patient banner [ie some patient data will have to be returned for most use-cases if a user is permitted to 'break-glass' - ie clinical users], and the client displays an appropriate user interface to allow the user to 'break-glass'. This action adds the patient to the session's break glass list (or singleton), with the client reloading the page.

To support such a workflow, each entity should support an :authorization attribute when appropriate. Some attributes will be redacted if there is no access (e.g. a patient's diagnoses or clinical information).

Add WebSockets

This will permit bidirectional communication and being able to collaborate with other users more easily on shared documents and forms. Health and care is all about team working and we mostly work asynchronously, but some teams such as our MND clinic, work synchronously in clinic and it would be better to have displays that update.

Need to fix expansion and testing of codelists

Current testing is returning false for all medications.

Need to use new codelists library.

Specialist form to make changes to pseudonymous patient data

If an end-user registers a patient using the wrong information, it is not possible to change that information. There is an internal workflow that, given a patient primary key, and a global salt, the existing patient data can be changed. This updates the sex, date of birth, stored NHS number and any episodes associated with a stored pseudonym.

This functionality should be exposed, for certain users, in the user interface.

Try fulcro for frontend

Can't record relapses when there is a missing neuroinflammatory record

There should be an error message pointing user to create the record manually, at least - but this isn't being shown. The better option would be to automatically create when needed, which would need to occur within a serialisable transaction of course, and therefore have the potential to fail and need to be retried, slightly complicating the logic.

Request new project form

To enter a queue to add new project for end-users

Switch to using generic properties for communication

At the moment, the current priority and timescales force the use of rsdb properties such as :t_patient/patient_identifier, directly mapping to that field in the backend database.

This is wrong and overly couples the front-end. In all cases, there should be generic system-independent properties. We've seen how this can work with the CAV example, which simply uses FHIR based properties.

All rsdb properties should be deprecated in favour of system agnostic properties. Unfortunately, that will mean creating properties where available standards such as FHIR and openEHR do not already have a corresponding property type.

The design of pc4 means that this isn't a major issue and is something that can be done incrementally.

Unified network busy subsystem

Need a simple module that others can use to show a foreground or a background spinner, and log network errors.

Pc4 services cache

Many Pc4 services use immutable, versioned file-based databases.

It would make maintenance and operations far simpler to build an online cache of system service data files making deployment trivial. In addition, it would then be possible to automate updates (e.g. a new version of SNOMED with the latest dm+d built in CI and pushed to s3 automatically aligned to the dm+d release cycle). Use of the latest versions of datafiles would be as simple as updating configuration files.

Implementation would need to be two modes: upload and download.

In upload, we would be able to upload datafiles online (e.g. S3) ensuring a naming convention based on service/software-version/data-version. Upload could accept a pc4 configuration file and upload using that - ensuring any pc4 deployments that will use that configuration file will be able to work without manual intervention. It should also be possible to run independently from any pipeline, independent of the pc4 configuration file, so that, for example, when nhspd is updated, a new datafile is created, uploaded and make available.

In download, for example on pc4 startup, any missing data files would be downloaded automatically from the online cache into the local file path and then used.

In addition, it would be helpful to be able to list available datafiles and filter based on service, or log when a service is not using the latest version.

Many pc4 services simply take a :path configuration to the local file-based database. Instead, those using the service cache should accept a filename/identifier (likely a tuple of service-name/software-version/data-version), a local file path (for the files) and the caching configuration (e.g. s3 configuration). The latter would likely be shared across services.

On startup, for example, the caching service would check the local path and simply return the locally installed datafiles if they exist. If they do not exist, the online cache would be checked, and files downloaded if available. The path to the downloaded files would then be returned.

Upload could be called on demand based on service/software-version/data-version, or from a given pc4 configuration file. In essence, pc4 caching is mostly about a naming convention than anything else. This could then be available a la carte from the command line, as a library or via pc4.