Users

While the Case Builder (CB) creates the case, the student engages the case via validated mobile device either as an individual or within group collaboration.  Once the MedEdQR application is launched on the mobile device and the device is validated, the User enters their ID and the application returns a list of possible cases they can access. If the User has the Faculty or Assistant role, they can also control case availability and tracking. The User accesses case information by scanning generic QR codes. Examples of where the QR codes might be located are: integrated within a case workbook that the program already has, located in a code “booklet” of either all codes or just case specific codes, located on a manikin or SP, or integrated / located within a program’s Learning/Content Management System. The scanning activity simulates the medical student requesting patient information, physical exam/test results, or case media. If student tracking is active, the student’s scanning actions are recorded on the web-based system for future reporting. If content progressive release is engaged, case page information is only released (made visible) to the student once prior pages have been viewed.  This way the student cannot potentially view the diagnosis before working through the case.


User Overview

There are four types of users; the Case Builder who is the only user with access to the web application, and Students, Assistants and Faculty who only have access to case information through the use of a validated mobile device. It is the responsibility of the Case Builder to manage users. All users are defined by their Username, UserID, Cohort, Email address, Department and role. An Assistant is a Student that aides the faculty or tutors in the delivery of a case. The only difference between a Student and an Assistant is that the Assistant has access to some additional “faculty only” features in the mobile device application. Users gain access to cases through two mechanisms; a user is associated with an individual case or, a student is associated with one or more groups to which cases have been associated. The latter association, users to groups, has been implemented to minimize CB’s time. Utilizing a familiar interface, departmental programs and their groups are listed, and the CB selects the target group. The current members of that group are displayed as well as a list of students organized by Cohort. The CB can select an entire Cohort, search for a specific student or open the Cohort folder and search for students to add.


Simplified Student and Faculty Management

User management consists primarily of four functions; adding users to or removing them from their department, keeping user information up-to-date, adding users or removing them from groups, and managing user mobile device validation. Departmental Case Builders (CB) are responsible for user management.

Users (Students, Assistants, and Faculty) can be individually entered or imported at any time. Importation uses .CSV file, which can be dragged and dropped into the import interface. Four pieces of information are required for each Student or Assistant (Name, ID, Cohort, and Email), and only three for Faculty (no need for Cohort). During the add/import workflow, the user type is requested, and optionally, the CB can select a default group to which users are automatically added.


Using the MedEdQR Mobile App

The user starts the MedEdQR smart mobile device application – in this case the pictures are from an Apple iPhone 6.

The Splash screen (the MedEdQR logo) is followed by an attempt to validate the device. Initial validation is done by scanning a special QR code that decrements the total number of possible validations for the user’s department and opens the door for the validating device to access departmental case information.

Now that the device is validated, the user’s ID is required followed by a request for the case number to be accessed. If the case number isn’t known or is already shown (the user has re-entered the app without an app closure in between) and the user wants to change the case, they can access the navigation menu and select the case from their “accessible case” list. Once in the case, the “Scan” screen is displayed whereby the user scans a code from the QR code booklet, from their paper-based case workbook, or from any number of other sources depending on how the case is being deployed.

In the example at the left, the “List Pages” QR code was scanned and the list of case pages was returned to the user. The user selected the “Patient History” page from the list and that content was displayed. Swiping to the left, the user is returned to the page list at which point they then request the “Patient Picture”, the “Hurt Scale”, case notes, bowel and heart sounds, X-rays and other case information. The last page access is the diagnosis page.

It is important to remember, that cases are structured by the departmental Case Builders. MedEdQR does not force cases to be structure in any particular manner.


Managing the Mobile Devices

Each department has a maximum number of mobile devices that can be validated (referred to as the “license pool”) and is give a unique token QR code (the “token”) to be used in the validation process. The maximum of validations is established through the department’s licensing agreement with MedEdQR. Within the web application UI, the CB emails the validation token to one or more users. Once received, the user starts the MedEdQR mobile app and scans the token code. If the number of licenses hasn’t been exceeded, then the user’s device is validated and can be used to access departmental cases. The CB has the ability to also rescind validations if necessary and those validations return to the license pool.

We use cookies to give you the best online experience, and improve service performance. By agreeing you accept the use of cookies in accordance with our cookie policy. For more information about how we use cookies and the choices you have with respect to control of cookies, please read our Privacy Policy.

By continuing to use this service, you agree to our use of cookies as described in the Privacy Policy.