Electronic Health Records are clogged full of required fields. These are everywhere from mandatory clinical questions to check boxes when submitting an EKG order.
Although the addition of required fields on forms is done with good intent, I am not convinced it often improves patient care.
The problem is that it is very easy to make a field mandatory without placing much thought into doing so. And nobody seems to remove required fields once created.
As we will see in this post, a required field may get ‘entered’ but that does not always mean the data is actually true.
SUMMARY
1. Why is this field required?
2. Workarounds on paper required fields
3. A rational approach to: digital required fields
3.1 Establish a high criteria to make a field required
3.2 Anticipated Expiration Date
3.3a Allows users to skip completing a required field
3.3b Create an internal audit system to track usage of the opt-out feature
3.4 Show the ‘justification’ for the required field
3.5 Be open to feedback
4. Next steps
1. Why is this field required?
Why is a field required? The doctor said so. The lawyer said so. The other doctor said so. The original paper form said so. The department administrators said so. The EHR administrators said so. The hospital administrators said so. The quality improvement team said so. Some researcher said so. A committee said so. And so. and so. and so.
To me, these are all unsatisfactory reasons for why a field is mandatory.
Required fields can slow down clinical workflows. Especially when the required fields are not normally part of the standard of care for that type of an encounter.
Required fields can generate garbage data. This happens when the only way to proceed to the next step of the form is to complete that field. If the physicians does not have the data for that required field, the only way to move forward is by making something up. This is highly problematic.
Part of the reason we have this issue in electronic medical records is because, when questions were ‘required’ in paper forms a workaround existed.
2. Workarounds on paper required fields
When data is not not available on paper forms, or when clinicians didn’t want to fill in the field (‘because nobody filled in that field’), they leave the field blank. On a computer a ‘required’ field cannot be bypassed.
Therefore, from my observations in dozens of hospitals in multiple countries of students, residents, and in particular attendings - when data is not available clinicians will make it up. This populates the EHR with garbage data.
I think, that those who disagree with this assumption that garbage data is a problem, are either innocent and naive, or suffer from a self-induced blindness.
Back to the paper forms… Here is an example:
On this form we can see that a self-righteous committee thought it was necessary to make a patient’s weight, height, LNMP, and nursing status mandatory for FOR ALL EXAMS[!].
In practice, on a paper form like this the box - MUST COMPLETE FOR ALL EXAMS - is left blank by almost everyone who completes the form. (Except the brand new medical students who fill out every field.) Experienced clinicians will indicate when the patient is particularly heavy and this may be an issue for the radiology department.
An experienced clinician will also indicate if the patient is pregnant, or if there is a possibility the patient could be, and if they are performing a test with higher radiation exposure - such as a CT-Abdo in a 30 year old lady. (side note: the reality is that this question has actually been replaced in many Emergency Rooms departments requiring a blood test to determine pregnancy status for non-urgent scans, rather than patient recall)
The problem of creating a culture where people regularly leave required fields on paper forms blank, or enter garbage information into them on the computer, is dangerous and is how people make mistakes.
If people always skip of the box ‘MUST COMPLETE FOR ALL EXAMS” there will be times when the patient should have had their pregnancy status recorded. Or their nursing status recorded. [I’d classify this problem into a similar category as ‘alert fatigue / alarm fatigue’]
But it doesn’t have to be this way. There is a better option.
The ideal system should ask required fields only when actually required. A process of revision and feedback of forms in clinical use should ensure they only contain those questions that are ‘high value’.
Let’s look at a rational approach to required data fields.
3. A rational approach to: digital required fields
3.1 Establish a high criteria to make a field required
A hospital should create a policy that specifies when a field may be mandatory. The bar must be set high. For instance:
- the data field is required for a mandatory external report
- without it the billing cannot be completed
- the field is absolutely necessary to the test/order/referal being processed safely.
Data that is ‘nice to have’ or ‘helpful’ should not be marked as required. [To help encourage your organization’s physicians to complete the ‘nice to have’ fields, I would recommend that all unneeded and low value fields are removed from the form. This will shorten the form’s length, and in turn clinicians will be more willing to complete the questions requested.
I find there is inverse correlation between the number of data fields requested, and the data actually submitted by the clinician. The longer the form, generally the less data that is willingly submitted.
3.1b What about questions for research?
If the field is required for an approved research study, the hospital must approach this very carefully. A large institution will have many concurrent studies, each with their own laundry list of questions. To add all their required fields at once would bring an organization’s clinical care to a hault.
Required research study questions needs to be managed carefully. Consideration must be given to how many additional questions are being added to the existing workflow.
Perhaps those studies that have a quantifiable impact on the efficiency of patient care should have to pay the clinic/hospital to offset the lost productivity from the study. (Otherwise, studies will create ‘externalities’ in hospital budgeting of time and cash).
Another way to prevent overloading the hospital forms is to sample patients randomly to create the study cohort, and only include the additional or required study questions on their forms.
3.2 Anticipated Expiration Date
All questions that meet the ‘required’ criteria should be given an ‘anticipated expiration date’. This should be tracked in an automated database.
The ‘anticipated expiration date’ is the trigger for when a required by the form’s creator/responsible person, to see if the question still needs to be compulsory, or if it it is even required at all.
Some examples of anticipated expiration dates:
- A particular date when a research study is over
- A standardized review date for new required questions. For instance, all new required fields should have a mandatory review to see if making them required was the right decision. Is the desired goal being achieved, and if not, should the field be reverted to ‘not mandatory’ - or removed entirely.
- When the report that was using a data field is no longer being generated. (note in this case the anticipated expiration date is not a ‘date’ but more so a trigger of an ‘event’)
3.3a Allows users to skip completing a required field
Yes, you read that correct. It is very important that the user can ‘out-out’ and ‘skip’ any required field. But first, we need to understand how garbage data enters the EHR.
3 examples on how garbage data may enter the EHR:
eg. 1) The data requested may honestly not exist - for instance when a required field on a form being completed on a man has a field that only applies to a woman.
eg. 2) The work required to obtain the data for the required field is ‘felt to not be justified’. This is common. For instance, a patient’s “last known mensural period” may be a required field. This field is likely required in order to avoid excessive and unnecessary radiation to women who may be pregnant. However, having to ask and complete this question on a 55 year old lady who is having a low risk investigation (such as an uninfused brain CT, or chest x-ray) is often considered a waste of time and overtly jobsworth. Therefore, in order to get around this, a physician often may enter a random date, or perhaps use today’s date, or perhaps January 1st with a random year.
eg. 3) At times a physician may forgot to collect a required field during the patient encounter. For instance, a pre-MRI checklist has many required questions. If a physician forgot to ask one of them, they will be unable to submit the requisition. This leaves the physicians three options (1) try to get a hold of the patient, (2) delay submitting the requisition until next time they meet, (3) take a best guess at the answer (“I’m fairly certain the patient does not have any cochlear implants”). It may seem very dangerous to guess, but the physician knows the patient will complete the same questionnaire (and actually versions with even more details one) on at least one or two more occasions prior to their MRI. Therefore it is ‘assumed’ that if they incorrectly guessed, this will be remedied.
A much better solution to all of the above questions is to allow the user to opt-out of the required question. When they select the opt-out button, a dropdown list (and free text box) records why they opt-ed out. This is a much better option than making up garbage data. Let us review those same cases from above, but this time with the opt-out button:
In the case of eg. 1 - the opt-out button would provide feedback directly to the person responsible for ownership of that required field. In the case of the form having an error, the opt-out button would bring this to the form creator’s knowledge.
In the case of eg. 2 - This would provide feedback on the discordance between what the administration & forms team believes is important vs what ‘on-the-ground’ clinicians believes is important. Let’s have a discussion around this. Rather than pretending a gap between these opinions does not exist.
In the case of eg. 3 - the opt-out button would would allow the clinician to submit the form in a timely manner without having to make up any missing data. By flagging these fields as ‘missing at time of form entry’ the next team receiving the document can be extra careful to ensure this data is accurately collected when they update the same information at their step in the care workflow.
Allowing users to opt-out of required fields leads us to the next section:
3.3b Create an internal audit system to track usage of the opt-out feature
it is necessary to track when users opt-out of required fields. Otherwise there is now way for form developers to know how to improve the forms. Tracking this information also is critical to prevent certain clinicians from frequently taking the ‘easy our’ and using this ‘shortcut’.
Therefore track and monitor data. If certain users are outliers from the norm, use that data as a starting point for discussion. The outlier clinician may be right. The normative/average clinician may be right. They may both be right, or one of them wrong. It is impossible to know without speaking to the people involved directly.
Here are some examples of opt-out data to create automated reports on:
Q1 - Which clinicians opt out fields the most? Who are the outliers?
Q2 - Which questions are opted out the most? Desegregate this data by particular clinicians, departments, clinics, times of day and any other factor? Is there an explanatory factor for why this field may often be skipped? Is it perhaps a bad question?
Q3 - Which questions have had their completion rate change with time. Perhaps that is an indication the question is no longer useful.
3.4 Show the ‘justification’ for the required field
Whenever a field is marked ‘required’, the ‘justification’ for why it is required must be easily accessible to the user.
For instance, a “(?)” at the end of the line with the required field.
If the user ‘hovers over’ over the (?) they a popup box appears that contain a summary of why the field is required. eg: “Reporting” “Billing” “Research” “Patient Safety”.
If the user clicks on this popup, the will be taken to a detailed explanation page. That page should integrate everything the hospital knows about that particular question and why it is mandatory. For instance":
- What ‘department’ is responsible for that form / question in the EHR.
- The committee that decided to make the question mandatory.
- The names of the members on the committee at that time (including who the responsible head of the committee was).
- When it was made mandatory.
- When its ‘anticipated expiration date’ is (for either review or discontinuation).
- A brief, and a detail explanation of why it was made mandatory.
- eg. for Reporting - the reports generated by this should be listed
- eg. for Research - the studies this is being used for should be listed
- eg. for Patient Safety - precisely how this question improves patient safety, and what the risks would be without it
- The coding ‘logic’ for who the question is mandatory for (eg. “women over age 50 who have never been pregnant”).
Showing all this information should not be ‘extra work’. All this information should be tracked by the institution. (Though I suspect no institution actually does this).
Providing this information to users (1) increases transparency, (2) increases the ability to get good feedback from users, and (3) helps users to understand why they are doing something - which in turn will increase compliance.
3.5 Be open to feedback
The detailed explanation page page should also include a form for user feedback.
This feedback should go directly to the individual responsible for review of these questions in the EHR. The person who submits the feedback should also receive progress updates regarding the status of their suggestion.
For instance, a user may explain why a required field is no longer be required. Or they may provide an example of a case where the required field is not appropriate or is thought to be overly burdensome.
4. Next Steps
I do not know any electronic health record system that handles required fields in the way this post discuses. If you do know of one, please forward details to @_GregSchmidt or gschmidt@medmb.ca
On the EHR I am currently working on, we are reviewing all questions with required fields. We want to ensure each question asked is necessary and useful. This is particularly important as many questions are asked hundreds-of-thousands (some almost a million) times annually.
A word on data auto-population:
Advanced auto-population of data from the patient’s past chart is important in reducing the user burden completing forms. This is the topic of an upcoming post.
A word on designing real-world systems:
Hospital administrators may be surprised to discover their forms are not completed 100% the way the committee designed them. It is important to realize, that the ‘ideal system’ is a system that works, not a system that remains an ideal.
The workarounds discussed in this post create a system that is safe and works. It recognizes that classification of required field questions is a dynamic process that requires constant revision and user feedback. It recognizes that users sometimes have (a) more knowledge than the committee that created a form or (b) more laziness than the committee that created the form. Being able to capture this user data via the field’s opt-out button is critical in building a self improving system.
To fail to capture this important user data, results in the current state of ‘required data fields’ in EHR system. Where it often results in the creation of garbage data, delayed patient care, and an administrative layer which thinks ‘everything is working great’.
IdeaStage: new since Nov 2018