Introduction: RFID Stethoscope for Medical Sim

By Visit My Site!
About: Most days, I am an Associate Teaching Professor at the University of Missouri and a small business owner with decades of experience in project management, information security and videoconferencing technology.…

Note: While this instructable is published under J Scott Christianson's account, the credit for this project is shared equally between Scott and Chris Sanders.

Request: If you are an Instructables member, please consider voting for this project in the three contests in which it is entered (click on vote icon above). We'll use any contest prizes for community, undergraduate and/or graduate classes!

Background

In health care, a Simulated Participant, Standardized Patient, or Sample Patient (referred to as an SP) is an individual trained to act as a real patient in order to simulate a set of symptoms or problems. Simulated Patients have been used in the education and evaluation of an array of health care providers including nursing, medical, pharmacy and social work learners.

The standardized patients are taught to deliver specific patient case information to learners. The standardized patients communicate and deliver the patient's history in a way that meets the needs of the specific learning experience (usually orally or using simulated patient records). The history portion of the SP simulation experience can be reproduced with effective standardized patients and retains a high fidelity to typical patient encounters.

However during the encounter, the SP is not able to simulate certain physical findings that the learner may attempt to obtain by examination: for example, an abnormal eye exam, heart murmurs, abdominal noises, or crackling lung sounds. These findings must be delivered by means other than observation by the students, thereby interrupting the patient encounter. The lack of realism can introduce disruption and may present a less authentic experience.

In this project, we were specifically looking for methods to improve the delivery physical findings and represent physical elements of an SP in a way that continues to assist the learner in a realistic patient encounter. As such, our first step was to inventory the methods by which findings are, and could be, delivered to the learner.

Step 1: Options for Findings Delivery

Option 1

Find ‘real’ patients with abnormal findings that the students could examine and practice their skills. This would represent one of the best possible solutions but is unrealistic for several reasons: Lack of available patients who would be willing to serve as standard patients; Any such SPs would be limited in the encounter experiences they could provide (a one-trick pony so to speak).

Option 2

Find standardized patients with medical conditions to fulfill the role for learning experiences. An example, find standardized patients with fundoscopy eye exam abnormalities. Find standardized patients for death and dying scenarios by finding standardized patients that have experience with abdominal cancerous masses. As with Option 1, while this might represent one of the best scenarios for findings delivery, it is unrealistic to use for at scale.

Option 3

Utilize a normal healthy SP to represent medical history, some physical findings and hard to recreate physical findings through paper findings cards. Medical findings are delivered to a participant when appropriately triggered. The standardized patient delivers paper-based findings cards during the encounter. Using this method the SP can deliver findings card that states ”heart murmur found in M3” or “lungs sounds are crackling”. These paper cards can be held by the patient and deliver to the learner during an encounter. This is the currently used system at the simulation center. This has several problems/risks:

  • The SP can drop or mix up the cards.
  • The learner does have the opportunity to come in contact with the patient in the same way they would in a "real world" encounter.
  • The learner may be misled by seeing that the SP has many or few cards, perhaps indicating the complexity of the simulated case.

Option 4

Utilize a normal healthy SP to represent medical history, some physical findings and hard to recreate physical findings through electronically generated methods. The standardized patient delivers electronic based findings through a tablet device during the encounter. The method allows the standardized patient to select and present a mix of digital content including images, sounds or video into the experience of the learner. This can be accomplished by the standardized patient presenting the appropriate electronic content via a computer or tablet device when the learner asks to investigate a specific physical aspect of the human body.

Option 5

Utilize a normal healthy SP to represent medical history and some physical findings and represent hard to recreate physical findings through electronically generated methods. An additional standardized assistant can remotely view the live interaction between learner and standardized patient and then identifies triggers and delivers electronic based findings through a tablet or computer device during the encounter. The method allows the standardized patient to focus on representing the history part of the encounter and a remote assistant then triggers the appropriate digital content including images, sounds or video into the experience of the learner. This can be accomplished by the remote assistant presenting the appropriate electronic content via a computer or tablet device when the learner asks to investigate a specific physical aspect of the human body.

