healthcare – TjilpiDoc

A Functional EHR

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”.

Why is Health IT so hard?

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

Corporate Dementia and the Health System – is AI the solution?

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.

Corporate Dementia and the Health System – is AI the solution?

The health system is suffering “cognitive decline” due to anonymous consultations and poor continuity of care. Clinicians often ignore past medical history, leading to poor management of complex multimorbid patients and an increased rate of Clinical Error. Smart design of electronic health records and the use of targeted AI applications could enhance data visibility and improve patient care, reversing this decline and fostering continuity.

As I age I start to worry about dementia. Yes, I forget names – but generally if I wait a few minutes they will come back. But I am concerned for the Health System – it appears to be suffering from cognitive decline. It is now routine for clients to be seen by clinicians who have never seen them before – the “anonymous consultation”. With the loss of traditional General Practice, ubiquitous but poor quality electronic medical record systems and increasing staff turnover everywhere, continuity and client relationships have suffered. Past history is “forgotten” – diagnosis relies on the presenting symptoms and observations. Clinicians are less sophisticated than they were – they are not likely to consider alternative diagnoses such as masquerades and unusual presentations. Multimorbidity is less well managed by the “anonymous” clinicians as they struggle to learn the detail of a complex client. Expertise and the knowledge of and a relationship with a client has been replaced by complex rituals of checkups and Careplans, items and counterchecks. But important issues still seem to fall through the cracks – it appears these systems are not a safety net. Lumps that should have been investigated and removed are forgotten for years before they are finally dealt with. Or perhaps they are never confronted and the patient dies – even then the potential cause is not identified. Clients may present repeatedly with the same issue with the system apparently not remembering previous investigations and outcomes.

At a policy level the constant loss of corporate knowledge due to turnover means that the same issues come up again and again – they appear to be immutable – the previous solutions and outcomes have been forgotten.

Does Past History Matter?

We spent a lot of time in our training learning a systematic approach to Medical History. A major part of this was obtaining past history. It was regarded as an important predictor of the likely diagnosis on the presenting occasion and there were often other issues that required followup. For a complex multimorbid patient it was important to obtain a full picture of the clients medical history to plan and prioritize interventions. But it appears from the behaviour of many clinicians that this is no longer regarded as important. Past history is almost routinely ignored and the client treated for their presenting complaint. The system relies on programmed interventions such as Careplans to manage ongoing issues. But these are far from perfect – in practice they cannot be easily tailored to an individual and in many cases relevant past history is missed and forgotten. Clinicians are encouraged not to think independently but to just follow the prompts. In a previous article I discussed Complexity in Medicine – if indeed many clients can be regarded as “Complex” then a programmed approach is likely to fail. Good management of Complex Multimorbid clients (the majority of those over 40) requires a map of their issues and a tailored “thinking” approach at every encounter. When serious lifethreatening illness presents, it often does so over several clinic visits over several days. When mistakes occur in this situation it is usually due to different clinicians not referring to the events on previous days – again, Past History Matters.

What is AI ?

AI (Artificial Intelligence) is the buzzword of the times. But many people dont have a clear understanding of what it means. There have been massive advances in this field in the last 20 years and it continues to rapidly evolve. Essentially it involves several large datasets. A suitable dataset is separated into categories with the desired outcome. This is then used to “train” a mathematical algorithm as a “black box”. Once the model has “learned” the pattern to an acceptable degree, it is supplied with “wild” data to achieve the same outcome as the training dataset. These AI algorithms involve many simultaneous multidimensional calculations similar to 3D games – hence the use of video chips optimized for this. The American company Nvidia has seen its shareprice skyrocket – it started life as a video card and chip maker. More recently there has been a proliferation of LLMs (Large Language Models). These incorporate large numbers of language concepts and the relationships between them. They form the basis of smart chatbots and assistants for tasks as diverse as programming to marketing. These can ingest large amounts of data such as text and extract relevant concepts from them.

The search problem for clinicians

If we accept that Past History does matter, then the first task after the elucidating the presenting complaint from a client is to obtain a past history. The clinician encountering a complex multimorbid patient for the first time must try to get a complete Medical picture of their client. They are searching for “anything” relevant. This involves interrogating the patient and the medical record for important concepts . These are found in letters, pathology and imaging results, progress notes and documents. If the clinician is lucky, a previous expert clinician has created a summary of the relevant issues. The search may involve working across several record systems and interfaces. But this remains difficult due to silos and restricted access due to security concerns. The situation has not improved in recent years – major development projects have not allocated resources to interfaces and vendors remain resistant to interoperability for commercial reasons. In general the record has been designed by bureaucrats searching for specific data – they have a different search problem to the clinician. Data is hidden in easily searchable “items” rather than free text (which is frowned upon). There is poor interface design, with lots of irrelevant headings, poor formatting, poor labelling, administrative entries and many “null” values. A clinician has to search this very “noisy” environment for relevant data.

