Originally, when I started my thesis, I was planning my output would be to create a better version of the software my GP uses (which was as I discovered, an EMR system). However, during this research phase I found problems in Health IT that I could not ignore.
To create an EMR system for the NZ market would be both out of the scope of my thesis (it'd take a team of people, years of time, and a lot of money), but most importantly, it would do nothing to tackle the underlying problems I discovered in my research. A new product would have little impact on NZ's Health IT, as the challenges of Complexity, Risk, and Distribution would remain.
Instead, I've decided to take my output in a unique direction. I'm going to create a design proposal for a unique, experimental EHR system. I have some clear goals I want to focus on:
There is no value in making a design proposal of something which is similar to existing software. The opportunity is to explore and propose ideas which potentially have a high impact on Health IT. I'm going to be focusing on new technology, and how existing technology could be leveraged differently to design an EHR system.
My output is going to focus entirely on the problem of managing healthcare records. This is how are they stored, shared, and interacted with - and nothing else. This means the scope of its functionality is quite limited, for example it won't do things such as appointment management, staff scheduling, invoicing, etc.
This is for a few reasons. Firstly, as complexity grows, so does cost and risk. Secondly, this aims to make distribution easier - if an institution needs to replace my system in the future, it has a much smaller scope of functionality, and therefore is easier to replace. And thirdly, because it aims to be general purpose.
The value of software with a scoped focus has been long understood in the world of software development. In the original UNIX philosophy from 1978, the first rule was "Make each program do one thing well." (McILroy, 1978). This rule has been long celebrated and has been re-worded into every subsequent UNIX philosophy.
Healthcare software is currently designed and built around the needs of institutions. If my output aims to be focused on the general problem of health record management - then it should be usable across institutions.
In every design decision, I will try to tackle the larger issues I discovered in my research - The challenges created by Complexity, Risk, and Distribution. My output is a response to these issues.
It's been well discussed that the issues with distribution impede innovation (Coiera, 2004) (Rudin, Bates, & MacRae, 2016) (Beasley, Holden, & Sullivan, 2011). How can my system be designed to enable faster distribution, with less socio-technical impact? How can my system reduce the inherent risk of healthcare software? And how can complexity and variety be managed?
An EHR system is a complicated piece of software to design. Instead of tackling it as a whole, I've decided to split the problem up into 4 separate areas:
Storage Format - How do you represent healthcare information in an EHR system?
Authentication & Privacy - How do you verify that somebody is allowed access to a record - and how do you protect the patient's privacy?
Networking - How will the record be transmitted and shared between all parties?
User Interface - How does the end user interact with this system - and how would software interact with this system? Dissatisfaction with existing interfaces was a common theme discovered from my user research.
While there are interactions between these areas, they clearly divide the problem up. This way I can conceptualise and iterate upon smaller problems faster, select the most successful outcomes, then combine them to create the final system.
For each area, I will be following a traditional Double Diamond design process (Design Council, 2015). However, as my User Research has already been done, and my focus is defined - I will be focusing on the third section of the process 'Develop'. I will be conceptualising, and critiquing a broad range of potential solutions.
When assessing how successful concepts are, I'm looking at three separate qualities, which relate to the goals discussed in the brief:
Potential impact - Could this idea have a large impact on NZ health IT, and more specifically, how could it address the three issues of Complexity, Risk, and Distribution?
Feasibility - Is this concept reasonably achievable? I don't want to create a design proposal for a system which wouldn't be able to be built. This project is not a speculative design project (Auger, 2013) - all concepts must have firm evidence of feasibility.
Uniqueness - While I will look at existing solutions to these problems, there is opportunity and value to assess unique approaches.
So, with that out of the way, let's move onto the logically first problem to tackle - storage.