Tips and Tricks
First Quarter 2019
Tips and Tricks: Formatting a case for different audiences (e.g. first year medical student versus a medical student in clerkship verses a medical esident or practitioner).
Background – Why Virtual Patient Cases: One of the main goals in health care education is to supply society with knowledgeable, up to date, and skilled professionals. The societal and health care expectations in providing adequate learning experiences can be overwhelming for both learners and educators, and the health care environment is dynamic and continuously changing with fewer patients in hospitals staying shorter periods and with specialized health care needs. There are also technological advances, financial challenges, and numerous regulations. The teaching and learning of professional skills must be conducted without jeopardizing patient safety. Therefore, this continuously changing health care environment requires new models for training health care professionals. One challenge is how to teach students to apply their knowledge when they are dealing with clinical problems. Technology enhanced simulation is one possible solution. Different types of simulation modalities as a teaching method in health care education have developed rapidly during the last few decades. Simulation offers a safe and realistic environment in which to learn, practice, and make mistakes without direct contact with and risk of harm to patients. The use of virtual patients (VPs) is one means to attain the goal of supporting medical students in their acquisition of scientific knowledge, as a way to integrate theory and practice, and promote clinical reasoning.
VPs can take many different forms and can be realized using a wide range of presentations, styles, and configurations. There are also several definitions for the concept of the virtual patient, and the term VP is often used in an ambiguous manner. I’ve adopted the following definition: “An interactive simulation of real life clinical scenarios for the purpose of health care and medical training, education or assessment.”
Traditionally, medical education relied heavily on didactic learning (e.g. in the classroom or lab) and learning by example (e.g. clinical labs or simulation). “Problem Based Learning” (PBL), a form of Standardized Patient simulation developed in the 1980’s, began to take roots in the form of virtual patient cases.
Developing VP Cases for different audience knowledge levels: While virtual patient cases are apropos to all levels of medical education (and all areas of medical education), it may not be obvious how one might format a case for different audience knowledge levels.
Consider the above slide derived from the MedEdQR overview presentation. For a novice medical student, they know little about “Dr. Think”, medical knowledge, systematic decision-making, clinical reasoning, diagnostic procedures, treatments, and professionalism. At the other end of the spectrum, the resident or practitioner, well versed in Dr. Think, doesn’t need coaching or “guidance.” They are capable of traversing a case and requesting case content that they deem most appropriate. Taking the audience into account, there are at least four strategies that can be used in the creation of a case that will support the level of guidance a learner might need. It is even possible to take the same case, and with minor modifications, convert it from a fully guided case to a completely unguided case (or something in between depending to the audience requirements).
Here is an example of the four strategies. Four pages were created in a “Test Case”, each page containing some form of reference to the patient’s “Vital Signs”. See Figure 1. In order to show how each strategy is implemented, we will step through each of the four page examples.
Figure 2 shows how the Vital Signs would look to a learner when they view page “Example 1 – inline as text.” In this example, the Vital Signs are embedded in the text as a table. The learner, not necessarily knowing that they need to obtain the patients vital signs, is guided to that need by inclusion.
When a learner views page “Example 2 – as an attached image” (see Figure 3), it is a different experience. The Vital Signs are not there to view. The learner must select “Vital Signs Example” from the “Available Media” area, which is an indication that the information is being retrieved from the media library. In this scenario, it’s a little less obvious that the learner needs to request the patient’s vital signs, but can see that they are available if they want to see them.
Requesting the “Vital Signs Example” image (see Figure 3), the image is rendered on a new page requiring the learner to close that page in order to return to its parent. Figure 4 shows how the Vital Signs image would look to the learner.
Figure 5 shows the “Example 3 – by reference” page where the learner is told to “request” the patient’s vital signs. Here the learner is requesting content that was added to the case from one of the Physical Exam or Lab Test libraries – in this case from the Physical Exam library. Requests are made by scanning a QR-code, voice or text input or by using the “What can I ask?” question mark. This scenario requires the learner to be even more engaged in accessing the patient’s vital signs because they have to take a somewhat more complicated step to retrieve (request) them.
The results of this workflow are the same as “Example 3 – by reference.” See Figure 6.
So it can be seen that by varying the way medical knowledge is accessed within a case, the case can be tailored to learner’s particular knowledge level or the learning goals of the case.
There is another reason to choose one strategy over another and that has to do with tracking. In ALL cases, user activities are tracked, but only made visible and available to Case Builders if tracking is enabled for the case. In the first example, the only user activity that would be tracked would be the fact that the user elected to view the first page – i.e. Example 1 – inline text. Since the Vital Signs are embedded in the text, no activity is registered relating to the accessing the Vital Signs. In the other cases, one where the learner elects to view the Vital Signs image from the media library, and the last two where the learner requests access to the Vital Signs from the Physical Exams library, those requests for them are registered as activities. Additional views of the parent page or the actual vital signs data will results in a new activity being registered. Activity tracking can be quite useful in reviewing learner progress and case assessment.
This is just one of the many case building strategies that makes the MedEdQR platform so flexible, and it is this flexibility, among other traits, that makes this platform a leader in virtual patient case creation and deployment systems.
Tips and Tricks: Using split screen and slide over with MedEdQR IOS.
Ever since the release of Apple’s IOS 9.x, iPad users have had the capabilities to do both split view (i.e. show and run two apps at once) and slide over (show and run a second app on top of the existing app). It is even possible to add a third app if two apps are in split view and the third app is added as a slide over app or a split view app. If you have sufficient screen real estate you can even have four apps in split view. There is a great introduction to split view and split screen at this site. Not to be outdone by Apple, Android table devices also have split view capability. If you’re interested in getting an introduction to its use, visit this site.
So why might I want to use this feature? Consider the scenario where a learner is viewing a blood smear, as in the picture to the left. If they aren’t familiar with reading or interpreting such pathology, they might “slide over” a website specializing in reading blood smears. Another scenario might be that they are confounded by some physical exam findings and/or laboratory results and want to consult an online diagnostic repository or even class notes. Using the slide over or split screen would give the learner access to additional content to complete or document the exercise. One final example is where the learner needs to keep notes along with interacting with the virtual patient case. Of course, the learner could use the notes function within the mobile device MedEdQR application, but those notes are only available within the mobile app. Alternately, using split or slide over mode, the learner could drag their text app onto the screen and create or augment their portable notes there.
Tips and Tricks: Some thoughts about building cases.
Building cases is an art, which implies that there are many, many ways to construct them. But unlike art, which is often abstract, and more pathos than logos, virtual patient cases are more prescriptive. There are case goals and objectives that would minimally define the case particulars such as the audience, the knowledge coverage, and required or expected outcomes. What also comes into play is whether the case is being constructed from scratch or is being converted from another form.
When a Case Builder constructs a case, they have to take into account both the purpose of the case, and the learner’s level of medical knowledge, clinical skills and understanding of professionalism. If the intended audience is at the novice end of the spectrum*, the novice user might find all of the case information within the case pages including any media, physical exam and/or lab test results, any interpretations, reports and assessments. Typically cases for novices are sequential and don’t contain decision branching, thus they traverse the case sequentially. If the intended audience is at the other end of the spectrum (an advanced learner or practitioner), they might encounter only patient information such as medical history and the presenting problem within the case pages and then have to request content via one of the “request information” options (voice or text input, using the “What I can ask” icon, or by scanning a QR-code. Such cases often contain complex branching or navigation between case information thus requiring the user to make informed decisions relevant to the diagnosis or treatment of the patient.
Taking this a step further, the same case, with only some textual and branching modifications, could be assigned to users at various knowledge levels. For example, if case’s Physical Exams (PE) and Lab Tests (LT) are constructed in the PE and LT libraries, then for the novice users the text could instruct them to request one or more PE and/or one or more LT. For other more advanced users, those directions could be removed from a cloned version of the case thus requiring them to make all the information request decisions. There is no reason not to have multiple versions of a case for audiences of different abilities and no reason cases must be limited to one audience.
This discussion has only covered how cases might be constructed when taking the audience and purpose into account. There are certainly other goals or objectives, such as optimal treatment vs. cost of treatment that might lead to other case construction opportunities. Expect more on this subject in the future.
*The learner spectrum is a construct I employ to discuss the abilities of the learner when it comes to medical knowledge, clinical practice and professionalism. At one end is the novice, who knows only rudimentary knowledge and must be guided through the diagnostic / treatment process. For the novice, all of the decisions are made for them as the case is traversed. At the other end of the spectrum is the seasoned learner or practitioner who has a number of years of practice experience. They know the standard operating procedures leading to a diagnosis / treatment and do not need to be guided through the case. For the advanced learner, none of the decisions are made for them as they traverse the case.
Tips and Tricks: Assigning cases to groups and some ideas about how that feature might be used.
One of the important features of the MedEdQR platform is the ability to assign cases to both individuals and groups simultaneously and independently. First here is a little background on groups. A group is an arbitrarily named aggregation of users and cases and is assigned to a single departmental program*. Cases can be assigned to any group and users can be assigned to any group – all independently and simultaneously. As an example, a department’s Medical Curriculum program might have a PBL group, an Assessment group, a Self Study group and a Remedial group, all assigned to it. There is no practical limitation to the number of groups assigned to a program nor is there a limit to the number of users or cases that a group can contain. In Figure 1 below, the Vanessa Jones case has been assigned to three groups each with their own start/end dates and assignment options. With respect to those users in each of the groups, this case is seen as three separate cases.
A couple more examples of how groups might be used are:
- Groups might be used to manage users and cases in a temporal way. For example, the department might have four programs, First, Second, Third and Forth years. Within those programs, groups are created to represent the terms or semesters within a year and then cases and students are assigned to the appropriate groups. This might look like First Year program contains the Fall, Winter and Spring groups. Furthermore, within that same First Year program there could be a Self Study and Remedial group as well.
- Groups might be used to represent classes, or seminars or other learner engagements. For example, there might be a group named OSCE containing the appropriate clinical cases and the learners needing to review those cases. Or as mentioned before a Problem Based Learning (PBL) group where learners are given access to the current PBL cases.
Groups are valuable for other reasons. Groups can have a starting and ending availability date or be perpetual. Groups also have the options to toggle user activity tracking, progressive disclosure and whether the users in the group are required to certify that they have completed the case (End-Of-Case) certification.
Figure 1 also shows that the case in question is also assigned to three individuals: a learner, a faculty member and an assistant. This might be done so that the assigned faculty member could review and critique the case prior to deployment, the assigned assistant might familiarize himself or herself with the case to make it easier to operate in the assistant role, and so that the assigned learner might do remedial work or be assessed.
Those are just a few ideas how and why cases might be assigned to groups and individuals. It was designed to be highly flexible so that it might easily model nearly any curricular case deployment structure.
* While a department can have many programs, only system administrators can create departments and programs as part of an institution’s subscription setup.
Tips and Tricks: Some ideas about using custom Physical Exam (PE) and Lab Tests (LT) profiles, panels, exams and tests.
There is an obvious reason for the feature that gives Case Builders (CB) the ability to extend the system PE and LT libraries, namely, there are missing PE exams and/or LT lab tests. We strive to keep the system wide libraries up to date; the PE library with the standard PE exams and the LT library with the most ordered lab tests – all neatly aggregated into PE profiles and LT profiles and panels**. Yet it is impossible to predict the depth and breathe of the needs of the medical education community with regards to keeping these libraries current. This is the primary reason we implemented the ability to augment the system libraries with departmental libraries.
There are other reasons for wanting to extend these libraries, but for brevity sake, we will focus on one, economy of effort. Let’s use the Complete Blood Count (CBC) lab panel as an example of how a panel can contain a very large number of tests and how the contents of a PE or LT profile or panel might grow over time. This panel in the system LT library is currently an aggregation of 49 different lab tests. In the last two months the system admins have added no less than three new lab tests to it and there is no reason to assume that we won’t continue in this practice. Why? Because there was either a client request that we deemed suitable for inclusion in the system library or we determined that there were missing exams or tests during a review of virtual patient (VP) cases. In situations where a profile or panel has a large number of lab tests, often the CB may only needs a small portion of the tests contained therein. Furthermore, when a curriculum of VP cases are taken as a whole, the same sub-set of the CBC tests could be used over and over again with only minor additions or deletions. Looking at this from an economy of effort standpoint, it makes sense that the ability to create new aggregations would be helpful – re-aggregate to your needs. Once the new aggregation is in place, the CB only needs to select the new panel folder during the case build-out to include all of the required tests. Without this ability, the CB has to select tests from the CBC panel lab tests one at a time to be included in the case. To make this process more automated, why not create a new aggregation, let’s call it CBC-mini, containing only those lab tests that are consistently used? We have found from our review of VP cases from a single source, that a consistent subset of lab tests, especially when the tests are from comprehensive panels, provides an opportunity to create custom profiles or panels through the re-aggregate of exams or tests.
** PE profiles and LT profiles and panels are aggregations of individual physical exams and lab tests respectively. Yet, there is a major difference between the two. Profiles are aggregations that do not share exams or lab tests among themselves. The PE library contains only profiles.
The Lab Test library contains both profiles and panels. For example, the LT “Acid-base and blood gases” profile contains the “Absolute content of carbon dioxide” (CO2-A) lab test. You will not find this test in any other LT profile. LT Panels are a different story. Panels are open aggregations – a lab test can be in more than one panel and if used in a case, the lab test results are shared across all the panels that contain it.
Tips and Tricks: Page tricks using Branching and Progressive Release (Disclosure).
The heart of any virtual patient case delivery system has to be the case scenario – the story, the “case”. In the language of MedEdQR, it is the Case Pages. All other content, such as physical examinations, radiography and lab tests are performed and the results requested as a result of some implicit or explicit information contained in the case pages.
Case Pages, therefore, represent the most important content in a case since they document the case scenario. Yet, the “case” is a learning, teaching and/or assessment experience from the user perspective, which means that the case content guides the case designer in the way the user experience is constructed. This leads to the question “for what purposes can I use Case Pages?”
What you will find is that case content can take many forms, and is only limited by the creativity of case designer and the goals for the case. So the following is a quick introduction as to the possible Case Pages content opportunities. Each opportunity is followed by an example list.
Pages as documentation
- Case author information
- Case edit history
- Case usage history
- Case metadata (curriculum info)
- Objectives and goals
- Competencies, EPAs
- Curriculum and accreditation
Pages as patient documentation
- Intake forms, and other forms
- Surgical, allergy, and other forms
Pages as patient historical information
- Previous episodes, encounters, intakes,
- Patient / Family histories
Pages as warnings, gotcha’s and miscellaneous information
- Teachable moments
- Applicable research
Pages as content
- Patient history,
- Presenting conditions,
- Physical exam and lab test findings and interpretations,
- Other clinical results,
- Images, heart, lung, gastro sounds,
- Radiography and other rich media,
- Physician notes and discussions,
- Diagnosis, differential diagnosis,
- Epilog, and
- Red herrings, rabbit holes, confounding results, disinformation.
Those are some examples and not meant to be comprehensive. As we construct cases as examples, we are never short on ideas, and I’m sure you will have the same experience.
Tips and Tricks: Using the new IOS and Android mobile apps to interact with the virtual patient cases.
Splash screen Request screen Example image screen
If you remember the first time you saw the MedEdQR mobile app in action, you might have found all the QR-codes cumbersome and wondered why you had to have an entire booklet of the codes just to request case information. That question was actually discussed in the April ’2017 newsletter (see “The pros and cons of input selection types”). We also realized that while the scanning of a QR-code gave access to most granular information in the case, that input method was burdensome on the users since they had to have access to the QR-code booklet all the time. Initially our hands were tied by technology – until now.
Over the past few months I discussed the fact that we were going to implement, in addition to the QR-code scanning, two additional “request information” input methods; voice and text based requests. Those input methods are now available in our latest releases of our IOS and Android mobile apps.
Using the new inputs is quite simple. If the user wants to attempt to request case pages, or case media or any other content aggregation (e.g. Vital Signs, or Complete Blood Count), they select “Speak” and say “Vital Signs” or “Case Pages”. If the underlying bot recognizes the phrase, it will return the results if any. If, by chance it can’t understand the utterance, it will display a message suggesting that you might type your request in instead using the “Type” input alternative. Thus these new input request actions practically eliminate the need for the QR-code booklets except if the user wants to deep dive into the content by requesting a singular content element such as “Blood Pressure” which is aggregated to the “Vital Signs” profile.
Will the voice and text inputs always be limited to aggregations only? An excellent question, but one we aren’t prepared to answer yet. Consider lab tests for a moment. Some of their names are either unpronounceable, hard to pronounce or contain characters that would confound the “listening” bot. Of course, the user could type them in, but in some circumstances, that too might be a chore since it’s prone to typing or spelling errors. Thus initially limiting the type or speak inputs to aggregation nearly eliminates those problems
If you have further questions regarding the voice or text input, click here to use the feedback form to make the request.
If it has been a while since you saw a demonstration of the MedEdQR platform, or if you have not experienced a demonstration yet, we would be happy to show you how this platform can enhance your educational program. Click here to request a demonstration.
Tips and Tricks: Using the MedEdQR platform in marketing, sales and case studies.
The MedEdQR virtual patient case delivery platform is not a “one trick pony” by any means. One of its strengths and differentiators is that its only use isn’t limited to student-oriented engagements. There are many types of learners that could benefit from working though a virtual patient case.
Take, for example, a company that makes medical devices, such as artificial hips, shoulders, and knees for replacement. They might spend millions of dollars in R&D updating and refining their products. Now let’s say that they have developed a new and improved version of an artificial hip and need to prepare collateral materials for marketing, and sales to surgeons, and potential patients. A great way to augment traditional materials is to create a virtual patient case to teach/train the stakeholders about the new product.
The company could start with the creation of a single virtual patient case describing a typical patient diagnosed with a condition that requires a hip replacement. This case would contain all the information about the patient (patient history, symptoms, complaints, …), any radiography, physical exams and lab tests performed and the diagnosis up to the point of selecting the make, model, and size of the replacement. Initially you might consider the audience for this case to be a resident in their orthopedics rotation. However, that is just the beginning.
Remember that one of the differentiating features of the MedEdQR platform is case cloning. So you now clone the case and add information pertinent to sales. What is the new version all about? How is it different from the previous version? What are the patient characteristics that would lead to its selection versus another device model? Embed in the case the important information necessary for sales to differentiate this new model from the competition and from your own previous or competing models.
Another cloning of the original case (or the sales version of the case) can be used for marketing. Using some of the info that sales needs, collateral information marketing information could be added to the case and the case deployed to the marketing staff as a training and reference tool.
The practitioner / surgeon would want to know the technical specs on the new device, how it compares to the former devices, what circumstances indicate its use, and so on. The MedEdQR platform can be used as the foundation for a Continuing Medical Education system delivering virtual patient cases to practitioners for credit.
These are just a few examples of how the MedEdQR platform can be used within a healthcare organization, within a medical facility or practice, or within a third party ancillary business such as a medical hardware manufacturer. Its functionality and flexibility take it far beyond the traditional medical school environment.
Tips and Tricks: Using Case Pages to Capture Goals/Objectives and to Log Changes – Hidden Pages
One of the things I learned from my experience in medical education was that, when it comes to virtual patient cases, it is necessary to document the case’s goals and objectives as well as to log case changes as they occur over time. The goals and objectives are necessary for curriculum development to document and manage case medical knowledge, clinical skills and professionalism coverage. This documentation may also be necessary for program accreditation.
One of the new features in the upcoming release is the ability to “hide” Case Pages. It hides them from the users but not from the case builders. Having this information can be very useful for accreditors, program and curricular evaluators and developers, providing them valuable data for continuous program and curricular improvement.
The other area where hidden case pages can be useful, besides developer notes and the previously noted goals and objectives, is in creating a “Change Log”. A change log is a list of the changes made to the case – the who, what, when and possibly why of how the case is evolving. This information is especially useful to those in charge of case management from the standpoint of content coverage. This information might include where the case was drawn from (the source), when it was created or cloned, original name and who created it, when it was created and what changes/edit have been made in the case over time. Because the page creation editor has the ability to add tables to the page, it is easy to build out a case’s change log functionality.
Tips and Tricks: Using Case Pages to Capture Goals/Objectives and to Log Changes
From the start, the development of the MedEdQR platform focused on two primary goals, to make the user experience as intuitive as possible by providing only the necessary and sufficient case building blocks needed while modeling virtual patient cases, and to make the modeling as flexible as possible to be able to model any virtual patient case through the use of those blocks. Those goals resulted in an implementation with just four building blocks: Case Media, Case Pages, Physical Exams and Lab Tests along with the required resources (i.e. Libraries) to help make case building fast and efficient.
Case Pages are designed to provide the documentation of the case – they represent the who, what, where, when, why and how of the case. At its simplest level, one can document how this patient came to be a patient, their past and current medical histories, and discussions about the results of any physical exams, lab tests, radiography, and treatments. So Case Pages are mainly the equivalent of the physician notes, discussions, and interpretations associated with the patient condition in some meaningful, often chronological, order.
But Case Pages don’t have to be limited to just information about the virtual patient. Often times it is important to actually document the case itself for curricular and/or accreditation reasons. While currently MedEdQR hasn’t implemented competency tracking (it is under consideration for future development), it is possible to use Case Pages to document them. Thus, a Case Goals & Objectives page could be added, supplying information to any case builder as to purpose and expectations (competencies) related to the case. Likewise, it may be important, especially over time, that information is collected about how the case has evolved and who made the changes and when. In this case, a Case Page could be used to store that that information.
The upside of this is that it is possible for case builders, using the case search ability as part of the Case List, to search for cases fitting specific profiles. Or, based on the change log page, to decide whether to clone a case to take it in another direction, or to just continue updating the current case. We are currently implementing the ability for the case builders to hide Case Pages from the users, rendering the page use strictly for the use of the case builders. Using Case Pages in this way is a precursor to our implementation of user and case metadata in Version 1.4.
Tips and Tricks: Using the MedEdQR system with an OSCE
A potential client posed the question, how can the MedEdQR platform be used in an OSCE (Objectively Structured Clinical Examination [Experience, Exercise,…]) learning encounter? As we know, an OSCE is most often used to assess a learner’s clinical and professional skills. The exercise brings together a learner (or group of learners) and a real person acting out a virtual patient scenario. The actor is known as a “Standardized Patient” (SP) and is commonly used in most medical education enterprises.
It’s interesting that this question came up, for it is one of the original use scenarios from which MedEdQR was created. Yet it has been a use scenario not often discussed.
As I see it, there are four situations surrounding an OSCE experience where MedEdQR might be appropriate, simply, pre-OSCE, during an OSCE, post-OSCE and a MedEdQR platform only OSCE. I should reiterate that in my experience, OSCEs focus on two of the three primary categories that learners address in their medical education, namely, clinical skills and professionalism. Medical knowledge is often peripheral to the exercise. But what if medical knowledge could be blended into the exercise? Could it make it more “real”?
The purpose of the OSCE is to allow a learner to practice and demonstrate clinical skills and doctor/patient interactions (professionalism, bed-side manner). Learners have the opportunity to demonstrate competency in communication, history taking, physical examination, clinical reasoning, medical knowledge, and integration of these skills. It is meant to be a fair and accurate way to assess competence, as well as identify areas that need more work and practice. So it can be both a learning experience and an assessment situation.
OSCE exercises (stations) may include:
• Clinical interactions with standardized patients: counseling, examination, history taking (most common form of OSCE)
• Examination of mannequins and interpretation of findings
• Computerized cases
• Physical Exam or Lab Test interpretation
• Order writing
• Phone calls with patients or consultants
“Preparing for OSCEs is very different from preparing for an examination on theory. In an OSCE, clinical skills are tested rather than pure theoretical knowledge. It is essential to learn correct clinical methods, and then practice repeatedly until one perfects the methods whilst simultaneously developing an understanding of the underlying theory behind the methods used. …
“In many OSCEs the stations are extended using data interpretation. For example, the candidate may have to take a brief history of chest pain and then interpret an electrocardiogram. It is also common to be asked for a differential diagnosis, to suggest which medical investigations the candidate would like to do or to suggest a management plan for the patient.” (Wikipedia: https://en.wikipedia.org/wiki/Objective_structured_clinical_examination)
Using that as the background, it is now possible to describe how the MedEdQR platform can be used in an OSCE environment.
A pre-OSCE scenario
When a learner enters an OSCE station, they are required to dialogue and build a rapport with the “patient” (virtual, real or simulated). As stated previously, they might take patient history, do a number of clinical skills exercises and attempt to use their medical knowledge to do a differential diagnosis. But what if there is other information such as patient history, documented previous episodes, or previous lab tests, physical exam results or radiography that might be pertinent to the current scenario? That puts the patient on a timeline – a patient with previous conditions and history that wouldn’t necessarily be forthcoming from the patient. A parallel virtual patient case could be created to prepare the learner for the OSCE. In one sense it would be like having an EMR available to complement what is happening in the OSCE.
An in-OSCE scenario
This is really an extension of the pre-OSCE scenario presented above. In this scenario the learner would use the MedEdQR platform provided virtual patient case as an integral part of the OSCE. The case could expand the breath of the learner / patient interaction significantly. An example of this might be the addition of specific heart or lung sounds to the scenario where the SP role needs to have a heart murmur, but the real person acting in the role of the SP doesn’t have a heart murmur. In a diagnostic situation, the ability to access lab tests or other physical exam information as well as any apropos media could be very beneficial. MedEdQR provides the means to request information or results as needed within the OSCE workflow.
A post-OSCE scenario
Following the previous two use scenarios it should be obvious that a virtual patient case could easily extend the OCSE experience by allowing (or requiring) the learner to continue the OSCE case exercise outside of the OSCE lab. For example, if the OSCE was primarily clinical skills and professionalism based, the medical knowledge aspects of the case could be further explored. A post-OSCE case could also be used as an additional assessment tool, or be used as a lead-in to a deeper version of the same OSCE case.
An OSCE using only the MedEdQR platform
Typically an OSCE is not a “virtual” experience, though the role-playing of the SP makes that part virtual. Of course, in scenarios involving telemedicine or using manikins the “virtual-ness” of the scenario comes into question. Yet, regardless of the technology used in the experience, there are benefits for using only a MedEdQR based case. The most obvious benefit is that the cost of engaging an SP is eliminated since a learner or mentor can play the role of the SP. This reduces the cost associated with simulation labs while providing the ability to create OSCE like engagements in and outside the classroom or clinical setting.
In OSCE style engagements, a learner is typically focusing on clinical skills and professionalism in their interactions with the “patient” (SP). Those physician-patient interactions can include counseling, examination, and taking their history. Why can’t those interactions be done within a virtual patient case? It all depends on the goal of the case that is eventually expressed in the content and workflow of the virtual case. Because the MedEdQR platform gives case builders the ability to add any kind of information (text, rich media, physical exams and lab tests), to be able to assess a learner’s decision making on line through the use of graded or branching quizzes and through learner’s notes capture their questions, thoughts, and even diagnosis, a virtual patient case can be a worthy replacement or substitution for an OSCE. The negative in using a virtual case in this scenario is that the learner doesn’t interact with SP for clinical skills or professionalism assessment. It has to be simulated in the virtual case. Yet this is not a problem if the OSCE scenario doesn’t use SPs but uses manikins or other non-human sources.
Tips and Tricks: Innovative ways to use QR-Codes
It’s important to remember that the QR-codes are generic – i.e. not case dependent. Once a user has logged into a case, those codes are now connected to the case. Thus it is possible to build a clinical skills case around a manikin (or skeleton for more fun), and let the users scan the codes to return the Physical Exam data or any other data apropos to the case.
There are other ways to use the QR-codes. Case builders have the ability to send individual codes to both groups of users and individual users. The use case here would be that a new lab test is now available or there are some other temporal changes in the case that weren’t available when the case was initially release. Another example would be that there is new patient information or new radiography available.
A third potential use is the possibility of using the codes in workbooks or in other printed or emailed content. A scenario can be constructed whereby specific QR-codes are printed, screen captured or emailed (the QR-code in this case would be a graphic) and those codes included in a workbook for use in a workshop or other gatherings. An example would be a seminar on clinical skills where it could be useful to have available a video example of performing a cranial nerve exam on a patient. The code for Case Media could be included in the seminar workbook and users could scan that code to retrieve the video – both during the seminar but afterwards.
There is at least one more use scenario that is possible and this scenario was one of the main features around why the MedEdQR platform was created. How about attaching QR-codes to a vest or jumpsuit (e.g. a hazmat suit)? Here any user could become an SP (Standardized Patient), providing an engagement where users use each other as SPs for clinical skills practice, medical knowledge acquisition and inter-personal skills development all structured around a virtual patient case.