IUSM Educational Technology

Per Dr. Humbert’s request, I have completed an additional feature to the BCS checklist Master Log.  Along with the BCS checklist Master Log running every night, Dr. Humbert wanted to be able to have automatic emails sent out to 3rd and 4th year students.  These emails are an effort to notify students of BCS requirement deficiencies.  The goal of the emails is to notify 3rd year med students every 3 months of what BCS requirements are missing and the deadlines of completion.  4th year students are to receive the same basic email, along with some additional verbage, every month.  Due to the fact that 4th year students will be graduating this academic year.  The additional feature has been added to the BCS checklist Master Log.  The first set of emails went out on Oct. 15th.  In speaking with Dr. Humbert, it looks like the emails are fulfilling their purpose.  Dr. Humbert and I have been inundated with emails from 3rd and 4th year students concerning their BCS requirements.  Mostly in the area of the student not being aware that they were missing some requirements.  I have been working closely with Dr. Humbert in an effort to help each student meet the requirements and modify any incorrect clerkship encounters.

I’ve been working with Sue Maple and Dr. Hilgarth on the specifications for the ICM-I and ICM-II form modifications.  Students in Terre Haute have been issued handheld devices to log encounters as part of a new Rural Medicine project.  As part of this project, the ICM-I and ICM-II forms needed to be modified.  Both forms are to have the exact same field data, with one minor exception.  The ICM-II form will have an additional field for Group and Preceptor.  This field will be specifically for Indianapolis ICM-II students only.  Therefore, I’ve created a single ICM form that will be accessed from two separate links.  Each link will pass the clerkship value of ICM-I or ICM-II.  The new form will display the proper data based on the ICM link that was accessed.  If an ICM-I student accesses the form, their form will be identical to the ICM-II form, but without the Group and Preceptor options.  Whereas, if an ICM-II student accesses the form, he/she will have the Group and Preceptor option.  I decided to use one form mainly for the reason of future updates.  Since both forms had the exact same fields, updating one form (the ICM form) would propagate to both ICM-I and ICM-II students.  This form also incorporates some AJAX technology in displaying the Preceptor drop-down based on the Group selection on the ICM-II form.

In the past few months, I’ve been interested in creating a Google style search to the admin page in CERTTS.  In the past, the search term was based solely on what was typed in the text box of the edit/update accounts page.  I was interested in having the ability to suggest (to the user entering the search term) names in the accounts table that the user may be searching for.  The edit/update accounts page now has the flexibility to search for accounts by last name or by username.  When the user starts typing the search term, a Google style suggestion box appears below the text box.  Based on what the user is typing, the script will access the database and display last names or usernames similar to what the search term is.  As the user completes more of the text in the search box, the possible matches will become fewer as the suggestions narrows down the possibilities.  This allows the user to begin the basic spelling of the name being searched and then choose from a drop-down list of suggestions that match the criteria.  Now that I’ve completed this suggestions script, I’m looking into ways that this suggestion style search can be implemented on more of the CERTTS forms.

Wilfredo and I discussed the issue of student data being stored on the public syncing stations when a student syncs forms data.  This data not only is not needed, but the data is sometimes personal in nature and (over time) takes up disk space.  In the past, the directory that houses the synced data was deleted manually.  Which in some instances can take up quite a bit of time.  We’ve discussed the possibility of creating a nightly process that will delete that unwanted and unneeded synced data.  I have completed a system process, installed on the public syncing station in Wilfredo’s area, that will delete that data automatically each night and restore the Palm OS directory.  The process will be tested over the next few days and will be deployed to all public syncing stations when I have confirmed that the process runs without a hitch.

