Links: Home | Introduction

Feasibility and Implementation

The feasibility and implementation aspects are outlined here. The concept illustrated on the previous pages is technology neutral: it could be implemented using any standard IT technology whether that be modifications to legacy systems, additional modules, or the creation of new systems. The concept could be implemented in a centralised system, or via a distributed approach. A smart solution might even support a combination of these approaches. This means it is feasible for all stakeholders to participate.

Background

Currently a range of approaches are adopted for storing and exchanging medical (or health) records, and for transferring prescription information. These include the following: paper based information, transmission by fax, records on an IT system (database), email, automated electronic exchange protocols, and electronic workflows (to streamline processes). Identifying common standards for data storage (e.g. field names and definitions) and exchange represents a useful starting point. This may be inspired by investigating open and national standards, and defacto practices in use today.

Given a diverse range of existing scenarios, a flexible and scalable approach probably offers the best solution.

Flexible and Scalable

It is proposed that the adopted solution provides a flexible and scalable approach. This means that stakeholders can participate with a range of (legacy) systems and interfaces; and over time they can adopt more of the functionality as and when they wish to do so. A range of system and service options would be available: some users might start by adopting a few aspects and evolve over time, while others (such as pioneers, champions and early adopters) adopt a comprehensive range of services.

This flexible approach also allows for adaptation to future disruptions from innovation.

To keep the approach feasible a limited range of interface options and support for legacy systems would be provided. The chosen options would adopt IT standards, open source standards, commonly used approaches in the sector, and contemporary and planned sector specific standards (e.g. electronic health / medical records). This ensures the greatest impact for a given effort. (Note that this approach does not necessarily exclude a minority of potential users that may have incompatible legacy systems. These users would just have to carry out a simple manual step to get their data (prescriptions) into the system, such as copy and pasting the text.)

It is recommended that AI capability is added to the system at a later date. This allows sufficient time for usage practices and (anonymous) data to be collected, which can then be used to train the AI (machine learning) system. The initial system design step should consider how this influences the requirements and functional specifications.

Centralised System

It is feasible to quickly build a solution using a centralised IT system, based on standard databases, software and Internet technologies. A prototype could be developed within one month, and a fully working system could be developed within three months; followed by beta testing. Standard interfaces could be used to allow staff across all organisations to access the system via easy to use web pages, and receive notifications via email. Standard Internet protocols (e.g. REST or SOAP APIs) could be used to allow automated transfer of data between systems.

Note: The technical approach is centralised, but multiple providers of these systems might emerge (e.g. the hypothetical sites of prescribe.acme.com and www.xPrescriptionsAreUs.com).

Distributed Systems

It is possible to build this solution as a set of distributed systems:

» The process could be distributed; and/or

» Each health care provider (or pharmacy) could host their own system.

Different steps in the prescription process could be supported by different systems (and hosted by different parties).

An HCP might have their own system, which provides interfaces for their patients and specialty pharmacies to use. Rather than actually hosting the system (with their own servers and software) HCPs might make use of virtually hosted and managed systems, whereby the technical aspects of hosting are provided by a third party. The HCP controls the data and the prescription process. Good practice would suggest that the data is encrypted on the server (and in transit), which would prevent unauthorised access to the data.

Similarly, specialty pharmacies may opt for virtually hosted and managed systems. [Although the author thinks the above HCP model might be more appropriate as they are probably the most suitable candidate to be guardians of patient data.]

It is even possible for a combination of distributed approaches to be used (in terms of the process and hosting).

For these distributed solutions a well defined messaging protocol and data definition specification are required.

Although such a diverse arrangement might initially seem complex, this need not be the case; and it offers the opportunity to allow lots of service providers to deliver a range of services, using their own internal (legacy) IT systems.

A distributed solution might be possible via new blockchain technologies, though other traditional IT approaches are available too. [The author has limited knowledge of blockchain and is unable to assess the suitability, or unsuitability, of blockchain.]

The author designed an innovative messaging system and investigated its technical aspects. It could support a distributed approach using any technology (and would even be compatible with legacy systems and paper based approaches). It features text with hash-tags for data fields, transaction IDs, privacy expiry dates, privacy check URLs, privacy policy, and URLs for transactions. [It could also be used in a centralised approach.]

Adoption

As with any new approach or addition, attention has to be paid to migration: system updgrades, data migration, and staff training. This approach aims to minimise the impact of this by allowing staff to continue using legacy systems (with modifications), and to gradually adopt additional functionality over time (if they wish to do so). For those that want to quickly migrate the majority of their process to the new solution, the simplicity of design in user interfaces and the support for common practices and data standards means that the migration should be relatively simple.

Technical Details

The author has investigated detailed technical aspects of this implementation to confirm its technical feasibility. One specific approach has been documented and illustrated with a partial protototype. (For completeness a very simple alternative approach has also been included.)

Next

Links: Home | Introduction