Why not just modify an EMR for learning?
Several groups have already looked at the concept of modifying an existing EMR for learning purposes.
While this has been done, there are many challenges that arise from this approach. We note that an open-standards EMR can still be a useful component of the overall platform but we should take care not to expect too much from that component. We set out here some of the key challenges with using the underlying system architecture of an EMR as a learning environment.
- For educational and evaluation purposes, the fundamental structural units and data assumptions in an EMR are a poor fit. Consider the case of William, age 7, who has asthma. For learning purposes, we would like to be able to explore William’s progress over time, seeing how his condition evolves with age. To do this, we need to be able to work with ‘virtual time’ i.e. to adjust William’s age, birthdate, and various data parameters through various encounters with learners. In simple virtual patients, it is easy to state that William is 7 years old etc. But when working with an EMR, we want to be able to present a consistent set of data screens, where his birthdate is consistent across the presentations. We also need to be able to make William 7 years old over subsequent groups of learners, and to date his test results, vital signs etc consistently. So here is the first major inconsistency between a real EMR and an educational EMR (EEMR): in a real EMR, there are certain fundamental parameters that never change for a patient (birthdate, dates of clinic visits and hospital admissions, ethnic/genetic background etc). Once set, they are inviolable – a determinant data set that are used to hold other pieces in the related data tables together. In the EEMR, you need to be able to create multiple instances of William, and his age and date parameters are now virtual, relative to the date seen by the learner group.
- If only it were the dates that needed to be variable, we might be able to work around this, but there are many other workflow dependencies in an EMR that do not apply to an EEMR. In a real EMR, there is only one fundamental workflow and audit trail. William will see a series of healthcare providers (HCPs), but always a series. He cannot be in two places at once. He can only pass through a clinic or hospital using a single workflow path, which is then well documented, and then archived for future retrieval. Rollbacks are not only difficult, but actively prevented by most EMR systems because this corrupts the audit trail of which HCP did what when. In an EEMR, we need to be able to present William and his illness episode to various groups of learners, either in parallel or as a repeating series of events. When presented repeatedly, the starting point and its associated data should be the same for each batch of learners. In a traditional sandbox EMR, this creates lots of maintenance needs to roll that dataset back to its earlier state, along with the creation of a copy of what was done by the earlier set of learners. Real EMRs are not set up to do that. It is foreign to their fundamental architectures. Much redesign work is needed to accommodate those simple educational needs. This gets expensive.
- Security, confidentiality and access control lists are needed in both an EMR and an EEMR. But the needs are different. In a real EMR, the controls need to be quite strict. The audit trail of who did what when needs to be clean and hard to modify. Generally a limited set of HCPs will be expected to interact with the data and to edit it. Measures are taken to ensure that an HCP has the right security role to edit the data. You would not expect or want a Unit Clerk to be able to edit a surgical Operative Note. In the EEMR, the situation is much more open and flexible. Many more individuals over time will potentially have access to the same data. When authoring cases, you may well want an Administrative Assistant to modify a surgical Operative Note because the teacher will not have time to make all the changes needed. You also have the possibility of learning scenarios, especially in interprofessional education, where you want to be able to change the role of the participant. This is a very powerful learning exercise to put a medical resident in the role of a pharmacist or paramedic: the walk-a-mile-in-my-shoes phenomenon. This would not be practical in a real EMR.
- For evaluation purposes, we need to see what happened to a patient in both an EMR and EEMR. In the EMR, there is only a single audit trail. Depending on the vendor, this is variably implemented, with many simply tracking who opened the patient’s record and when. We know from our extensive work on virtual patients and virtual scenarios that in an educational environment, we need to track what was done by the learner in much finer detail. Sometimes it is sufficient to record that the correct diagnosis was made and drug provided. But in the current drive towards competency-based education, that is not sufficient and we increasingly need to track all the activities of a learner and her peers. Team-based learning is powerful but also harder to assess. Traditional EMRs are not designed to track multiple activity streams and generally assume that only one HCP is editing the patient record at one time. We need more flexibility and capacity. We also need the ability to export such activity metrics to our other educational systems. EMRs are not set up to do this – their export functions focus on a single patient at a time. In educational evaluation systems, we need to be able to send data from one platform to another, often in real-time, and across learner groups (who might all be tackling the same patient case scenario at one time).
Now there are other aspects of an EEMR where a traditional, open-standards EMR structure would be useful. We will address this later, including some thoughts about a simple repository for capturing exemplar case materials from other healthcare systems and EMRs.
So while an EMR could be adapted for educational purposes, we would be messing with some of the fundamental structures of the system, disabling some of its key features and functions, and expecting new functionality that is hard to implement because of the original architecture design. Yes, you can make any vehicle fly, given sufficient thrust, but the landing might not be successful.