Follow for articles on healthcare system design
WELCOME TO EHR BUGS
Home of the EHR Bug List & EHR Wish List
Purpose
EHR Bugs is a place to discuss and develop best practices for electronic health records.
How?
EHR bugs will form an open source community that discusses EHR principles in a format that does not mention specific EHR vendors
JOIN EHR BUGS
This site and community are brand new.
Everything for this page is up for discussion on how it can be improved and re-worked.
We will grow this webpage and the community organically based on the direction members want to take this.
EHR Bugs needs patients, clinicians, designers, developers, researchers, and policy experts involved.
TO START
We need to figure out what tools works best for connecting with EHR Bugs community.
Would members like to create a dedicated Slack group? an online forum? a Wiki? Ideally we require a medium where members can discuss and evaluate EHR ideas.
JOIN US
Please complete this short New Members Form - to stay up to date on this project
or e-mail directly at hello@ehrbugs.com
THE EHR BUG LIST
The EHR Bug List is a collection of real life examples of bugs in medical record software.
BUG DEFINITION
A bug is as anything that is dangerous to patients, frustrating to clinicians, or falls short of what an electronic health record system should be in 2019.
THE PURPOSE OF THIS LIST
The Bug List has many benefits,
It can help begin a concrete conversation about the problems with electronic health records.
It can act as a ‘check list’ for organizations designing and implementing EHR software to consult when they run their internal quality checks
It can act as a shortlist for the development of EHR quality standards that are required for certification of EHR safety..
REQUIREMENTS TO SUBMIT A ‘BUG’
Bugs are to be submitted anonymously. They will not include any information that can identify the patient, the user, the date, the EHR system, or the health system where the bug occurred.
Only report examples of bugs that are real. Do not include hypothetical examples. If you have experienced a particular bug multiple times, it is OK to write a ‘composition example’ based on the multiple real occurrences.
Do NOT include your name or city. It is ok to mention your role (provided this is general enough and non-identifying).
Do NOT include any patient identifying information. Patient sex and approximate age is ok if relevant.
Do NOT include any electronic health record software identifying information. For example, do not mention anything that can identify what EHR software company produced the bug. If you are discussing bugs with hardware, do not discuss what brand of hardware caused the bug.
Do NOT include any information that may identify the health system, clinic, or hospital you were working in. It is ok to say the type of facility you were working in if relevant, such as outpatient primary care clinic, tertiary hospital operating room, etc.
Do NOT mention how long ago, or the date when the bug took place.
Do NOT include a screenshot or link to a picture of the bug.
Do NOT try and circumvent the spirit of these rules, by ‘following them’, yet making it still possible to guess information that has been asked to be anonymous. This website will only work if it remains entirely anonymous.
The Bug Submission form will log
Timestamp of when bug was submitted
Description of the bug. Please be as objective as possible and leave theatrics aside
Optional field: country. This is logged to help track where submissions are coming from
FOLLOW YOUR HEALTHCARE ORGANIZATION’S BEST PRACTICES
Submission of a bug to EHRbugs.com should not supersede or be considered in lieu of any formal processes your healthcare organization has for submission and tracking of patient safety issues or electronic health record issues.
Submission of a bug to EHRbugs.com should not require the user to violate any legal obligations the user has to confidentiality regarding the matters shared.
EHR WISH LIST
The EHR Wish List is a collection of things we wish EHRs did.
It is based on both good ideas observed in operational EHR software, in journal articles, in R&D, as well as aspirational features and ideas of what EHRs could do.
THE PURPOSE OF THE WISH LIST
Identify best practices, so these can be collected and discussed. This will be valuable to anyone building an EHR, and help EHRs overall become better.
Track ideas for EHRs, to help direct development efforts in the future
Provide a place for optimism as we help build the future of healthcare
REQUIREMENTS TO SUBMIT A WISH
Unlike the Bug list that requires only real examples, submissions to the wish list can be either real example or hypothetical examples.
Follow the same requirements as outlined when submitting a bug. Do NOT identify yourself, the patient, the health care system, or the EHR software.
POLICY ON SCREENSHOTS
At this time we are not accepting screenshots or links to good EHR examples unless they are links to professionally published papers, or to ideas for EHRs that are not in production
ABOUT EHR BUGS
The exact description for this will evolve in the coming days. We need a place where electronic health records can be discussed in depth. How they should look? How they should work? How they should be coded? How they should be implemented?
As healthcare becomes ever more ‘digital’ the need for high functioning electronic records with tighter integration into care delivery becomes even greater. Hopefully the EHR Bugs community can help be a place that helps make this a reality.
A major difficulty in being able to do any of the above has been the EHR Gag Order. The premise of this website is to discuss EHR functionality in a manner that is EHR product and vendor agnostic.
In this way we can hopefully begin to discuss best (and worst) practices without being sued.
The need for an EHR Bugs Community
The exact text for this about section is still in development. I have pasted some observations
RAJ M. RATWANI, PHD; MICHAEL HODGKINS, MD; DAVID W. BATES, MD
“A major impediment to addressing usability and safety issues has been the inability of clinicians, researchers, and developers to communicate openly and share specific usability and safety challenges associated with EHR technology. Although medical device companies are required to share usability and safety issues, some EHR vendors have resisted sharing this information—even information related to events that have resulted in substantial harm. Many contracts signed between EHR vendors and health care organizations include clauses that prevent health care organizations from sharing specific information about the EHR product. Such “gag clauses” require authorization from the vendor to share screenshots, videos, and any other information about the purchased EHR product.8 For example, some vendors specify that a clinician who identifies a critical usability and safety issue cannot share a visual example illustrating the issue, which could potentially prevent other clinicians from committing a similar error. A researcher studying usability and safety issues cannot publish a screenshot that may advance EHR design. A vendor may permit release after review of the content, but this process is often lengthy and permission may not be granted.”
(Improving Electronic Health Record Usability and Safety Requires Transparency, JAMA. Dec 25, 2018)
MARK FRIEDBERG, MD,
RAJ RATWANI, PHD.
HARDEEP SINGH, MD
ROSS KOPPEL, PHD
EDWARD J SCHLOSS, MD
SAIF KHAIRAT, GEORGE CAMERON COLEMAN, SAMANTHA RUSSOMAGNO, DAVID GOTZ
“Compared to the aviation industry, health care lags behind. While EHRs first penetrated health care over a decade ago, only in the last three years did the ONC implement similar practices for EHRs. In fact, many EHR vendors do not even comply with ONC policies, yet they maintain adherence certification nonetheless [27]. What will it take for our digital health system to achieve the safety profile of the aviation industry? If usability researchers have limited access to EHR systems and are not able to disseminate the results of their research fully, and if vendor adherence to regulation cannot be ensured, then EHR systems will continue to put patients at risk.”
(Assessing the Status Quo of EHR Accessibility, Usability, and Knowledge Dissemination, May 25, 2018)
ARJUN GUPTA, MD; SNIGDHA JAIN, MD; CAROL CROFT, MD
“End users should be actively included in designing, testing, and implementing the electronic medical record system and in guiding performance improvement efforts”
JEROME CARTER, MD
“Certification testing is not the answer because it only tests for features, not the quality or coherence of the underlying system. User-centered design, per se, is not the answer either. What does make sense as an initial approach is a set of vendor-independent test cases that can be used to test every CPOE system. Another thing that might help is better after-market surveillance where every error condition or bug is immediately captured and reported. But there is a much larger question here: Are there ways to test complex clinical systems such that errors can be trapped and fixed prior to production? There is no mechanism to enforce quality requirements, but clearly quality issues exist.
Imagine someone being able to start a company that builds commercial aircraft and never have to conform to any external quality requirements. Standards for aircraft have developed over decades of testing and studying accidents and mishaps. Aerospace engineers are professionals dedicated to aircraft design, and they help to develop standards. Clinical software is complex and is becoming an essential component of the healthcare delivery system. I find it amazing that there isn’t a group of professionals dedicated to assuring the quality of clinical software. We need engineering standards for clinical software systems. This is not a call for regulations; rather, it is a call for a more formal approach to clinical software design and development.
Currently, we lack any sense of the best design choices for any aspect of clinical systems. There is no manual to consult for the ideal UI for neonatal nurses, or a frequency distribution of errors likely to occur with EHR problem lists or a guide for drug interaction algorithms. Just about everything known about complex clinical systems is proprietary, but intellectual property claims are not antagonistic to engineering principles. Aerospace engineering holds no threat to Boeing. There was a time when EHR systems were mostly talked about, but not used. Those days are past. Now we live in an era where lives depend on clinical systems.” [emphasis added]
Full Post: “Bugs and EHR Systems: Engineering Matters…” by Jerome Carter, July 4, 2016
Gregory Schmidt, MD
Everyone becomes an expert by studying and building on the previous generation. Artists listen to other artists. Musicians listen to other musician. Architects study other architects. Scientists study other scientists. Chess masters study master gameplay. Business leaders review other case stores. Developers share open-source code. Producers review other films.
It is no surprise that digital communities have evolved in all areas dedicated to sharing, studying, and providing feedback on each others work.
Electronic Health Records remain the anomaly. The best points and worst points of them remain shrouded in secrecy. Best practices remain occult, and progress in the industry has been slow and too sloppy.
Who started this group?
Hi - I’m Gregory Schmidt, a Canadian trained General Internist who believes that Electronic Health Records play a crucial role in the future of healthcare.
At this time I am helping build EHRs with AMPATH and OpenMRS in Kenya. We are gearing up for a massive re-build of OpenMRS (used in 80+ countries). This is the perfect time to build a community around EHR best practices.
You can find my writings at www.gregoryschmidt.ca or view it filtered for posts on EHR.
Connect on Twitter @_GregSchmidt or by email gschmidt@medmb.ca
Currently, it is just myself. But I hope in the upcoming days and weeks others become founding members of EHR Bugs and take the community forward form here. Let me know if you, or anyone else, may be interested in this.