It set me thinking whether ‘salami slicing’ applies to Epro and if it is always a bad thing. Of course, it means different things in different contexts, and the use here by the commons committee was different to that here.

So which is the better approach to savings – a few large changes or a series of small amounts, which combine incrementally to something significant. As ever the answer is almost certainly something along the lines of ‘it depends’ or ‘both are useful’.

Healthcare IT (which is our core business) is often touted as a means of achieving savings. Whilst obviously we like to hear that, and indeed sometimes our sales people peddle that message, personally I think a more palatable wording would be along the lines of ‘business change projects, supported by IT systems, can deliver significant savings.’ Without associated business change, it’s unlikely an IT system will deliver significant savings on its own.

This is one reason why we partner with companies like digital dictation providers, Winscribe, to deliver whole solutions rather than technology installations. One example of a single big saving comes from a large trust who purchased a solution combining Epro clinical correspondence, Winscribe Digital Dictation and Dragon Speech recognition with the aim of a 1.5 million spend to achieve a 9 million saving. There is certainly much technology involved, but the key to realizing the savings is the associated re-organization of people.

Merry Christmas from everyone at Bluewire Technologies!

2011 has been a great year for Bluewire and Epro. We have had three new developers join the team: Ruari has joined us to help manage deployments of Epro, Matthew has been working on our reporting functionality and Kit has been developing our new Epro.com website. We also have Bonny who has joined us as a freelance usability consultant, and she also works on our online presence and community participation.

Sadly, Glenn left us to pursue other things, though he is still seen here now and again (especially when Adam cooks for us all!).

Our Technical Director Will left us for a year long sabbatical too, however we still hear from him on our blog.

We have had one of our busiest years to date, having deployed Epro to three new NHS Trusts this year: Leeds Teaching Hospitals, Harrogate Hospital and Portsmouth Hospital. We hope that 2012 continues to see more deployments across the UK!

The GitHub set up guide has a good introduction to ssh keys, if all goes well it looks like this:

    doug@local:~$ ssh -T git@github.com
    Hi Douglas! You've successfully authenticated, but GitHub does not provide shell access.

Since my ssh keys are on my local machine, connecting to GitHub is seamless. While setting up a remote server to demo a side project, I wanted to check out some code from GitHub, and here’s what happened:

    doug@local:~$ ssh doug@remote
    doug@remote:~$ ssh -T git@github.com
    Permission denied (publickey).

To connect to GitHub I need to use my private key, but I don’t want to copy my key to the remote server. SSH Agent Forwarding to the rescue.

SSH Agent: Could not open a connection

The first problem was that I couldn’t access my local ssh agent from the remote server. Here’s what the error looks like:

    doug@remote:~$ ssh-add -l
    Could not open a connection to your authentication agent.

Agent forwarding needs to be enabled locally and on the remote server. On my local machine, I added this to my ~/.ssh/config:

    Host remote
    ForwardAgent yes

The Host section header accepts a wildcard, but make sure to only enable it for hosts you trust to act as if they have your private key. On the server, AllowAgentForwarding yes should appear in sshd_config, but this is the default on Ubuntu so I didn’t have to make a change.

SSH Agent: The agent has no identities

Once the remote machine could connect to the agent, I was surprised to find that it didn’t know my identity, even though I was already connected to the remote machine!

    doug@remote:~$ ssh-add -l
    The agent has no identities.

This produced the same output on my local machine, so it looks like the ssh connection was using the private key directly, skipping the agent. I ran ssh-add to add the local keys in ~/.ssh to the agent:

    doug@local:~$ ssh-add
    Identity added: /Users/doug/.ssh/id_dsa (/Users/doug/.ssh/id_dsa)
    doug@local:~$ ssh-add -l
    1024 b6:dd:b7:1f:bc:25:31:d3:12:f4:92:1c:0b:93:5f:4b /Users/doug/.ssh/id_dsa (DSA)

This isn’t something I would want to have to run after every restart, so here is how to make it happen automatically on OS X and Windows.

Digging Deeper

The ssh -v verbose flag produces lots of interesting output on authentication negotiation. Here’s the line which shows that GitHub requires publickey authentication:

    doug@remote:~$ ssh -vT git@github.com
    ...
    debug1: Authentications that can continue: publickey
    ...
    Permission denied (publickey).

Considering the role of OSS within healthcare, I think there are two distinct categories:

