Secondary Menu

RFID Stethoscope for Medical Sim

About: Most days, I am an Assistant Teaching Professor at the University of Missouri and a small business owner with decades of experience in project management, information security and videoconferencing technolog...
More About JScottMO »

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:

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.

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.

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

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.

Connect these wires to the processor/RFID Reader unit.

Insert into the entire unit into the enclosure with the SD card oriented so it can be seen through the "window" in the enclosure.

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.

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.

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.

Build a Tool Contest

Warm and Fuzzy Contest

Epilog X Contest

2 Discussions

Fascinating concept, I hope you guys take this further. If you're after realism, you probably want to make the stethoscope as realistic and lightweight as possible. While it's hard to tell without actually hefting it, it looks a little heavy/clunky (yeah, prototype, I know). Some suggestions:

- The stethoscope tubing transmits sound remarkably well (it has to, right?) so you could just use a single ear bud speaker connected (and probably sealed so it's airtight) to the bottom of the tubing. Keep the standard stetho earpieces.

- The 3D printed casing for the whole kit is an interesting design and looks well thought out, however I'd be concerned that it would detract somewhat from the experience - because an authentic experience is what you're after primarily. Could you use a standard or slightly modified stethoscope end piece (diaphragm/cup I don't know what it's called, sorry) with a small reader on each side, then wire these readers (with the headphone wire) up the stethoscope and then down into a case that the user can keep in their pocket? Then you'll have more or less an actual stethoscope and the bulk of the hardware is out of the way in the pocket (I'd also add a clip for the women trainees who often don't have pockets)

- If you did have two readers, you could then differentiate between the use of one side or the other, and encourage situation-appropriate use.

Again, I think this is a great idea and I think education in areas like this is in for a lot of change in coming years - you guys are on the leading edge, keep it up.

Thanks for the great ideas and comments. I don't know if we'll develop it a lot more right now. Our short-term goal is to get feedback, new ideas and let others take it and make it better.

"The stethoscope tubing transmits sound remarkably well (it has to, right?) so you could just use a single ear bud speaker connected (and probably sealed so it's airtight) to the bottom of the tubing. Keep the standard stetho earpieces."

Yes, we had thought about this and my colleague Chris wanted to go down this path, but I was worried about limiting the volume, and didn't want to risk blowing someone's ear drums out ! (the whole do no harm thing). But I think that it might work well, if you could make sure it is safe. Also there seems to be a wide range of quality in Stethoscopes. The one be got was $3-4 on ebay, but you can spend hundreds of dollars. So depending on the Stethoscope that the student is bringing to the simulation, they might have a different experience. That would be another concern of professors and students in a simulation environment.

I think that the use in vet schools would be very cool, as they rely on data collection more than asking a cow where it hurts!

Certainly, we agree that the enclosure could be much slicker. I was thinking a cone like shape for the final deisgn. The battery we used was overkill, and a small lipo (or seveal) could be used instead and would fit better in the enclosure. This was more for testing and proof of concept rather than production.

Thanks so much for your interest and comments. It means a lot. This is the first Instructable that we have published. Looking forward to sharing some more!