Functional requirements of an EEMR

If we want to develop or implement an Electronic Medical Record for educational purposes, what are the functional needs or requirements? 

  1. We need to track our learners. In the current competency-based professional programs, it is no longer sufficient for a teacher or evaluator to globally state that the learner is good enough, or more importantly, not good enough. We have a huge problem with Failure to Fail, which is not providing a properly accountable educational service to our public. And when we do fail, one of the biggest challenges is poor documentation and insufficient data. Most failing learners now litigate. We must have evidence to support competency judgements. 
  2. We need to track what our learners actually do. While teachers and evaluators are keen observers, we also have our biases. We pass learners that we like and who are like us. This is not good enough. Google and Air Miles now have a pretty constant record of what we do and how we behave. It is no longer defensible in the current world of big data to not track what our learners do, when faced with a clinical challenge. We need to be able to assess, sometimes in fine detail, exactly who did what when. In team-based learning, the actions of peers are also important to track. For a final evaluation, you often do not need all this fine detail for the majority of learners, who perform their tasks in a timely and efficient manner. But our challenge is in documenting and accurately measuring those who are marginal performers. We owe it to them (so that earlier detection can prevent prolonged or repeated clinical rotations) and to our patients (so that we do not foist substandard practitioners on an unsuspecting public). 
  3. We need to track how our educational programs perform. Do learners benefit from the cases and materials that we create? Are there weak areas in the learning design that could be improved? The same could be said for teachers. Accurate feedback on teacher performance is rarely provided because it is so important to protect the source of the data: learner evaluations. No learner will criticise a professor, whom they might later need for a reference. If we could provide objectively created, de-identified activity metrics from the learners, the teachers would then benefit from earlier feedback on their teaching methods and materials, without the risk of blaming learner attitudes. We have used such activity metrics to great success in some of our projects (e.g. Clinisnips article and project], thereby generating a useful feedback cycle to improve the learning materials. 
  4. We need to be able to share such activity metrics with a variety of learning platforms. Most educational programs rely on a Learning Management System to do this recording of learner progress. However, in Canada, few medical schools make much use of an LMS. Medical curricula are not course-based; their rotations, which are constantly overlapping, are a poor fit for the database architecture of an LMS. But other healthcare disciplines are more course-oriented and some make extensive use of the LMS. We need to be able to track and export activity metrics in a manner which is not dependent of these monolithic systems but can be integrated with them. Previously, this was attempted using SCORM – however, SCORM is oriented towards courses, LMSs, and a simple pass/fail result. Fortunately, we now have some newer approaches, such as the Experience API (xAPI), which allows for tracking of activity metrics in a Learning Records Store (LRS). The xAPI/LRS approach is designed to be flexible across multiple platforms and learning systems; has the capacity to absorb large amounts of data from multiple, simultaneous activity streams; and can be easily connected to one or multiple existing LMSs and other data systems. 
  5. While the basic workflows in clinical practice tend to follow some reasonably predictable clinical pathways, we need to allow for pathway variations. We also need to allow for different user interfaces and presentation layers. Not all EMRs look the same or work the same. But for learning and evaluation purposes, we need to see whether the learner can figure out an acceptable pathway through a learning problem, and apply a reasonable set of procedural steps. To use a simple analogy, in a driving test, we do not expect the student driver to know how to operate all the controls in a vehicle (sunroof, music etc). And we do not expect that the procedure will be exactly the same for all vehicles: some have their turn indicators on the left, some on the right. But we do expect learners to adapt and properly indicate their turns. So, for an EEMR, we need a design where the interface can be easily modified and tuned to the local context, without affecting the underlying learning designs and business logic of the system. This is now a fundamental feature of good data system design: to detach the presentation layer from the underlying business logic; and therefore in our new thinking about how to construct a usable EEMR platform, we are not diverging from good, current, educational system design. 
  6. Clinical teachers across all disciplines do not have time to develop rich and rewarding EEMR case materials. The authoring interface will need to be intuitive, allowing for branching narratives and pathways that reflect the real variability of clinical practice. It will also be important, for efficiency’s sake, to be able to copy and repurpose existing case materials. A modular design to the case or scenario elements greatly facilitates such repurposing. Open data standards for case content also promote such sharing and repurposing. 
  7. Educational programs do not have vast resources to maintain such systems. Even once a system is designed and implemented, it must still be maintained. Sandboxes usually have to be cleaned out and raked clean – this applies just as much to educational sandboxes. Better to design a system where such cleanout is not required. 
  8. We need flexibility in how learner groups tackle such case presentations and scenarios. Depending on the discipline and learning environment, our EEMR needs to handle multiple concurrent users, teams of collaborating learners, or proctored exams for summative assessment. This creates a different set of requirements for managing user groups, roles and identities. This can be very resource intensive and it is often better to integrate your EEMR with existing educational systems that already manage user roles and access. This can be achieved using IMS-LTI integration, or other education authentication systems. Because different programs, universities and disciplines use different platforms for such user management, our EEMR should support a variety of such authentication systems and integration APIs. 
  9. Because our learners change careers and move from system to system, it is also important that their learning achievements and activity metrics are portable across systems. An analogy might be to follow the concept of a transfer of records from one system to another, just as in medical records. But a more recent approach that also translates to educational activity metrics is that of the Personal Health Record (PHR). For the EEMR, the equivalent would be the Personal LRS, a rapidly emerging concept in educational achievement tracking. This does not have to be implemented in the early designs but it is important to allow for such future functionality. 
  10. Generating realistic case materials, with DICOM and other data that has reasonable verisimilitude, can be very time consuming. This is where connecting our EEMR design with a more traditional, open data standards, EMR would be beneficial. The ability to accept case materials from other EMRs, rather than having to always create the case records from scratch, would be a great time saver. It may also be worth exploring the ‘Donate your Educational Data’ concept as part of this. One of the resulting functional needs that arise from this approach is that of de-identification. This presents its own set of challenges but has been addressed elsewhere. There are some aspects of the DyD approach that crowdsource this function, which again would reduce risks and resource consumption. 
  11. Search and data discoverability are common aspects of the EMR and EEMR. In both systems, you need to be able to identify cases that match certain characteristics. But the security/confidentiality aspects are quite different for the EMR and EEMR. In the EMR, privacy is paramount and systems are generally very protective of their internal data and metadata. In an EEMR that would be adopted across multiple organisations, disciplines and programs, much more openness and data sharing would be required. Indeed, there would be a duality of purpose: for some parts, such as source materials imported from an external EMR, you would need to continue to protect the privacy of such data; for other virtual patients and scenarios, you would want to be able to easily share case materials across other server instances or case repositories. To accommodate such a duality of purpose, again it would make sense to couple an open-standards EMR, with an independent EEMR platform. 

