EHR - Electronic Health Record   Home    Dansk 

Uvis - tool for end-user customization   Anonymising health records   EPIC acquisition  

2003: Region Fyn EHR

In 2003, Region Fyn wanted to acquire a new EHR system. They had heard about the task method for specifying requirements - and the advantage compared to use-cases, which were popular at that time. We set up a cooperation where I wrote the data model and the tasks - the two key parts of IT requirements. The result was a success for the Region. Further, in 2007 the result became the basis for the problem-oriented requirements (SL-07). SL-07 uses the EHR-system as the main example, but has added many requirements to the 2003 version: integration requirements, response time requirements, usability requirements, business goals, selection criteria, etc. In a typical SL-07 requirements specification, tasks and datamodel are around 50%.

2005: IT architecture for EHR - are principles sufficient?

The Danish government had decided that in 2006, the existing 14 small regions in Denmark ("amter"), were to be merged into 5 large Regions. Each "amt" had its own hospitals. What to do with the hospitals in the new, large regions? In april 2005, the IT-architecture board of the Region Association published a report on Common architectural principles for EHR. Several organizations were invited to comment, and I was one of those who sent a reply (Download reply (pdf), Danish).

The main problem as I saw it, was that the board's proposal didn't address the serious problems in the area, e.g. that the systems should exchange data, and avoiding that suppliers get a monopoly. The board never replied, but in October 2005, Henning Mølsted from the newspaper Ingeniøren phoned me and asked for an interview. His article created a media debate, starting with the actual problem, but soon becoming a fruitless debate where some said that EHR didn't work at all, others that it worked very well. As usual, the disagreement was that people didn't discuss the same issue. Some people talked about the big problems that didn't have a solution, others about things that worked well, e.g. the sub-system for medication.

At the EHR conference at Nyborg Beach, October 2005, Esben Dalsgaard from the board said that he agreed with my comments, but what I asked for, wasn't the board's responsibility. Unfortunately, he is probably right. Important government problems often end up in a gap, in such a way that everybody assumes it is someone else's problem. IT architecture is apparently one of them

2006: Assessment of future EHR platforms

At the beginning of 2006, people from the ministry of health and from the regions, discussed how to connect Denmark's many EHR systems. I was involved in the debate in many ways, and in June 2006 I released a note on the economy and other aspects of the various solutions. Basically three solutions were debated: (1) Merging the systems within each of the 5 new regions into one. (2) Connecting the existing systems with SOA (Service-oriented architecture). (3) Migrating all existing data into one new "platform", which basically was a database. On this platform, you would gradually build user interfaces suited for each of the many medical specialties.

A mistake that had blocked progress was that stakeholders believed that each medical specialty needed its own system with its own database. The idea to have one database with many user interfaces, was incredible.

What would the cost be for each of these solutions? Surprisingly, it would be 2-3 times more expensive to go for solution 1 or 2, than going for solution 3 (one new platform).

I also looked at other factors than economy, e.g. data migration, needs for specialists, education and transfer of staff, acquisition of new modules or equipment, supplier monopoly. Everything pointed at solution 3. Further, I outlined a time schedule for implementing solution 3.

Details of the three solution are in this report: Download solutions (pdf, Danish)
Details of the financial calculations are here: Cost calculation (xlsx, Danish).

So what did they decide? Nothing. Each region made small changes. Not until 2013 did any major change take place: Two regions acquired EPIC and made it their common platform for all EHR in 17 hospitals. See Acquisition of EPIC below.

Health record with lab results and patient services
Health record with lab results and patient services

2007: Graphical and customizable health record system - Uvis

In 2007 I got funding for a project that would develop a tool (Uvis) for end-user development of interactive, graphical user interfaces. We assume that these end-users understand spreadsheets, but they are not programmers. We would also prove that the tool could be used for health record systems with local customization in the hospital departments. When we started the Uvis project in 2007, we based it on Windows .NET. At that time, the web was not suited for data visualization. This changed during the project with the arrival of HTML 5.