1. Open source solutions which might be procured directly by the NHS.
2. Open source components to facilitate building software for the NHS.

The first category is where recent discussions have focussed and includes things like operating systems, databases and healthcare-specific software such as the clinical portal released by Leeds recently. There are some very well established options here but uptake has been very limited so far, largely due to the well established dependency on Microsoft technology (which, until recently, has been licensed at a heavily discounted rate) and risk-averse procurement processes.

The second category is interesting because having open source components for NHS software both lowers the barrier to entry for new suppliers and also allows suppliers to concentrate on areas which deliver customer value. There is very little UK-specific tooling around standards such as HL7, ITK, Common User Interface, DM+D, SNOMED CT – suppliers spend a lot of time and money implementing internal tools to deal with these themslves. Why are there not open source projects in these areas? I think a large part of the problem is the lack of a visible, active healthcare-specific development community in the UK. As a supplier, why would invest in open sourcing one of your internal projects without confidence that the development community can extend and support that project in a more effective way than we can on your own?

Before I left we were already fairly well set up for remote development – there is sometimes a need to do some coding at a customer site or on the road – so the infrastructure was in place, and we set up a git mirror of our subversion repository so we can make complex changes without syncing back to the office. However, there is one part of the development infrastructure I’m missing – my co-workers.

In Brisol our office is open plan. If there is a piece of code or architecture you don’t understand then the path of least resistance is to wander over to person who wrote it and ask them how it is supposed to work. Forgetting the well-documented productivity hit that interruptions can cause, this seems like a good thing for whoever is stuck because it can quickly solve their problem.

In Australia, without the luxury of easily contactable co-workers, my only immediate option when I don’t understand something is to read the code. There is a much stronger motivation to refactor and review when access to the person who originally wrote the code is restricted. Maybe this is yet another reason to allow developers more isolation from their co-workers when writing code?

Over the past few months we have been looking at how we can improve the training we provide clients and partners using Epro.

As a User Experience (UX) designer, I’m concerned by systems that require users to have training before they can use them, as the idea of needing to be trained implies that a system is overly complex. Contextual support and error prevention can be used on most systems and websites to ensure that users have the freedom to use the service at their will. However, looking at the nature of tasks users have to perform using Epro, and the potentially fatal consequences of errors, in this case the system does demand that users have a good level of understanding before they are able to use a live system. Training is therefore essential to protect patients from errors that could, in some instances, be very unpleasant.

We currently run training sessions with groups of users at Trusts before Epro is launched within their Trust. These include interactive demonstrations of a test system that trainees can explore and play with, so that they become familiar with the tasks they will need to conduct. Although this does work well, we have been looking for ways to improve as training does not always occur at the optimal time for participants (due to busy hospital schedules). If we are to provide the best training for users we need to find ways to ensure they retain the information they learn.

After doing some research into training techniques, I’ve developed a list of key points we are going to use during our review of our Epro training procedures, which are shown below. These focus on ideas that can help users to recall information in the long term.

Improving information retention

“It goes in one ear and out of the other.”

– Exactly what we don’t want

Information recall can be improved by making allowances for the following factors:

Content structure:

People remember things better that are at the start or end of training sessions. Structuring content to complement this can help to ensure the most important lessons or take aways are retained above less important points.

Refreshing trainees memories

People recall things more poorly 24 hours after training – reviewing materials at this point can help to cement them, and allow them to retain the information. One way to do this is to run a quiz or test the day after training has taken place. We are actually developing an online quiz for our Epro trainees to use following their training sessions to help them put their learning into action.

We are also planning to introduce an online community forum and knowledge base where Epro users can go to re-engage with training materials as well as ask questions and request new features. We hope that this helps to maintain the user’s level of knowledge over time.

Use triggers to aid memory

People struggle to remember lots of similar things, so you can influence what they remember by making key points unusual or unexpected. These points will be more memorable, and if they are particularly surprising, they will be easily recalled by trainees.

Another tactic to help people remember details is to use mnemonics and/or analogies, like the ones used in school science classes: remember ‘MRS GREN’ (Movement, Respiration, Sensitivity, Growth, Reproduction, Excretion, Nutrition).

Engage both sides of the brain

People recall things better when they engage both sides of the brain: both analytical and creative thinking. Visual material and material that stimulates emotional responses is more memorable than material that is heard or talked about. These different types of stimulus are ‘saved’ in different parts of the brain, so having materials that offer these different characteristics increases the chances of the information being stored and recalled.

