My writing on domain-driven design arose because of my own experience building an electronic patient record system:
“A model is an abstraction of the real-world distilling knowledge into core concepts and processes.”
In that development, I was fortunate to use technologies developed by NeXT (and continued by Apple - WebObjects), which enforced a strict separation of model, controllers and the view. Importantly, I learned an important principle: the importance of starting with a data model conceived with a deep understanding of the domain in which I worked in my day job.
It was only later that I read Eric Evans’ “Domain-driven design” which, while not about healthcare, has much to teach us in health information technology about the importance of data modelling.
“There are many things that make software development complex. But the heart of this complexity is the essential intricacy of the problem domain itself. If you’re trying to add automation to complicated human enterprise, then your software cannot dodge this complexity—all it can do is control it. The key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure, which gives the software developers the leverage they need. A good domain model can be incredibly valuable, but it’s not something that’s easy to make. Few people can do it well, and it’s very hard to teach.”
Excerpt From: Eric Evans. “Domain-Driven Design: Tackling Complexity in the Heart of Software.”
A digital drive
It is easy to see information technology as a product rather than what it really is - an enabler of transformation.
How can we deliver transformative change in healthcare using digital technologies? Why does a domain-driven design approach help us? Why and how should we start with domain models?
I suggest that there are five broad principles… my 5 Os of healthcare IT:
Define a clear vision. For example, in Wales, the Welsh Government Informed Health and Care strategy is a very good start.
Then define tangible definite high-level objectives. This should not be “deploy XXX” where XXX is a product you want to deploy, but instead focus on user need - the requirements, the problems you are solving and the transformation you enable. So, for me, in the next 3 months, NHS Wales should:
- ensure laboratory and radiology results and clinical documents are available to all clinical users when they are seeing a patient, irrespective of where those investigations were performed
- identify deteriorating patients on the ward
Your prioritisation list might be different, but those objectives should support the aims in your overall vision. I have a different list for 6-months, 12-months and onwards (a subject for another post).
It is sensible to define a list of all objectives, each a stepping stone on the way to delivering your overall vision. You will need to take into account political and business priorities as well so it is about negotiation, discussion and understanding.
To illustrate this, we currently have a PACS replacement project ongoing. For me, replacing one PACS (picture archiving and communication systems) with another, in the absence of a well argued need, does not meet the standard required. In a resource limited environment, wasting resources without good reason is difficult to defend. Always ask for a compelling reason why something is important! What value do we gain that cannot be achieved in more prudent manner?
Likewise, what is the point in forcing organisations to rip out a patient administrative system to replace with a new “Once for Wales” PAS if each will be configured differently with different information standards? Similarly, if the project to “deploy” the system doesn’t end up providing administrative and clinical staff or indeed the patient, information from across multiple organisations, then what are we trying to achieve?
Your objectives define your work.
Make information technology and the transformation agenda owned by the users.
But who are the users? You need to consider : health professionals, administrators, managers, analysts, the patient, and more!
The users must be engaged, must be empowered to own and drive their work. We need to understand the areas in which there is synergy between requirements from different perspectives and design our enterprise to provide the common tools to solve their problems.
Rather than top-down “You will…”, consider instead “Here are the tools to achieve your goals… do you want help?”
For all users, ask them what they want.
For instance, what do our patients want from a healthcare services that recognises that digital is one way of providing a service? Are you sure that we know the answer to this yet?
Allow debate. Make your work transparent.
Information technology is difficult, so ensure plenty of debate to hear all of the views. There is no right way, but favour solutions to deploy quickly, get software in hands of users early and get feedback, favour an approach that set a foundation for future plans and don’t limit what you don’t know you don’t know. As I have said many times before:
We need to build an infrastructure that explicitly recognises that we don’t have all of the answers, and therefore must support innovation. Such innovation may simply be incremental improvement of existing technology, but also must cope with and embrace the introduction of transformative and disruptive technologies.
We should debate and build in the open. There are few situations in which work, particularly funded by the public, should be behind closed doors. Transparency is key; options analyses of the most appropriate way to deliver solutions to our problems. Like everything in medicine, our decisions are rarely black-and-white, but careful judgements balancing many different options.
Permit failure. Fail fast. Recognise the relative unchanging components and iterate and prototype the components that change more quickly.
How can we develop a “can-do” digital culture in healthcare? Should we clone the “Move fast and break things” culture reporting in technological startups? We need to approach information technology in a different way but we can’t “break things”! We work in a safety-critical environment, but we must recognise that the pace of change and the level of risk can be different at different levels of our enterprise.
In this diagram, we see that our architecture consists of an open platform approach, built using application programming interfaces.
- The data layer contains longitudinal episodic patient data relating to admissions, appointments, measurements and outcomes. This layer may consist of multiple data repositories for laboratory systems, documents, clinical data and aggregate data from across multiple patient administrative systems from multiple organisations. These complexities are abstracted within our architecture as a set of simple open application programming interfaces (APIs). This layer changes the least. A blood pressure in the right arm will always be a blood pressure recorded in the right arm.
- The business logic, services and process/workflow layers provides important reusable services that execute business logic. This ensures that user-facing applications do not make the mistake of embedding important business logic and rules. For example, if access to information needs to be logged, then it is better to perform this at the API level rather than within a user-facing application.
- The user-facing components and applications leverage the underlying platform in order to provide value for users. User-facing applications are most likely to need to change frequently given our technological advances. You should consider these to be relatively ephemeral, taking advantage of new mobile devices and other new technology.
You can see this approach in more detail in my plan for an open platform in NHS Wales :
Without a platform, one ends up procuring multiple systems that need to be connected together, rather than to a common enterprise platform. This results in:
- Data silos: most current products store their data in a proprietary format within that product. As a result, we create multiple silos. If one can access that information and connect it to your other deployed products, you hit the complexity of n*(n-1)/2 data interoperability, in which you have to somehow connect that product to everything else (2 systems need one connection, 3 needs 3, 4 needs 6, 5 needs 10, 6 needs 15,7 needs 21!) so one ends up with a combinatorial nightmare.
- Procurement rules: it is difficult to scale a solution across a wide enterprise as costs hit thresholds for OJEU rules and suddenly, you and your team are committing large sums of money in a high risk deployment in which failure cannot be countenanced.
Instead, think “open platform”!
Scale organically, enthusiasts and early adopters, grow horizontally; get people asking “can we have that too?”, until your solutions are the default, that they make process easier and not more difficult.
It is difficult to support innovation if we cannot tolerate variation. It is easy to assume that all variation across health services is bad, and so it is easy to think you should harmonise people and processes with technology.
Such an approach is wrong. Firstly, harmonisation is a people and processes issue, not technological, and secondly, how can you be sure you are harmonising to raise standards? What if you are standardising to the lowest common denominator? Variation allows you, as part of systems continuous improvement, to innovate, appraise and improve. Conversely, unmeasured and unmonitored variation is difficult to justify.
As such, recognise that information technology is fundamentally an enabler for transformation and that transformation needs to be driven from the bottom-up; imposing a software solution from central diktat rarely results in satisfied users or effective change. Design the health enterprise to instead allow iteration and innovation in a safe way, playing by a well-defined rulebook.
(CC BY 2.5, https://en.wikipedia.org/w/index.php?curid=11484459).
Work with early adopters and enthusiasts and then plan to scale organically, proving benefit using a quality improvement methodology such as DMAIC. Measure!
Projects relating to information technology fail frequently and this is seen in many industries, including healthcare. Healthcare enterprises are complex heterogeneous environments with many stakeholders and significant complexity; mistakes may cost lives. It is easy to assume that, faced with such risks, one should centralise and control and drive change from above, but such an approach actually results in a greater risk of failure.
There is an important paradox in many health services, including Wales, is that there is a tendency to centralise the day-to-day management and delivery of individual products and yet high-level strategic and prioritisation decisions are decentralised, haphazard and dependant on capital funding with little or no consideration or control as to how those projects will fit into a wider technical healthcare enterprise architecture.
The high-level strategic roadmap to deliver our shared vision should be centralised across an enterprise. Similarly, the rules of engagement, the the contractual obligations at a human and technical level that permit interaction with the open platform (API and data standards etc.) should be defined centrally. Conversely, the day-to-day management and delivery of individual projects should be driven, bottom-up, by the users and for the users and scaled out when appropriate.