In 2011 we had an operational prototype of the entire system, and we had tested that spreadsheet-level end-users could use the tool for development. We had shown Uvis to several suppliers of health record systems and to some software houses. They could see the potential, but their present focus was expanding their products with web and mobile user interfaces. It wasn’t obvious how Uvis could be ported to these platforms. Some of the companies said that if the system had been for the web or a mobile platform, they would use it right away. See more on the tool - or try it yourself: Data visualization and EHR

2013: Anonymizing a large health record database

As part of the uVis project, we anonymized a relational database of 300,000 electronic health records. This was much harder than anticipated. Structured data in the tables were relatively easy, but identifying data could also hide in free-text notes. We also had to ensure consistency so that data still gave a correct picture of the patient's medical history: Preserving medical correctness . . .(pdf, 13 pages, 2016)

2014: All medical data

Funding for the Uvis project ended in 2013, but Lauesen and Søren Lippert (former heart surgeon) continued on an informal basis. We developed our own version of a full health record database - just to prove that it is possible to cover medical data for all specialties with a small number of tables. Other systems have more than 100.

In 2014 our health record database included all kinds of medical information: 27,000 diagnoses, 17,000 kinds of lab tests, 17,000 kinds of clinical activities (including X-ray pictures, etc.), tables of clinical users and organizations. The table of medicine types is supplemented with a table of 13,000 drugs with trade names. Patient-specific data is covered by 10 tables. One thing we didn't try to cover was billing and accounting. In total the system comprises 26 tables, including simple tables such as a list of urgency codes.

The figure shows a patient lifeline including doctor's notes, diagnoses, medication, lab tests and other kinds of service. Services with numerical results are automatically shown as a simple line graph, other services as boxes. Some services can be shown in a special way when you click their box. There are additional screens for ordering medicine, giving medicine, ordering services, etc. In total around 20 screens, all made with Uvis - and without programming.

Troubles with acquisition of the EPIC health record system

In 2013, two Danish Regions (Copenhagen and Zealand Region) signed a contract with the American EPIC company about acquisition of EHR systems for the region's 17 hospitals and 40,000 health-care workers. EPIC had been selected in a tender process where 3 suppliers had sent a proposal. The system was deployed at the first hospitals in mid 2016 and the last hospitals at the end of 2017 - on time and budget.

However, many users were annoyed with the system, productivity was low in many clinics, and at the end of 2019 no financial benefit had been reported. Rumors were that the wrong system had been selected. What went wrong? The short answer is: Many things, e.g.: They used the wrong selection criteria, although it looked right on paper. They deployed too much too early and didn't adjust the deployment process. They didn't plan the new work processes for individual clinics. They deployed the system with insufficient support and training. You can see the details in these papers:

2017: Soren Lauesen: Damages and damage causes in large government IT projects. Damage case stories (pdf, 59 pages). This report investigates 5 large, troubled projects. What went wrong and how to prevent it? The EPIC project is Chapter 5.

2017: Soren Lauesen: Why EPIC was chosen and the consequences. This paper investigates how the customer selected the health-record system EPIC, and why they didn't realize that work with the new system would be much slower in many of the medical areas. Choice of EPIC - in Danish (pdf)

2017: Soren Lauesen: Time study of EPIC in the clinic: The paper contains Lauesen's detailed time study of consultations in an endochrinological clinic that had used EPIC for about a year. Around 40% of the time was spent by the doctor clicking and typing without patient contact. Around 30% was spent by doctor and patient jointly looking at the screen (great!). Changing the patient's medication dose required 25 clicks. The average observed consultancy time was around 18 minutes. The department budgets with it being 15 minutes. With the old system, the time was 10 minutes. Download report - in Danish (pdf)

2017: Oliver Metcalf-Rinaldo and Stephan Mosko Jensen: Learnings from the implementation of EPIC. These reports describe the many accidents when deploying EPIC, e.g. lack of user training, slow update of the patient's medication data, medicine orders that disappear. Learnings from implementation of EPIC (pdf, 54 pages),   Appendix (pdf, 27 pages)