Maintaining concentration

During training, participants ability to recall or follow information gradually reduces as they lose concentration. Unfortunately as humans we have limited capabilities to keep attention for extended periods of time. This can be partly alleviated by structuring the training to incorporate changes of pace and short bursts of activity. These changes help to re-engage those who might have lost their train of thought.

I started working at Bluewire Technologies this summer after graduating from University, and so far I have been doing a lot of work with Microsoft SQL Server. The timing of the SQL Bits conference came at just the right moment for me as I have spent several months getting into SQL Server and I’m now ready to broaden my understanding. It was also a great opportunity to meet other SQL users and pick up tips.

The conference was my first ‘proper’ professional event I have attended, and It gave me the opportunity to experience working away from the office and introduced me to networking with other professionals. I set myself some goals for my time at SQL Bits, which were:

• Experience: To enjoy the opportunities that occurs when working out of the office
• Learn: Deepen and broaden my understanding of Microsoft SQL Server
• Network: Take advantage of the opportunity to meet a large variety of different people

Part of my job is to deal with execution plans, deadlocking issues, query performance problems and the reporting services (SSRS) component of SQL Server, so I was keen to develop my knowledge of these areas at the conference. Topics of particular interest to my work included:

• Execution Plans: Understand how they are created and can be manipulated
• Lock behaviour: Discover how transactions and threading affects a database
• Integration Services: Gain overview and explore relationship with Reporting Services
• Performance: Be aware of queries to avoid, why they bad and possible resolutions
• Reporting Services: Increase my level of expertise for creating SQL reports

Day 1: SSIS

The full day session that I attended on Thursday looked at SQL Server Integration Services (SSIS). This session primarily focused on how SSIS can be used to support extract, transform and load (ETL) process. The beginning of this session provided a good introduction into using SSIS, though later demonstrations showed how reporting can be used alongside it.

Key points I took away from this session:

Buffers and Settings: Developed understanding how settings like buffer size affect performance
Control flows: Seen how tasks, block sets and looping can be used to execute data flows
Data flows: Identified how sources, transformations and destinations can be configured
Performing ETL: Identified how flat files can be used to perform incremental loads into SQL Server

Day 2: SQL Performance

SQL Performance: Looked at SQL queries, identified performance issues and walked through the solutions.

Transactions and Locking: Developed understanding of how implicit and explicit transactions behave and which concurrency locks are not compatible. Deadlock prevention mechanisms were also discussed – identified that NOLOCK should rarely be used and uses of database snapshots.

Day 3: Advanced Reporting Techniques

Advanced Reporting Techniques: Broadened understanding through looking at examples to perform reporting. This included been shown how to develop themes for per user basis, creating Gantt charts, heat maps and the effects of using tables and sub-reports.

Execution Plans: Improved my knowledge surrounding execution plans and their effect in a database – am more familiar with behaviour of joins and aggregates.

Map-Based reporting: Seen how map data can be created and used inside SSRS

PowerPivot and QlikView: A comparison and contrast of two business intelligence tools that allow database data to be brought into either Microsoft Excel or Qlikview’s visualisation interface.

SQL Service Broker: Looked at how the SQL service broker can be used to achieve certain functionality.

What I have gained from SQL Bits

The conference has given me more confidence when It comes to solving problems and understanding the performance of our SQL Server databases. I’m also spending more time experimenting with SQL and using the information I took from the sessions which is great.

I am also planning on attending the Bristol SQL User Group as I think it will give me more opportunities to learn and share knowledge.

Resources

Below I have included a set of resources that belong with each session. There should be videos of these talks being made available as part of session list for SQL Bits.

Advanced Reporting Techniques: This presentation was primarily based upon the work on the milestone scheduler. Other useful resources include SSRS reports examples and SSRS Tutorial.

Execution Plans: Slides and SQL code.

Map-Based reporting: Slides, reports, database backups and demo notes are available.

PowerPivot and QlikView: Has provided the slides alongside relevant resources: Powerpivot workbook and Qlikview script.

SQL Performance: Link to SQL code used in the session.

SQL Service Broker (and Gathering Performance Data with PowerShell): Video of session.

Transactions and Locking: There are slides from this session as well as a notes from 2008.