These are the core functionalities that are required in such an EEMR platform. While this could be designed into a single system, it would make more sense to take advantage of the inherent capabilities of a number of systems, and then integrate them into a coherent whole, using a set of APIs and interoperability protocols. We are fortunate in that such APIs and protocols now exist in the tools and platforms at our disposal. 

This complex architecture diagram does not show all the components mentioned above. Because of the open nature of the above architecture, it would be very feasible to integrate the PHR mentioned above, using Infoway’s open APIs

There are also a number of existing educational functions that could optionally be added to such an extensible platform: 

  1. Tamagotchi-like cases — in some disciplines, such as family medicine, palliative care, community health, the principle of continuity of care to a practice population is a core concept. Learners would benefit from the approach of having a system that can generate care requests on an ad hoc and pre-programmed basis. Illness does not always arise at the most convenient times. Think of the strong learning generated by having a virtual patient “page” you in the evening, using SMS or Twitter, and asking for advice with a problem. Or it might be a virtual team member. These are the realities of practice in a small community – so why don’t we expose our learners to such events? We have implemented these in some of our virtual scenarios, with great educational impact. 
  2. Turk Talk — real-time remote collaboration in small group learning scenarios. In community-based learning programs, which are often distributed, the ability for learners and teachers to collaboratively tackle a learning scenario, which requires team communication and concerted action, is a powerful learning tool. We have successfully incorporated this Turk Talk approach into our mental health scenarios. The same functionality can be added to an extensible EEMR platform. 
  3. Learner-generated case materials — not all of our scenarios and case materials have to be created by teachers and program administrators. There have been a number of successful programs and competitions, such as Infoway’s virtual patient series or JISC’s Kritikos project, where the energy and imaginations of learners generates materials, concepts and approaches that experienced/jaded teachers have overlooked. The EEMR platform should include an authoring environment that supports team-based, mentored/collaborative authoring. We have worked with such design principles and included these aspects into some of our previous projects. 
  4. Curated multimedia — educational systems are more engaging if they provide multimedia elements. But such media objects can be expensive to create from scratch. It is more cost-effective these days to curate a selection of existing materials, e.g. from YouTube, and present them with suitable annotation and editing. There are various ways in which to do this, which our various collaborating teams would be glad to share.