The *Take Care* System

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 63

Take Care, an infrastructure application for patient-related information, written in APL, is the largest health-care system in operation in Sweden. In the summer of 2003 there are

• 700,000 patient record files accessed from
• 4,000 clients all over Stockholm at
• 25 server calls per second from
• 1,700 concurrent users on open socket connections;
• 8,500 registered users have online access to the patient records stored in a central database all based on APL component files.

The server is a mirrored UNIX machine running 30 workspaces on 30 different ports, listening for incoming traffic, plus some extra workspaces for communication with other systems.

1993¶

Let’s start from the beginning, ten years ago. By coincidence I met a nurse who introduced me to the world of hospitals. By that time, computers were common in primary care, but there were few in hospitals, for many reasons. The systems there were lab systems and cashiers’ financial records.

So we sat down and asked ourself "what would it take to make an administration journal system for the whole of Sweden (9 million people)?" We were allowed to visit the journal archive at a medium-sized hospital in mid-Sweden, and could study the paper files there. Some were small and some were huge.

As a result of that study, we found that APL component files were the perfect data storage. It felt almost as if component files were made for patient records. So one file per patient was a natural thing to select. In Sweden each person has a unique personal number that’s used all his life. A small formula translates that personal number into a file name and we had easy access to the files.

Having seen the lack of support systems for hospital care, this was a challenge and at the same time a real opportunity: to be able to build a system, starting with CLEAR WS.

All data was to be stored in the central database. The data recorded in the files would never be erased or changed. We studied the laws, and soon learned that no recorded information may be changed or updated. Any changes had to be traceable. So we simply stored any new version of the same document in what we call a new instance. That is a three-dimensional structure, where each version of the stored document carries information about who, where, when, etc.

Simplicity¶

Not even capable of programming my video, I knew at that time the importance of simplicity. The user interface must be clear, easy to understand and intuitive. Doctors and nurses do not work with computers, so a fast access to patient information must be very intuitive. The need for training must be minimal.

Everything we did focused on finding the important parts of a specific problem, and then making that as simple as possible. The benefits of this approach showed later on: users liked the system. As a very important effect, we also got very fast response times, almost everything subsecond. And that is true even when there are 1,700 concurrent users on the system.

Terminology database¶

Having a background in statistics, I also knew the need for "speaking the same language"; so one of the first things we did was to add a terminology database to the system. Definition of terminology used is available online.

We continued to design the server parts as well. The system was to become a central system, with access to all data from everywhere within the local network. In Stockholm there was already a large network in place. No medical information is stored on the clients.

1995¶

After a year or so we were looking for the implementation guide for EDIFACT. And by coincidence, there was Svante Lewald at the other end of the telephone, wondering what we were doing. So we told him of this fantastic new system, how easy it would be to add new functionality and so on.

He was at the time responsible for the clinical chemistry laboratory at Huddinge Hospital.

"We are ready to receive electronic lab orders from journal systems, but so far no vendor can do that."

Our reaction was, "Great, let’s do that!"

So we started designing the form for ordering lab tests. There was a well-established paper based system in place, so we had to make Take Care better than that. No one was going to make doctors use Take Care instead of paper.

Our first test started at the lung clinic, and after a few weeks we found doctors ordering lab tests happily with Take Care. This inspired us to develop further.

So far we had no contracts whatsoever. All our work had been done just to prove that it was possible to develop. In 1996 we got our first contract with Huddinge Hospital.

The lab order to the clinical chemical lab was very successful: electronic orders went straight into the lab system, and blood tests could start earlier, because no more registration was needed: just read the barcodes of the already-registered order. Test results were recorded in Take Care and stored in the journal files. The doctors had easy access to the complete history of test results for a patient.

The next laboratory to join Take Care was clinical bacteriology. The order form was programmed to have some intelligent guidelines making the quality of the orders better.

Version handling¶

We continued to add functionality, documenting journal texts, all based on the terminology database we had included at an early stage. The work defining terms really took off.

We also knew that we would have a lot of users running the system in the future, so the system updates had to be stable and automatic. Code tables and workspaces and namespaces are distributed automatically from the server to the Windows PCs as required. This means any new release is mostly a matter of replacing a handful files on the server. (So far we have had 408 releases since December 1996. Every one of the today’s approx 4,000 clients runs the same version of the system.)

Error control¶

We also built in automatic error control. If and when an error occurs on the client PC, we can catch it with ⎕TRAP and send that on to the server. So we see every domain error, etc., that occurs in the system.

Shipping new releases frequently makes things easy for us this way too. Should we introduce errors with the new code, it will take a fraction of a second before we can see it in the error log. (And there will be a lot of them too.) This has happened a few times, and we could act long before users reported the error. If no new errors pop up in the first hour or so, we can happily go on holiday.

Y2000¶

Then the year 2000 was approaching. Some of the older systems used for cashiers and finance were not going to work after 2000. In November 1998 we were asked if we could develop a new cashier, and economic and diagnosis reports. There was very little time, and we had no idea what we were going into, but we said Yes and had a seven months extreme period, calling in two more APLers to help us.

We had an intensive period with users around us all the time so we could construct what was needed as we went. In March 1999 we delivered the first parts, and the whole hospital managed to train their personnel and everything worked well as 2000 arrived.

Onsite customers¶

After that we continued to add functions in close cooperation with the users: meeting them once a week, discussing solutions and implementing them once we understood what we were supposed to do.

Nobody knows, the customer at least of all. Mostly they have only an idea – a good start. The first screens are taken back to the users, and we continue from there, testing, and detecting missing and unnecessary things.

While we work, we always focus on simplicity, removing every button or field we possibly can. Then comes a point when we look at the newly developed functionality and wonder "why did we not find this solution from the start – is this all?" And when that happens, we know we have made it.

Here are some parts of the system:

• Activity Organiser
• Prescriptions
• Intelligent Remittals
• 10 Laboratories
• Patient Registration (e.g. for operations)
• Consultation Remittals (to and from the hospital)
• Resource Planning
• Scanning
• Images import
• Emergency Department, where they all use digital dictation: a Philips Speech mike integrated with Take Care

The Future¶

Today more functionality is being added, and new customers are invited. Having joined Profdoc, Scandinavia’s largest vendor in the health-care arena, we find our future looks very exciting. Now we have access to well-defined data that just await analysis. An hypothesis test function is waiting to become reality and, who knows, we might be able to help the clever people out there make new medical discoveries.

The development continues…