The HMRC had made a mistake, presumably a case of mistaken identity. Given that everyone has a unique National Insurance Number, this set me wondering how that error was made. Did someone do a search like ‘john smith bristol’ and then pick the name above or below the one they wanted? This is an established risk with pick lists and is something which should influence the way you design pick lists for drug prescribing. Not all suppliers do this which has led to some negative press reports. There is some good guidance on it here.

Perhaps the error had occurred as a consequence of using a single key field (e.g. National Insurance Number)  for identification which is an inherent risk of relying on a single key field. Incorporating a check digit as in the case of NHS Numbers partially mitigates against this, but only detects errors which alter the key field to an invalid one, not ones which alter it to another valid entry, which may reference a real entity.

Let’s consider administration of drugs at the bedside in hospitals. It is incumbent on the nurse to identify each patient correctly as step one. One strategy is to attempt to enforce two or more factor identification such as checking a number, name and date of birth or address. At first thought this would seem to reduce risk, but asking people to perform repetitive actions which consume extra time, may lead to reduced concentration or a mechanical approach which defeats the primary aim of trying to reduce mismatch errors.  Bar code technology can help but is not a cure all.

How should one check multiple factors? Checking name, number and date of birth correlate from a chart at the end of the bed or a wrist band still do not necessarily remove single points of failure (wrong chart, wristband with errors). Verifying the patient’s name and date of birth by asking directly would seem an obvious approach for mentally competent patients. During a recent in-patient stay, this provides the added benefit of furnishing my 80 year old razor-sharp-witted mother to respond to an enquiry of her date of birth with ‘The same as I told you when you asked me at 0911 this morning, and four times a day every day since I was admitted.’

From a commercial perspective, we have had little or no demand for SCT support from hospitals. The only place where we are using the terminology significantly is when recording drug administration using the dictionary of medicines and devices, which uses SCT identifiers internally. In turn, these can be used to drive decision support (we use First Databank) and so there is an incentive to collect the structured data. All of the national datasets that we use in a structured way (such as Specialty Codes) do not yet use SCT, and it is not always the case that hospitals use these codes internally anyway.

As to the future of SCT, I have some thoughts:

1. There needs to be a strong commercial incentive for suppliers to support SCT. Initially, I think this will come as the national datasets migrate to SCT terms. After the low-hanging fruit, I think adoption will be much slower, and it will be a long time before we start to see SCT used for what is currently unstructured data and have the tools to take advantage of the properties of SCT which differentiate it from it’s predecessors.
2. We need significant user interface innovation around clinical data entry if we are to start replacing unstructured prose with structured / coded data. Maybe tablets will provide the incentive here, since on-screen keyboard input is clunky, and it is an opportunity to start with a blank slate. This kind of innovation is tough in the risk-averse and commercially difficult NHS environment and, although tablets are in vogue, it is yet to be seen whether there is a market for software that really takes advantage of the platform.
3. Collecting structured / coded data is very difficult if we don’t know how it is going to be used – if we could work this out retrospectively then it is effectively the same problem as automatically deriving codes from natural language.
4. Hospitals and suppliers need better tools to manage and work with the SCT releases. At the moment, we are having to maintain our own internal SCT terminology database, applying updates and subsets ourselves. This is costly, and means that the terminology is only updated with new releases of our software. Under Connecting for Health there were noises about NHS-wide terminology services but we’ve never seen this implemented anywhere. At a technical level, there is little / no out of the box support for the standard platforms and development tools that most NHS-supplied software is built on. Where are the libraries and tools for developing against SCT in .NET or Java?

Overview

I think it is important to look at how databases affect the development of systems. For I believe that this does not only affect how functionality is composed; but defines the roles, responsibilities and social interactions within a development. I would therefore like to take this opportunity to discuss with you the methods that use database version control to provide database migration and the possibilities of automating database migration.

Project Development Level

In project development, it is important to treat the database as a distinct component to the application and external services (such as data logging and report generation tools). The primary job of both the application and any external service is to provide processing to the data it receives, whereas the function of the database is primarily as an information storage and retrieval system.

The problems faced when looking at typical development teams is that there is this propensity for application code to be placed under a version control system, but for the database to be placed outside of version control. It is often common place for single instances of databases to be shared between multiple developers.

From a project development level, each developer should work with their own version of the database. No longer does there need to be a build-master to police the changes made to the database.

By using database scripts to make changes to the database and having a system which can execute those scripts, then there should be the framework to allow developers to re-build their databases to make sure they have the modifications that other team members have made.

Automation Process

