10 design principles for building electronic patient record systems
Here are my suggested 10 broad principles for building the next generation of electronic health record systems:
- Separate application code from data.
- Data, as in the patient record, must be longitudinal, immutable, federated, structured and meaningful, with a focus on the patient.
- User-facing applications should be lightweight and ephemeral, with a focus on process and workflow. Ideally build your applications out of re-usable components. Applications should almost always be stateless because state should be a function of your data and process models.
- Focus on user need. It subsumes everything else. That means helping professionals and patients to understand and refine their needs, as well as needing to create a culture of continuous improvement. Remember our work will never be complete.
- Build trust. Teams need to trust one another. Likewise, our systems need to be secure-by-design, ensuring consent and transparency are integral to the use of personal data; work to build public trust maximises the opportunities to use data to manage and improve our health services and advance our knowledge and understanding.
- Build platforms and use use open standards, even if you think you only need a single user-facing application. But, understand you are wrong, on multiple levels, to think one user-facing application will be sufficient for your needs.
- Modularisation is key; limit the surface area of interactions between those modules. Allow parallel independent development. That means understanding bounded contexts and two pizza rules. Think contracts: technical (API), performance, reliability, legal, regulatory and cultural. The more people who need to be involved in a decision, the slower you will deliver; your architecture and organisational structures should be designed to streamline that decision making.
- Understand that reliability and risk are not homogeneous across our enterprises. One size does not fit all. Remember that adding more process or checks, particularly if it requires manual checks from multiple stakeholders, can have a paradoxical effect on making systems less safe. Also never forget the frequently forgotten consequences of failure to deliver.
- Adopt a mobile first strategy; always consider multiple channels of interaction for your users and give due regard to digital inclusion. How are our tools going to support different types of users with different needs?
- Focus on developer velocity. The consequences of this is automating end-to-test testing and safety assurance, as well as doubling-down efforts to modularise services. We are not building something that will ever be complete so embrace and design for change.
Let me know what you think.
Mark