What would it look like?

With the increasing complexity and fragmentation of Primary 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
The patient is seen after a previous presentation or after an episode of treatment for followup. 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 Rheumatic 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.
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.
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.
Silos
If anything, the barriers to communication between systems have worsened in my clinical lifetime. Administrators have become ever more paranoid about security and have put up ever more barriers to access. They appear not to consider the cost and harm of poor communication. In developing the NT Government Acacia system, there was no budget for interoperability or communication with outside systems. Records remain “siloed”. Communication 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. In the multimorbid patient, treating every condition “to target” may impose an impossible burden of intervention on both patient and clinician.
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. If such an approach is to be feasible, the Record itself must be able to be used efficiently.
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 in most EHRs are not particularly intelligent or flexible. The number of Recalls generated can rapidly become overwhelming, making these systems 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. The Record must keep a copy the referral or provide information for the other provider to act on. Much of the inefficiency in Primary Care nowadays is related to policing (rationing!) access to various resources or interventions 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.
Business Processes
There is a constant process of Business Rules and Policy review in large organizations. Committees are hard at work adding new rules and policies all the time. After an adverse incident, new so called “quality initiatives” are often added – these may actually worsen quality and safety. The relevant clinicians are required to undergo “training” while the systemic issues underlying the event are ignored. The new initiatives usually add yet more complexity and overhead to the work of the clinician and “noise” in the record. There does not appear to be a parallel process and review and rationalization and so complexity builds over time.
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 an often 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.
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. Surprisingly, the client is often reticent about prompting the clinician with past history – presumably they expect this to be available in the record.
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. (This remains to be definitively shown IMO) 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. A corollary of this is that the record must be usable by Expert Generalists.
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.
Break down Silos
This remains a perennial chestnut, yet to be resolved. There appears at last (after more than 20 years) to be a push for Open Interface standards in the use of FHIR as a messaging system. This of course could have all been avoided (and FHIR would be unnecessary) by agreement on system interoperability many years ago.
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
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. Changes which require software rewrites are charged at expensive and often extortionate rates. (See my articles “Why is Health IT so hard?”, “Complexity in Software Design” and “Software Design in Health”.
These rates could be reduced if the “barrier to entry” for new players was reduced. But large vendors resist standardization and interoperability to maintain “vendor lockin”. Old “Legacy” Software systems are effectively frozen due to poor software design and maintenance over time and thus are genuinely difficult to modify. An Open Source system could overcome all these issues, though it would take time and effort to develop. 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.
