Developing software for healthcare has three main issues
Healthcare is complicated, and always changing. As healthcare has become more effective, it's complexity has increased. The information stored in medical records, and what the user needs varies accross location, role, enviroment, context. Regionally software is bespoke, and unique - and will continue to change in the future.
Healthcare is risky. Managing risk is tricky, but software failure is unacceptable in healthcare. Design software which is robust, and well tested, is necessary.
Healthcare is becoming team based. Healthcare information is transforming from single institutions to a 'team' of doctors around a singular patient. This is a fundamental change in our healthcare system, and cannot be slowly integrated into our existing system
Barnett is an experimental EHR system. It's experimental because it's a theoretical design, of a system which has considered the application of cutting edge technology, and new ways of solving old problems from it's core. It is still just a design proposal, and hasn't been built.
Barnett doesn't aim to be just software - it aims to be a system, for the management of medical records. Atul Gawande has defined three skills a good system requires:
Barnett aims to achieve these through extensibility. It's impossible to design software which is perfect first time. Even if you did make something 'perfect', it would be out of date in a few years. Barnett instead focuses on being easy to change - allowing changes to be developed much faster, and the system improved through an iterative process.
Barnett is designed to be a general use EHR, however it's main focus is primary care - as primary care is where the majority of effective, cheap healthcare occurs. It however, does not include all function of a PMS (Patient Management System) - eg billing, staff management, referrals, acc forms, etc. My view is that is outside of the scope of medical records, and should be handled by another integrated system. By splitting up the functionality, it allows small, quick changes to be built faster than dealing with a whole PMS.
A patient's health record is broken into modules. Modules represent just a small slice of a patient's health. For example, one single module would be for demographic info - name, age, NHI, contact details, address. Another module is for the medication list - what medications the user is taking, how much, what for, etc.
Ultimately patient's have very different information that needs to be stored about them, and the importance changes. For example, a newborn has very different healthcare needs compared to an elderly man with heart problems.
Barnett's modules are extensible - there are a few core modules which ships with every record, for primary care usage. However, anybody can define a new module of information to store, and add it to a patient's record. This way the record fits the patient - an ecezma sufferer can have a section for dermatology, but doesn't require a section for cancer treatment, or diabetes. Literally any information a doctor deems worthwhile tracking, can be added.
While there is no regulations on who defines records, it's aimed that national representative groups would define the records. For example, plunket should define a format for newborn records. The Cardiac Society of Australia & New Zealand should define a format for cardiographic information. By segmenting into professions (instead of regions), hopefully formats can be updated faster.
As stated, good systems need the ability to recognize success / failure. Any defined module requires to define a function to produce an anonymized record for statistics tracking, and big data. This provides a high level way to spot issues. Combined with fast updating, this aims to allow groups to spot issues, and implement solutions faster.
Authentication has two purposes - ensuring that the doctor is who they say they are, and only showing them what they have access to.
Modules defined fields
Records are stored on 'nodes', servers which can be connected to by a client - weather that be a GP, Patient, Statistics tracker, Software of some kind, third part o-Auth login, etc.
Nodes come in two types, trusted and untrusted.
A health provider (say a clinic), can set up a node in their clinic, to store their patient's records. It will keep a full copy of all of their records. They also set up a node with a cloud provider, and another cloud provider, and set them up as trusted nodes. These nodes act as duplications of each other - if one record changes in one, the changes are replicated to the others.
This creates a robust private network - in the occurrence of failure, work can continue, the clients just need to find another working node. I like this model because it can be deployed in many ways - want to run a node as a SAAS model, without any physical servers, no worries. Need to deploy servers in a place where theres no external network (eg, a rural outreach van in the poorest countries), can be done easily.
So what happens when the patient goes to a specialist, or the hospital. The clinic can connect it's nodes to the specalist as 'untrusted'. This means they will only sync parts of their records which are considered shareable. For example, a medication list is useful for a cardiologist, but they don't need written, detailed appointment notes. If the specialist say, prescribes a medication, that would get added to the medication list, and synced back to your GP (and every other connected node with your records).
Modules defined what can be shared as part of their authentication
This creates a distributed network of healthcare records - data is spread, regionally first, accross multiple institutions, while maintaining privacy and security. Networks can be grown without control of a governing party - if two institutions see value in sharing information, they can.
When a module is defined, the creator also needs to define a package which explains how the interface is designed. Interfaces are built with standard, reusable components - buttons, datepickers, sliders, etc are consistent across modules.
Modules are viewed in three ways - firstly, in a tab. This is the standard view for viewing and editing information
Secondly, a small widget providing an overview. The majority of healthcare is appointment based - the first thing a health professional needs to do is quickly get to grips with who their patient is. The overview widget should display the key information a new person to the record needs. This includes any warnings (eg, bad heart), but also standard info to get to know the patient (eg, allergies).
Thirdly, a deafult timeline view. Medical records are ultimately a longitudinal record (as in, information over time) - any value in a medical record can change, even a person's blood type can change. Modules would define a deafult view for the timeline.
Beyond that, Barnetts user interface aims to be extensible. User Interface packages can be created, and installed on client software by anybody. So, if a nurse has bad eyesight, she can install a package to increase the font size. If a doctor is annoyed that the button he needs is always hidden away, he could get a developer to write a package to move it. A bad user interface can make great software terrible - barnett aims to allow users to fix their issues.
Keyboard shortcuts are a key part of the interface, and are considered as important as the mouse. Also, undo buttons.
Getting a collection of health professionals to work together without being in the same room, and seeing the patient at different times is tricky, but important.
To tackle this we use MedDown, a writing format to allow doctors to communicate freely, but be precise when needed. It allows doctors to make reference to exact medications, appointments, lab results, etc.
There would also be a general comment board to inform other specialists / doctors of info.
Barnett aims to have a clear focus - manage electronic health records. However, the definition of what a health record is always changing, and who can use a health record is always changing. Therefore, at it's core it's designed to embrace change, via an extensible design from ground up.
Barnett is designed to be an iterative system - issues can be spotted via large data statistics (top down), but also average users (bottom up). Once a problem is identified, implementing, or prototyping a fix can be quick.