Links: Home | Introduction

Technical Details

This presents a concise outline of the technical details for one implementation approach: a messaging system.

Note: As stated earlier the concept illustrated on the previous pages is technology neutral, which means there is more than one technological approach possible to implement this concept. The following details are for one of those approaches - other approaches exist and details could be provided if you require them.

Overview

This technical approach consists of the following layers. Each layer leverages the benefits of industry standards.

Advantages

This messaging system has the advantage of working in any context and on any system: centralised IT system; distributed systems; legacy systems; and even paper (and fax) based systems!

Tags and Data Fields

It consists of a text based approach with hash-tags to identify data fields. A library of these tags would be agreed upon across the health sector - probably using existing national standards and/or defacto practices. The tags included on this page are for demonstration purposes.

The tags can be grouped into the following functional sets:

» Privacy

» Transactions

» Date and time

» Organisation

» Contact details

» Patient data

» Medication

» Health insurance

Privacy

#privacyExpiryDate - determines the maximum lifetime of all data associated with a transaction.

#privacyPolicy - instructs users how to deal with the data, regarding privacy checking and deletion of expired data.

#privacyCheckUrl - automated systems should always check this to see if the patient has changed their mind about privacy (or cancelled the prescription). A manual check with a web browser is possible too.

Transactions

In the IT sector there is a term called Universally Unique ID (UUID) which represent a globally unique (randomly generated) value. It is proposed this is used for transaction ID values.

#originTransactionId - This is the first transaction ID associated with the prescription, and all following transactions associated with this prescription include this value so that all transactions associated with a given prescription can be grouped together.

#transactionId - each step within the prescription process generates a transaction with a unique ID.

#transactionDate - the date and time the transaction was created.

#transactionType - one of a set of predetermined values to indicate the step in the transaction process.

#transactionsUrl - automated systems can use this to securely get and send transactions (using a REST API). Users with a web browser can use this manually too - if they have permission to do so.

Other Tags

The other tags should be self explanatory (in the demonstration).

Demonstration

This demonstration shows the transaction text generated. The system would then distribute this to the relevant parties automatically.

(For those users that have not fully opted into the system, the transaction text could be distributed by other (low tech) means, e.g. print / fax / email. Some organisations may want to keep a paper backup in case their IT system fails. In that case the transactions could be printed out. Note that the privacy expiry date is at the top - so that paper records due for shredding can be easily recognised.)

Prescription Creation

[Assuming the relevant patient (and their insurer) have already been selected.]

Patient: Joe Smith

Insurer: ACME Health Insurance

Insurance reference: ZA/1121/5443

Please enter the prescription data:

Medication Name

Medication Dose

Medication Frequency

Medication Duration

Create prescription and send to insurer for PA check:

Transaction:

Note that the above text is not seen by the typical user - that text is processed by the system software to automate processes and to deliver a user friendly interface (like that illustrated on previous pages).

For those users that do not (fully) subscribe to the automated system (initially), the above text can be used (via the lower technology mediums of paper, fax, email and legacy software). These users may print the text, or copy and paste it into one of their IT systems. The bold text above helps to clearly identify sections within the transaction.

Additional text and notes may be added to the transaction text - the automated system would simply ignore lines of text that do not start with a hash symbol (#).

Automated Workflows

There are significant opportunities and benefits arising from automated workflows in parts of the prescription process. Using the above transaction data it is possible to automate the following aspects with conventional software. [AI could also be used to automate more aspects.]

Notify service providers

For each type of action (#transactionType) there may be an average duration, or maximum policy duration, by which time the organisation aims to complete that action. When an action takes longer than the average and/or the policy maximum the relevant user(s) can be automatically notified by the system (based on the time elapsed since #transactionDate).

Notify patients

Patients can be automatically notified when the status of the prescription process changes. This can be a smart automated notification system that attempts to contact the patient in the following way (the first probably being the preferred option):

» Email (#patientEmail)

» Telephone (#patientPhoneHome or #patientPhoneMobile); or

» Post (#patientAddress, #patientCity, #patientState and #patientZip)

Relevant information

Patients can be directed to relevant supporting information (e.g. websites) about their medication (#medicationName), treatment, lifestyle choices, and supporting services.

Automated transactions and privacy management

Transactions (information exchange) can be automated (via #transactionsUrl), and information automatically deleted when privacy rules dictate (#privacyCheckUrl and #privacyExpiryDate).

Next

Links: Home | Introduction