The automation process for the database component of a project could be done by tools that generate database scripts. One option would be to use tools that examine code and files to automatically generate these scripts. The alternative approach would be to consider using a graphical tool that allows the user to modify a database, whilst it tracks changes made in order to generate scripts.

An example of a tool that manages scripts is Microsoft Visual Studio Team System, which allows ‘Database Projects’ to be created.

Whether or not you would want to use these tools to automate the process of generating databases scripts is really be up to you. The issue that will be faced is finding the right tool for your needs that will allows those nasty edge cases to be manually enforced.

As long as database descriptions are generated, whether that is manually or otherwise, then they can be versioned. With database descriptions versioned, then the rest of the database migration can take place. From my experience, generating these by hand would work.

Addition of Features

Features are added to a project to add or modify functionality for the application, database (such as reporting data or query performance) for the whole project. It should be the case that when modifications are made to a database, they should also be attached to any relevant code changes via source control.

Developers should be encouraged to change the structure of tables, rather than feeling that they should only rely on views / functions / procedures to generate data. This attitude should affect the culture in the workplace and empower good development choices.

It is worth explaining at this point the two methods of defining modifications to the database when using database scripts.

Object Based Scripts

In an object based scripting system, one file is responsible for creating a new item – such as a database table, view, procedure or function. Each file may also take the responsibility of removing or backing up the previous instance of the item before creating a fresh copy.

What this method does is allow fresh items to be created by a developer in one go, since one file contains the complete description needed for creation.

The process for re-building the database is:

1. Remove database
2. Run every file to create database, tables and other items
3. Import data into tables

‘Delta’ Based Scripts

A ‘delta’ based scripting system, operates by taking built version of a database and applying patches to bring a database up to date. In this type of script, one file shows changes to an item rather than describing item as an item. This means that often it is easier to find out the current structure of a table by checking database rather than reading through multiple files.

The process for re-building the database is:

1. Remove database
2. Build database by importing tables and data
3. Apply patches up till the version needed
4. Call scripts to create the other items – views, procedures, functions

Scripting Database Migration

‘Delta’ files work well for migration, as long as you keep record of the patches that have been applied to a database.

The process:

1. Perform delta
2. Drop other database items (view, procedures, functions)
3. Build / create other database items

The advantages of using delta files are that they often provide a good description of the changes that have taken place in a table and often capture the intent of the changes as part of a database patch. Data processing and manipulation can take place on a patch by patch basis.

They are not always the best of solutions. They may increase the time taken for a development build of a project to re-build the database, as tables will be modified more than once.

Relying on this approach will also require developers to create ‘delta’ files when they want on the database. It is hard to judge whether this is a positive or negative change.

When using object based scripts for database migration, either a database difference script or a set of ‘delta’ files need to be generated. The problem with relying on a generated script that just compares the database structure is that the outputted migration script is usually too messy to read.

‘Delta’ files can be written by comparing the table differences using a version control system. Those files can either be written manually or by an automation process that can process the logs in the version control system. Both of these approaches often the require contact developer who made the change, in order to understand the intent of the change and whether any data processing is needed.

The Current Migration Scheme

We use object based scripts to keep the barrier for database table changes to be low. Delta files are not automatically generated and require one or two individuals to write them. This does require chatting to other member of the development team to make sure the intent and data changes can be captured.

There are several scripts currently in use to aid the development of ‘delta’ files and to perform database migration. In this first case, there are tools to help perform operations such as add column, which cannot be performed in a single database command. There are scripts that allow test migrations to take place by retrieving and building an old version of a database and then running a set of patches.

There is also a tool called SQL Delta, which allows database structures and data to be compared for inconsistencies.

There is currently no script that handles the recreation of the functions, procedure, views, etc.

Where can we take this?

We need to change to way database migration takes place. The process for updating functions, procedures and views is currently a manual process involving dependencies on GUI. It should be appropriate to drop these items and create them new, since they contain no data.

It is worth considering if the generation of delta files and patches can be aided via an automated process that using a version control system to identify changes made. This may allow delta files to be grouped together when files are modifying same table.

There is no way to automate the testing of a migration easily with the scripts. We may need to look at making changes or additions to the test migration scripts to better support this.

Currently, we can use SQL Delta to some extent to aid testing by using it to compare structure and data differences.

This post is part of our team knowledge share presentations. To see a complete list of these sessions, please take a look at our knowledge sharing page.