Version Management and Computerised Order Entry Systems

 

Isolated order entry vs treatment plan updates

Computerised Order Entry Systems (CPOE) are used to create therapeutic or diagnostic orders for patients. Traditionally, CPOE systems are designed to let prescribers enter orders for a patient, sequentially, each at a time in isolation of existing orders. However, the whole set of orders for a patient defines the treatment plan for the patient. It would be more natural to have the CPOE modify a treatment plan as a whole, i.e. let the prescriber add, remove or update the set of existing orders for a patient. In this case the CPOE can not only apply business rules and perform calculations for each orders but also for the treatment plan (set of orders) as a whole.

Updating an existing order can also be implemented in different ways. The CPOE can change the order itself and persist this change, or the CPOE can remove the existing order and add the updated order as a new order. In the latter case each update of an order results in a remove and insert action to the set of orders.

 

Version Management of the Treatment Plan

Treatment plans for patients changes over time. Each treatment plan change could be viewed as an update of that plan. The treatment plan and these updates need to be persisted to a database. At first glance it would be logical to implement this requirement as an update in the database, i.e. the old treatment plan data is overwritten with the more recent treatment data. However this is a destructive action, as information is lost.

A different approach is to have the system persist a new version of the treatment plan as a whole to the database, which leads to the situation in which there are now 2 versions of the treatment plan, the old one and the newer one. When combined with the strategy in which every update of an order is implement as a removal and insertion of the updated order in the treatment plan, the CPOE effectively is taking snapshots of the entire treatment plan each time an update of that treatment plan is persisted to the database. This enables the persistence of a timeline of the treatment plan, no information is lost and the evolution of the treatment plan over time can be replayed. Actually, this is how in, for example, a Word document, the application allows the user to revert or reapply changes made in a document.

 

Logging and Version Management

So, when each change of the treatment plan as a whole is persisted to a database, logging these changes is relatively easy. The treatment plan change is identified by the version, which can be implemented as a timestamp: the date time of the current moment the treatment plan is persisted. The same version/timestamp can be used to log the action of persisting the treatment plan to the database along with additional details, like who persisted the change to the database.

 

Version Management of the CPOE as a whole

This principle of version management in which for each persistence to the database a new version of the dataset is persisted can also be applied to a CPOE system as a whole. A CPOE system not only needs to know about the orders for a patient but also needs:

• A set of available list of ‘orderables’, for example a set of medication products
• A set of dose rules that can be applied to orders to check whether orders are valid
• A set of solution rules for medication to check whether medication that needs to be prepared as a solution is valid

These configuration can also change over time and are part of the state of the system as a whole. When using a version management each change of a set of rules can be persisted as a new version of this set, along with logging the version change. This allows the following algorithm:

1. When the CPOE is initialised, the latest sets of configuration settings (available ‘orderables’, i.e. medication products, dose rules, solution rules etc…), is retrieved.
2. When a patient is selected the latest version of the complete treatment plan (set of orders) is retrieved.
3. When a specific version is selected of a previous version of the treatment plan:
   1. That order set is retrieved.
   2. The configuration settings that have a version which was ‘latest’ at the time of the treatment plan version, are retrieved.
   3. The version timestamps can also be stored along with the treatment plan version to relate the treatment plan to specific versions of the configuration settings.
4. When configuration settings are changed, a new version is persisted and upon initialisation of the treatment plan, the new version of the settings are retrieved

So, not only a complete treatment plan history is available and can be ‘replayed’, also, the current state of the CPOE system can thus be reconstructed.