Option 6

Utilize a normal healthy SP to represent medical history and some physical findings and represent hard to recreate physical findings through electronically generated methods. Allow the learner to select the electronic based findings through a tablet device during the encounter. The method allows the learner to select and observe a mix of digital content including images, sounds or video into the experience. This can be accomplished by the learner selecting appropriate electronic content via a computer or tablet device when investigating a specific physical aspect of the human body.

Option 7

Utilize a normal healthy SP to represent medical history and some physical findings and represent hard to recreate physical findings through electronically generated methods. The standardized patient can deliver electronic based physical findings through defined voice commands to an in-room computer device during the encounter. The method allows the standardized patient to command the display of digital content including images, sounds or video into the experience of the learner. This can be accomplished by the standardized patient triggering voice commands for appropriate electronic content via a computer or tablet device when the learner asks to investigate a specific physical aspect of the human body.

Option 8

Utilize a normal healthy SP to represent medical history and some physical findings and represent hard to recreate physical findings through electronically generated methods. The standardized patient is outfitted with an array of sensors (QR codes, lights sensors, pressure sensors) to detect learner interaction. Based on the learners interaction sets of sensors and processors, sound output and displays can represent the appropriate electronic content. One example would be the use of a stethoscope that plays the appropriate content when placed in the correct location for lung or heart sounds.

After considering the options, we focused on developing a project to develop an open-source hardware and software project to deliver findings triggered via a sensor (Option 8).

Step 2: Hardware Design

We choose to use small RFID "buttons" that could be attached to the SP. Then a RFID reader would be used to detect the serial number of the RFID button and would play a corresponding audio file to a headphone output that the student would be using. This way, multiple sounds could be played during one encounter with this RFID stethoscope.

