What would it look like?
With the increasing complexity and fragmentation of Health Care, the EHR (Electronic Health Record) becomes ever more important as the vehicle for continuity of care. For better or worse, the Days when a single family GP delivered the majority of a patient’s Primary Health Care, with the medical record held in the Doctor’s head with a few prompts on a 6X4 card are long gone.
Primary Health Care in many environments is now delivered by a team. As the title of this article suggests, I dont believe that EHR systems are currently delivering good outcomes in safety, efficiency and quality of care.
EHR Use Cases – What is the EHR used for?
Clearly, in order to design a record system, we need to know how it is used. There are various views on what the record should contain and how it should be configured.
One view can be obtained from NSW Govt Health policy, “Health Care Records – Documentation and Management Summary”
“The main purpose of a Health Care Record is to provide a means of communication to facilitate the safe care and treatment of a patient.
A Health Care Record may also be used for:
• communication with external health care providers
• communication with statutory and regulatory bodies
• facilitating patient safety improvements
• investigation of complaints
• planning
• audit activities
• education
• research (subject to appropriate authorisations)
• patient reported measures
• booking and scheduling of patient care and treatment.”
Thus, the Primary Use Case for the record is Clinical – ie to facilitate the delivery of safe and effective Health Care. But there are many other use cases with differing requirements.
For example, legal uses such as communication with statutory bodies or investigation of complaints demand extensive detail which may not be necessary in clinical care. Administrative users or users auditing the record have different requirements again – they generally want to search for a particular activity or measurement.
One might expect that all these users would have a different “view” or interface with the record. But in practice in most systems all users look at the same interface.
This is problematic for clinical users.
Clinical Use Cases
Undifferentiated presentation
In this scenario, a patient presents with a new issue which has not yet been diagnosed or defined. Many emergency presentations fall into this category. Sometimes the diagnosis is obvious – eg a broken arm after a fall. But usually the presentation is less specific – “I am feeling tired all the time” or “I have pain in the stomach”. The clinician assessing the patient will obtain a presenting history and examination which may suggest a specific diagnosis but more often will only narrow the field of diagnostic possibilities. For many conditions, the best predictor of the diagnosis is a history of a previous episode or risk factor. Thus, Past History is important. The clinician will need to search the record for “anything” relevant ie he/she in general will not be searching for a single specific item. Many symptoms occur repeatedly – they may have been investigated or treated in previous episodes – this will guide current interventions
Review
This scenario is simpler – the clinician will be looking for the record of the encounter that relates to this review. But often the relevant information is held in other systems – eg a review after a hospital presentation
Complex Chronic Disease
The majority of patients over a certain age are Multimorbid – ie they suffer from multiple Chronic Medical Conditions, with many not easily amenable to improvement by intervention. Here the Clinician must compile a map of the various conditions and decide what interventions are possible and useful. It is important to know what has been done previously and the outcome. Ongoing review and continuity are critical to the effective and efficient management of these patients. A Problem Summary should be easily visible on opening the record. There is often disagreement as to what should go here – as it is generally “critical real estate” it should only contain current significant issues, and not be a record of past history. Different EHR systems vary in the quality of this summary – some have no explicit summary at all.
Programs
Many Health services are delivered as programs – eg Rhematic Heart Disease, Trachoma, Immunization. Even here, the clinician may need a broader view of the client to assess the risks of delivering the service. Certainly, they will need to know what has already been delivered and when. Often there are many ways of recording a service, making it difficult to know what has already been done. Immunization is an example – details of previous immunizations may be held by other providers or in Remote databases.
Multiple problems
It is common in Primary Care for a patient to have a “shopping list” of issues which come from any or all of the above categories. It is critical to have a good record for the efficient management of this scenario.
Legal Use cases
Certificates
The records in this case should justify the certificate – in general not much detail is required
Licensing/Reports
Various Licences (eg vehicle, gun licence) may be issued in Primary Care. Reports for insurers are often requested.
Specific criteria such as vision may have to be satisfied – generally these are laid out on the relevant form. Some licences or reports may require a detailed search of the records. If the record is difficult to search, this creates legal risk for the clinician.
Complaints or Legal action
Here, too much detail is never enough. “If it is not recorded it didn’t happen”. Many clinicians try to pre-empt any complaint with exhaustive detail – this is inefficient and creates “noise” in the record. Because many encounters are anonymous (patient and clinician don’t know each other) there is often an ID process mandated by employers at the start of the record of encounter. This adds no useful clinical information but again creates “noise” which appears in any short summary of the consult and obscures useful data.
Audit, Administration and Research
Ideally these activities should occur in a way transparent to the clinical user. But this ideal is usually not achieved. Employers may mandate a “reason for access” note for anyone accessing the record, even though this access is usually logged elsewhere. Administrators may require particular activities to be stored in an “item” which makes them easily searchable, but adds “noise” for anyone doing a general search. Relevant data may be stored in the “item” requiring it to be opened specifically to view the data. Administrators may require exhaustive detail in the item, which when it is not filled, is still displayed as “NULL” values.
Administrative processes such as appointments, billing and travel should not usually appear in the record at all but often there are many documents relating to these cluttering the record.
Silos
Records remain “siloed” in various systems. Government clinic and hospital records are generally not available to outside users due to security concerns. Communication between these various systems is generally via letter in pdf format which is not amenable to direct import as atomized text. There has been some attempt to connect systems using a “third party”, such the NT SEHR or MYHR. These may contain relevant data but searches are very inefficient due to poor formatting, multiple levels of dialogs and huge amounts of irrelevant “metadata” and headings. It is a very labour intensive and inefficient task for a user to search between systems
The rise of the machine – programmed care of fragments of the patient
In recent years the idea that many conditions can be managed and outcomes improved if various parameters such a Blood Pressure and Lipids are “treated to target” has gained traction. The multimorbid patient is not considered in this approach. “Treatment Inertia” in particular by doctors must be overcome. Interventions can be performed by less sophisticated clinicians according to a “Careplan”. There is some merit in this argument, but for it to be successful, we need a well functioning record system connecting the various providers. The downside of this approach is that the patient is effectively broken into “parts”, with different providers treating different issues.
Opportunistic vs programmed care
An alternative approach is to deal with “everything relevant” when the patient client presents for any reason. This is more efficient in that the patient does not have to summoned or transported to the clinic. The down side of this approach is that the patient may have attended for a “quick visit” and not be open to dealing with other issues. The clinician may be overwhelmed with many presenting patients and be unable to undertake more than managing the presenting complaint. Clearly it is important deal with their presenting complaint but an efficient process that looks at the “whole patient” can actually more efficient and effective in the long term. The Clinician involved must be an “Expert Generalist” who has the skills and authority to look at the record in detail without being necessarily guided by prescriptive recalls and deal with all relevant issues including prevention.
The Recall
Programmed care relies on a system of communication between the various providers in the system to alert them to the various interventions required. Even in standard clinical care there is often a need for review and “safety netting” to ensure an intervention is successful and that the patient has not deteriorated. A recall is generated to prompt users as to what is required. There are a huge number of different types recalls available in the system. These may be scheduled far into the future.
Careplanning
It is quite difficult to show benefit from Primary Prevention – see my article on this in “Get Your Checkup!” https://tjilpidoc.com/2023/05/29/get-your-checkup/
But there is good evidence that secondary and tertiary prevention is effective and improves Health Outcomes. This activity targets known conditions or risk factors. It is thus important that these are not forgotten – a common issue with current systems. A schedule of interventions can be devised to treat a single or combination of issues – this is called a Careplan. Unfortunately,the systems used to devise both Recalls and Careplans are not particular intelligent or flexible. The number of Recalls generated can rapidly become overwhelming, making this system unusable and often ignored.
Efficiency/Productivity
In Health I am vastly less productive in terms of real assessments or interventions than I was when I first started Medical Practice in 1979. This loss of productivity appears to apply to the whole Health System. This is due to increasing complexity and inefficiency in accessing data such as past history, and inefficiencies in actions such as prescribing, investigation and referral. Indeed the very act of referring a task which I used to perform myself to another provider creates inefficiency. Much of the inefficiency is related to policing access to various resources on behalf of others, such as “navigating referral pathways” or prescribing medications that are subsidized by the PBS. Efficient processes in the Medical Record would go a long way towards reversing this declining productivity.
EHR Interface design
I have discussed this previously in “Software Design in Health” at https://tjilpidoc.com/2023/01/05/software-design-in-health/
In a competitive commercial environment such as mobile phone apps, usability of the interface is everything – users will not take up the app if the interface is not well designed.
But there is not the same commercial pressure in Health IT systems – users are “captive” to a poorly functioning program.
Some principles of User Interface design
Simplicity Principle – This means that the design should make the user interface simple, communication clear, common tasks easy and in the user’s own language
Visibility Principle – All the necessary materials and options required to perform a certain task must be visible to the user. A good design should not confuse or overwhelm the user with unnecessary or irrelevant information.
Feedback Principle – The user must be fully informed of the actions, change of state, errors, condition or interpretations in a clear and concise manner without using unambiguous language.
Tolerance Principle – This simply means that the design must tolerant and flexible. The user interface should be able to reduce the cost of misuse and mistakes by providing options such as redoing and undoing to help prevent errors where possible.
Reuse Principle – The user interface should be able to reuse both internal and external components while maintaining consistency in a purposeful way to avoid the user from rethinking or remembering. In practice this means data used in several locations should only be entered once and the interface has consistent appearance and behaviour.
In all the various Health IT systems that I have used, the User interface does not appear to conform with many of these principles. Typically, the program is complex with multiple layers of dialogs, redundancy of headings, poor use of screen “real estate”, poor formatting of dialogs, and displays of multiple “null” values
Often a lot of irrelevant “administrative” information is displayed. The end result is poor usability and poor “data visibility”. Important clinical data is hidden in layers of dialogs or poorly labelled documents.
These failures reduce efficiency and user satisfaction and increase risk in an already difficult and at times dangerous Clinical Environment.
What to do?
Acknowledge the issues
This appears to be the first, major barrier to improvement – accepting that poor record systems are a safety, efficiency and productivity issue. Once this is established, we need to accept that complexity, “noise” (unnecessary and irrelevant data), and interface design are important. Many of the problems are related to business rules and policy. Items and policies build up over time, with no review or rationalization. There is a need to “close the Quality Cycle”, and review these changes. After an adverse incident, new policies and so called “quality initiatives” are often added – these may actually worsen quality and safety. Certainly, they add complexity and “overhead” to the work of the clinician and usually increase the “noise” in the record.
Value continuity
Health encounters are now more often than not, “anonymous” – ie clinician and client do not know each other. This means the clinician must rely on history from the client or the record for relevant information. The clinician will have no memory of the client to help with their assessment. Business processes can be improved to value and improve continuity (eg ensure that the patient sees the same clinician on subsequent visits)
Value “thinking” and Generalism
There have been attempts to codify Clinical Practice into plans and guidelines in recent years so that unsophisticated clinicians can deliver care. Items may have exhaustive detail as to what must be entered by the clinician. This creates complexity and noise in the record. This approach is said to improve consistency and safety. But there remains a stubborn residue of clinical issues that defy codification – to resolve these, the Clinician must resort to Clinical Reasoning by first principles and a broad general knowledge. This should be acknowledged by policy makers – there is still a need for clinical “experts” and that not all practice can be reduced to a set of guidelines.
Simplify processes
As stated above there should a robust Quality review process to rationalize, simplify and remove Careplans/recalls/options/items where appropriate. Options should be reduced to a minimum to ensure more consistent use.
Design a more intelligent process for recalls and Careplans
One idea is to reduce all recalls to a single one with details of date, clinician and most importantly the reason(s) for the recall. When this recall is serviced, another can be generated if required.
A recall prompt could be made to appear at the end of the consult in the process of closing it.
The clinician would be forced to create a recall unless there is explicitly no need for it.
More use of “push notifications” to both clinician and patient could be worth trialling – SMS and email is widely used for this purpose in other spheres.
Abstract legal and admin processes
These records should be separated into another layer which is visible separately
The Clinical Record should be regarded as “precious”, not to be polluted with data not directly related to Clinical Care.
For example, ID protocols and “reasons for record access” should be in a separate log which could be accessed as required.
Travel, referrals and appointment data could be held in a dedicated web interface which could be accessed, viewed and edited as required by suitably credentialled users. Currently this is managed by multiple verbose, poorly labelled messages which clutter the record
Of course, this would require the cooperation of outside agencies such as hospitals and Government, which may not be easy to obtain.
Redesign of the User Interface
Changing Clinical Record Systems is usually slow and expensive. It requires multiple committee deliberations to achieve even the smallest change. Most large enterprise systems are held by Commercial Vendors and the user is essentially “locked in” and captive to these systems. (See my articles “Why is Health IT so hard?”, “Complexity in Software Design” and “Software Design in Health”.
Significant changes to a user interface would involve major code revision in most cases, but it should be explored after the above changes to Business Rules
Could AI be the solution?
I think this will be the way of the future – see my article on one idea at
AI could be used to extract a summary of relevant issues from a mass of noisy data, including sources outside the record. This would overcome the “anything relevant” search issue for clinicians
Using this data, the system could devise suitable recalls and careplans.
While many would argue that this would be prone to error, it is likely to be better than the current situation.
AI assisted coding massively improves a programmer’s productivity – this could be used to develop an entirely new system with high quality code and testing built in.
TjilpiDoc 