Clinical Document Archive

This paper is a manifesto for developing a cloud-native archive for clinical documents as an alternative to large and expensive health information exchanges.

↑Introduction

This paper is a manifesto for developing a cloud-native archive for clinical documents as an alternative to large and expensive health information exchanges.

Many regions currently using HIE technology utilise less than 20% of the profiles offered. The majority sticking mainly to XDS for documents and data sets and XDS-i for images. Yet they are paying for the entire solution; for which use cases can’t be found.

Most suppliers in this space are not cloud-native, meaning the infrastructure they run on can be costly and difficult to maintain.

There is a gap in the market for a document archive solution that focuses on the twenty per cent of functionality that clinicians require. Focusing on their core requirements will deliver a solution at a fraction of the operating cost; allowing health organisations to realise significant benefits.

A product developed using modern software development processes and adopting a cloud-first serverless approach will significantly reduce operating costs. Designed from its inception to leverage new cloud storage options will reduce costs while increasing the resilience and durability of essential clinical data.

I have worked in healthcare for twenty-four years. I’ve helped implement large information exchanges and created software that has produced millions of clinic outcome letters (ALMA). My work in serverless cloud technology is featured on the AWS public sector blog. I know what features clinicians desire from a clinical archive repository, and this system will give them the enhanced experience they deserve.

The intention is to develop this solution openly, publishing the code to GitHub as and when the various components are ready. This paper will be updated with progress notes, architectural decisions and technical specifications as the solution develops.

↑Goals

The intended goals of the project include:

• Speed as a feature Clinical staff are extremely busy and shouldn't have to wait for systems to load data. Speed is a feature. When most clinical systems can take upwards of five seconds to load a list of clinical documents associated with a patient, staff just stop using the system. This system will have transaction times measured in micro seconds, not seconds.
• Standards based The system will use standard HL7 MDM messages as a mechanism for organisations to publish documents to the archive. The will be done from facilities TIE (Intersystems, Rhapsody, Mirth)
• Content agnostic The system will accept content in any format, including audio and video and allows patients to upload photos for telemedicine workflows.
• Content collation The system will automatically build and maintain a single document for each specialty. This makes it very easy for clinicians to quickly retrieve and scroll through all the documents within a given medical/clinical discipline.
• Flexible architecture Easy to implement additional workloads on document submission. For example, load the content through Medical Comprehend to get SNOMED CT codings for each document, adding structured meaning to an otherwise unstructured file.
• Themeable The UI (User Interface) of the web application will be configurable for different clinical needs. For example, radiologist might wish to see radiology reports first.
• Multi organisations The system will work equally as well for multiple organisations as for a single hospital facility. The system removes the need to create/maintain a central PIX removing the overhead of having to manage the inevitable duplicates.
• Embeddable The web application can be embedded within patient context to all the major ERP and clinical systems using web technologies.
• Subscription/Alerting health professionals will be able to subscribe to notifications about patients and/or documents being published. All alerts will be sent via Gov .Notify.
• Secure using [strict CSP (Content Security Polices) and enforcing TLS1.2 with a reduced hand-selected number of cipher suites, the system will pass all security checks. All data is AES encrypted at rest and in transit.

↑Pricing Comparisons

Traditional set-ups have monthly operating costs ten times the base-line for this product:

• Elastic Compute – 800 USD per month, serving the main web application and the HL7 listener.
• Elastic Load Balancing – 30 USD per month, giving multi-availability resilience across the compute architecture.
• Elastic Block Storage – 70 USD per month for 10 TB of glacial instant retrieval storage. 10 TB of storage is enough space for millions of documents.

Monthly running costs less than $1,000. Compared to similar architectures which cost over $10,000 per month to keep the lights on.

↑Progress

• 18.03.2024 – started developing the HL7 parsing module.

↑Versions

• 18.03.2024 – added note about subscriptions and alerting.
• 08.03.2024 – initial document created.