Stacey Jackson has requested that additional names be added to the ‘Supervising Physician’ field and an additional location be added to the location field on the EM clerkship form.  Previously, students needed to type in the supervising physician’s name in the free text field, when completing an EM clerkship form.  Due to the fact that ‘Elkhart General’ needed to be added to the list of locations and the fact that there were specific physician names that needed to be accessed via a drop-down list, modifications were needed for the form.  I’ve incorporated AJAX into the EM form.  Now, when students select the location of the encounter, they will see different types of fields for the supervising physician field.  For instance, when a student selects the Elkhart location, they will be supplied with a drop-down list of the physicians.  If a student selects any other location, they will be supplied with a free text field to type the physician’s name (as they have in the past).  Now the EM form satisfies the needs of all students filling out an EM clerkship form, no matter the location of the encounter.

Along with the BCS Clerkship log, Dr. Humbert wanted the logs (as they run nightly) to email any students, once a month, that have missing BCS encounter data.  I’ve added that functionality to the ‘filtered’ BCS log.  Any students in the current graduating class (4th years) that show up on the log with missing encounter data, will receive an email that details what encounters are displaying on the reports and what is missing.  These students will be able to see what encounter types they have met the minimum requirements on and what encounters they have not.  This email will also display a message (written by Dr. Humbert) explaining the timeframe in which these students have to complete these requirements.  The email script is working correctly and is ready for use.  I’m just waiting for Dr. Humbert to supply me with the text that will be incorporated on the emails and what the deadlines will be.

Dr. Humbert made a request to have an updated BCS Clerkship log similar to the EM Clerkship log.  He wanted to be able to access an html style page that would have up-to-date info on students who have logged BCS encounters.  This becomes particularly relevant during the student’s 4th year.  Students are required to have a certain number and type of BCS encounters logged before graduation.  This log would enable Dr. Humbert to track student progress in an effort to communicate with the student on necessary remediation.  Two BCS logs have been created.  The first is a ‘filtered’ log that displays all students who have logged BCS encounters, but are missing some of the minimum requirements for encounters.  The second is an ‘unfiltered’ log that displays all students who have logged encounters, whether they have met all of the minimum requirements or have some discrepancies.  Both logs are updated nighly by a system process that I’ve developed.  Each log links the student name to their individual BCS reports.  Dr. Humbert is able to quickly and efficiently manage progress of the students and access the full details of the clerkship encounters.  The logs have been running for a few weeks now and (as of yet) Dr. Humbert has not had any modifications to the logs and how they display the data.

As with the database table changes, there was a need to modify the sync scripts and clerkship reports files for the new school year.  Previous years have had little modification in the sync scripts and clerkship reports.  However, this year, I needed to make adjustments for the different tables that now store data for clerkship encounters and BCS encounters separately.  These modifications had to incorporate features that would know which database table to retrieve BCS encounters, depending on the year’s reports being viewed.  For instance, up until the 08-09 school year all clerkship encounter data, including BCS data was stored in the same db table.  The 09-10 school year’s BCS data along with future year’s BCS data, will be stored in separate db tables.  When a student, clerkship director, or CERTTS admin chooses a report year, the clerkship reports and admin tools need to know which table/tables to query the data.  Sync scripts also had to be modified to write Pendragon data to the correct db tables.  CERTTS admins have some additional tools they can use to create encounters, copy table data to other years, create BCS encounters from clerkship encounters, etc.  All of the student, clerkship director, and admin reports have been modified and are reflecting data correctly.  All sync scripts and admin tools are creating and modifying encounters and encounter data correctly.

With the new school year, there was a need to update the Pendragon clerkship forms that the students use to log encounters with any modifications desired by the Clerkship directors.  Each form has been modified based on the new requirements and will be distributed to the students during their next hotsync.

Dr. Humbert requested an Excel spreadsheet of BCS data for the 08-09 school year.  He wanted to review all encounters logged as BCS so that he may be able to detect trends in logging encounters.  That data has been exported into an Excel spreadsheet and sent to Dr. Humbert for review.  There may be some adjustments in the types of column data he would like to see in addition to the already created report.  If so, an updated report will be exported.