How do we record a Clinical encounter?

It is important to record what happens in a clinical interaction for various reasons. Perhaps the most important is Clinical, to assist with future clinical interactions. There is also a legal imperative in case the encounter should be contested in future. Here, too much detail is never enough and this drives much of what is in the record. Third, the record is used for administrative and research purposes. Again this drives much of the content of the record even though it’s primary purpose is ostensibly clinical. How to record all this? The ultimate is to take video of a consultation. This is not performed often for many reasons including consent, storage and clinician resistance. In most cases a written account is entered by the clinician into an electronic record, with details of demographics, items describing various actions and measurements and free text “Progress notes” describing the interaction. Finally, most systems enter a “reason for encounter’ which may be multiple. Here codesets such as ICD or ICPC2 form the basis of a picklist. So an encounter can be described in various ways, from a full video to a single code.

Possible Use Cases for AI

(1) A “Past History Engine”

Could an AI generated Past History summary help the Clinician searching the record of a “Complex” patient? Could it prompt the less sophisticated Clinician with relevant information?

Large Language Model (LLM) based systems are now being widely used in various areas of commerce and legal practice to extract relevant concepts from large datasets of text. It would be possible for such a system to ingest an entire medical record with associated documents and even the documents linked to other systems. It does so much more efficiently than a human – in fact it may be impossible for a human clinician to perform this task efficiently in a large record with hundreds of entries and thousands of data items.

Territory Kidney Care

This system was set up to provide a summary of the past history of the many clients in the Northern Territory of Australia (NT) who were suffering from or at risk of renal disease. The aim was to help clinicians in managing them and to provide an early warning of deterioration by automated prompts. Some 10,000 clients were entered onto the system. Data on these clients was obtained from various sources with the relevant consents of their treating organizations. Data included problem codes, clinical measurements, pathology results and Medicare billing – this was entered into a single database which in turn was interrogated to provide a summary and timeline of various parameters available via a web interface. This effort was privately funded and mentored by a well known research organization. It cost a small fraction of typical comparable record systems (approx 1% of the cost the NT Govt new system Acacia!). The web interface was designed by a Darwin company – it was clean, simple and easy to use. While this was not a full Electronic Record System, it did show what was possible at minimal cost and with good interface design. By contrast, Government Health IT systems are typically expensive and difficult for users to navigate.

This system did not use AI – just basic data algorithms and clean interface design with minimal administrative “noise”. It also overcame the apparently intractable problem of getting data across interfaces between different systems – data was obtained from most of the large Health organizations in the NT. It gave a useful insight into where clients were attending.

If such an approach was broadened into large record systems and an algorithm based on an LLM to mine all the text into the record, we could obtain a good summary of a client’s past history. This would improve clinical management, efficiency and safety. It could go a long way towards providing the continuity that has been lost in modern Health systems

(2) “Recall Engine”

One of the mechanisms used in records to maintain continuity is the “recall”. It is entered for a specific date in the future with details of the clinician targeted and the actions to take. But current systems generate large numbers of often poorly targeted or incorrect recalls. The recall may be “serviced” but not removed or become unnecessary. As a result of this large (even overwhelming) number of recalls the system is difficult to use and is often ignored altogether. In my own surveys of records, outstanding recalls are not serviced in the majority of encounters. Could a smart or AI enabled system improve this situation? It could be based on the “Past History Engine” above and generate a minimum of recalls that are relevant and targeted. It could also generate a single optimized “Careplan” based on their known problems for the client with relevant planned interventions.

(3) Location

In a large system of clinics such as NT Government Remote Health, a particular client has a “usual clinic” which is tasked with delivering scheduled interventions such as Careplans . But many people visit several clinics, often in different health systems across borders and with different provider organizations. Some are “transient” with no identified clinic “owning” them. These tend to be a high risk and high needs group. One approach to service clients better would be to adopt an opportunistic approach to care and deliver all interventions wherever they present. But if we are to persist with the “programmed” approach we need to identify which clinic the client should be attached to – all clients, transient or otherwise, should belong to a nominated clinic. An AI algorithm looking at time series location data could possibly predict where the person is next likely to attend and target relevant interventions there.

Conclusion

The Health System is suffering from cognitive decline driven by increasing staff turnover and administrative complexity. Electronic Health Record (EHR) systems are not up to the task of replacing a long term relationship with an effective means of maintaining continuity. This decline could be reversed with changes in policy and business rules, smart EHR design and targeted use of AI to improve data visibility and prompt clinicians appropriately.