We choose to use the open-source Arduino platform for the RFID stethoscope, and specifically some hardware from TinyCicruits (https://tinycircuits.com/), which produces and sells a very small Arduino compatible platform. In this case, each stethoscope was made of the following components:

  1. ID-12LA RFID reader from ID Innovations (ordered from Sparkfun Electronics)
  2. Adapter board fo r RFID Reader from Sparkfun Electronics
  3. A bunch of RFID Buttons
  4. TinyDuino Processing board (the microprocessor)
  5. TinyDuino Audio Board (provides output to headphones)
  6. TinyDuino Memory Board (with microSD card for storing audio files)
  7. TinyDuino USB Board (allows for downloading programs, etc)
  8. TinyDuino Protoboard (for connecting the TinyCircuit "stack" to the RFID reader)
  9. A cheap stethoscope from ebay (~$4.00)
  10. A set of iPhone headphones
  11. A cheap USB Battery Pack from the local Best Buy to power the device. NOTE: You can't power it from a coin cell battery. To much power draw.

We also liked this RFID reader, because with the low power provided to the reader it would have very limited range.

The tiny circuit boards connect together and a small bolt with spacers is used to join them together into one unit.

Here are the pins that are used by the boards (and therefore not usable for other functions such as connecting to the RFID reader):

TinyDuino USB Board

  • Digital Pin 0
  • Digital Pin 1

TinyDuino Audio Board

  • Digital Pin 2
  • Digital Pin 3
  • Digital Pin 4

TinyDuino Memory Board

  • Digital Pin 10
  • Digital Pin 11
  • Digital Pin 12
  • Digital Pin 13

TinyDuino Proto Board

We connected the following pins from the Proto Board to the RFID reader

  • Digital Pin 8 on the Proto Board to D0 on the RFID Reader
  • Analog Pin 0 Connected to Res on the RFID Reader (future use: the RES pin can be used to see if the reader is still over the same RFID chip)In addition the following connections are made from the Proto Board to the RFID Reader
  • GND to RFID GND
  • GND to RFID FORM (defaults the RFID chip to RS232)
  • VCC to RFID 5V

The battery just connects to the USB connector when the unit is in use (and to a computer when being programmed). You must power with an external battery, a coin cell will not be enough.

Step 3: Enclosure

We 3D printed a custom enclosure for the RFID Stethoscope and small "jars" for the RFID buttons.

We used TinkerCAD to design the enclosure and jars. Here are the designs that worked well for our components and battery. You can modify for your battery/needs.

The enclosure is designed with a slot that can be used to access the MicroSD card (where the audio files will be stored).

Step 4: Programming the Arduino

Below is the link to obtain the code for the Arduino. This code has been optimized to use the least amount of memory possible. We found that once the program size gets to point that there is only 100k of free memory, the device will have memory issues and crash, requiring a restart.

The current code is maintained on Github at: https://github.com/JScottMO/Open-Source-Sim-Stethoscope. Please check there for updates and to submit your improvements.

To match the sound that you want played with the RFID serial number, you will need to edit two character arrays: allowedTags and SIMfiletoplay. In the example below, when the serial number 7C00563C5D is read by the microprocessor, the file h1.wav will be played from the microSD card.

char* allowedTags[] = {<br>"7C00563C5D", // Heart 1 Tag 
"7C0055ED87", // Heart 2 Tag 
"7C0055FAF6", // Heart 3 Tag 
"7C0055EE46", // Lung 1 Tag 
"7C005634C8", // Lung 2 Tag 
"7C00561822", // Lung 3 Tag 
};

char* SIMfiletoplay[] = {
"h1.wav", // Heart 1
"h2.wav", // Heart 2
"h3.wav", // Heart 3
"l1.wav", // Lung 1
"l2.wav", // Lung 2
"l3.wav", // Lung 3
};

Edit: If the RFID tag is not in the program, then the stethoscope will report "Tag not in database" and then Read the RFID tag number to you.

For initial setup, we found it easier to use an USB RFID reader. As long as you use the correct frequency (125kHz), it should not matter which one you use. This is the USB RFID Reader that we used: https://www.olimex.com/Products/Modules/RFID/MOD-R...

It was nice since it emulates a keyboard. Just put your cursor in a text document, wave a RFID button over the USB stick and it types the ID into the document. This one should also work: https://www.aliexpress.com/item/Mini-Portable-USB-...

Once the program is loaded, the last step is to power off the Arduino, load the wav files on the SD card and insert it into the device. It can then be mounted in the case and used.

A note about the wav files. They have to be uncompressed 22kHz, 16bit mono Wave files. We used this site to convert our files: http://audio.online-convert.com/convert-to-wav

To test the system, we generated audio files on the mac for 0-9 and A-F using this procedure ( http://www.makeuseof.com/tag/siri-voice-mac/) and the converted them using the above site. These files are included in the Github repository listed above.

Step 5: Putting It All Together

Final Assembly

  1. Thread the USB cable for the battery and the Audio cable for the headphones through the top of the enclosure and all the way through the enclosure.
  2. Connect these wires to the processor/RFID Reader unit.
  3. Insert into the entire unit into the enclosure with the SD card oriented so it can be seen through the "window" in the enclosure.
  4. Plug in your battery and then you are ready to go!

Future Possibilities: Hardware and Software

A couple of things that would be nice to do with this platform.

  1. We experimented with using the stethoscope to read the RFID IDs to us. That worked well, and we thought that we would implement a small switch that would allow one to enter this mode. However, we were not able to fit that into the program and keep the memory usage below the point where the device became unstable.
  2. Instead of putting the RFID serial numbers and the names of the sound files into the code, which requires compiling and downloading, it would be a lot better if the program would simply read the tag IDs and names of the sound files from a text or csv file that is on the SD. Again, we had memory problems when we tried this

Since we started this project a number of years ago, there have been some great new hardware platforms released, namely the Raspberry Pi Zero, which have been released. These platforms might not have the simplicity of the Arduino but would not have the memory issues, etc.

Possibilities: Applications

  • Besides use in simulation environments for human health, we have had some interest in use in veterinary training.

Contact information:

Please let us know your feedback ideas and suggestions.

Chris Sanders
Operations Manager
Shelden Clinical Simulation Center
University of Missouri
sandersc@missouri.edu

J Scott Christianson
Assistant Teaching Professor
Management Department
University of Missouri
christiansonjs@missouri.edu