Gregory Schmidt, MD

Ken Kocienda gives an inside look into Apple's software development process during his 15 years at Apple. He was there during the release of Safari, iPhone, and iPad. The book is a must read for anyone who develops products or is interested in Apple. This post highlights some of my favourite themes from the book. http://www.gregoryschmidt.ca/writing/book-highlights-creative-selection #Apple #Design

5 minute lightning course on EHR User Interface Design. Covers first principles, foundational components, and the future of electronic health records. This was presented as part of the Lightning Talks session at the OpenMRS Conference in Nairobi, December 2018. http://www.gregoryschmidt.ca/writing/ehr-design-omrs18-lightning-talk #EHR #UX #OpenMRS

A way to brainstorm, team build, and strategic plan in a very large group

Original Article: http://www.gregoryschmidt.ca/writing/brainstorm-how-might-we

Summary of 1551 ideas generated in one hour at the OpenMRS 2018 Conference. Original post with full details at - http://www.gregoryschmidt.ca/writing/openmrs-2018-conference-brainstorm-session #OpenMRS #OMRS18

Slides/text at http://www.gregoryschmidt.ca/writing/concept-electronic-health-record-april-2016

Cool EHR user interface mockups - The Concept Electronic Health Record - April

2016 ----- The Concept Electronic Health Record (C.E.H.R.), was a project from a research block in second year General Internal Medicine residency. The project was presented April 2016 at the University of Manitoba Resident Research Day. It won the Residents' Choice Award for Best Podium Presentation. At that time, the presentation was a slick 10 minute pitch. I have entirely forgotten the script from that presentation. Therefore, a new commentary was written for this post. It also goes into far more detail than originally presented.

#EHR #EMR #UX #UI

EHR workflows should be assigned in real-time, based on the patient's issues and resources available. Article: http://www.gregoryschmidt.ca/writing/workflows-3-levels #EHR #EMR #UX

Is this true? Confirming validity of Past Medical History data The truth of medical data rests on the ability to validate it against primary source material http://www.gregoryschmidt.ca/writing/confirming-validity-of-past-medical-history #EHR #EMR #UX #UI

Article: http://www.gregoryschmidt.ca/writing/problems-with-past-medical-history-data

---- Summary: "Do not believe anything you read in the patient's chart - it is full of lies".

This was the first lesson taught to new medical students by our hospital's most esteemed diagnostician. I have found this assessment generally to be true - both for paper and electronic medical records. However, in theory, we should be able to remedy this problem with electronic medical records.

This post is written across two parts, Part 1: (i) how do we determine if data in the past medical history is true, (ii) how fake data enters the medical chart, and (iii) in practice, how do clinicians verify the truth of medical data?

Part 2 proposes ways to help verify medical diagnosis.

e-mail [email protected]

Twitter @_GregSchmidt

'Auto-populated data' should be stored different from 'Original data' in electronic health records http://www.gregoryschmidt.ca/writing/auto-populate-ehr-data-vs1 ----- Summary The auto-population of data fields is a key benefit of electronic medical records over paper. However, there are two issues that need to be addressed in order to minimize error and reduce the chance that garbage data is created. First, a system is needed where users have an opportunity to confirm if the auto-populated data remains 'true' or has changed. Second, the auto-populated data must be stored in a way where it is tagged different from original data. But first, a comment on the benefit of auto-populated data fields.

Required fields can be the portal for garbage data to enter electronic medical records. Here are some ways to prevent that. http://www.gregoryschmidt.ca/writing/required-data-fields SUMMARY 1. Why is this field required? 2. Workarounds on paper required fields 3. A rational approach to: 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