Can anybody suggest a make and model of vital-signs (i.e. ECG, SpO2, NIBP, TEMP) or low-level multi-parameter patient monitor (ECG, RESP, SpO2, NIBP, IBP, TEMP) that has the capability of producing near real-time outputs using RS232 or RS422 communications?

Ideally the monitor should supply power from the serial port connector as well and produce e.g. 12s-interval physiological data (rather than trends) of all parameters and possibly alarm-status and time-stamps, etc, etc. The data acquisition needs to be done whilst monitoring in-situ (patient-isolation will not be an issue). If you have any experience of interfacing such monitors and can give me some advice, information, or contacts, then that would be a great help. Thanks.

Sounds interesting....

There is software available to 'printer emulate' if required and capture the output from most medical devices that may not have a dedicated rs232 link, but provide a continuous printed output if hooked up to the printer.

Alternatively RL I do have the odd bit of sourcecode in VB and Quickbasic (ideal for prototyping) if your intending on creating your own application.

I've written the odd bit of communication software to transmit / recieve ascii data from devices (biotek 601 pro) but pretty much any medical device is the same if you can get your hands on a copy of the command set for it.

About 3 years ago, datex were prototyping some continuous monitoring software for their ADU series anaesthetic units to aid servicing, so I'd hazzard a guess that most of their AS3/AS5 multi-paramater units will be suitable for the job provided you could get the protocol off them.

I dont know in what context your wishing to use communications, is it a sleep disorder clinic, personal project, or isolation ward type enviroment that you need it for?

If theres anything I can do to help, dont hesitate to ask

Joe.

Take a look at; http://connected.welchallyn.com/

Thanks for that Joe - I'd thought about the printer link and decided that it was probably easier to use RS232/RS422 rather than create a PCL driver, for example, for the embedded system I'm trying to develop.

I've got the Datax-Ohmeda communications protocol and the physiological data set information as well. Unfortunately getting hold of a compatible monitor for a few months, for development purposes, is going to be difficult.

I'm actually planning to start developing a dedicated interface module (specific to the monitoring in use; doesn't have to be RS232/RS422) and an embedded smart-alarm processing unit with the capability of issuing PC generated MP3 files of developed alarm-sounds.

Effectively real-time processing of physiological data, smart-processing and analysis and production of appropriate alarm sounds (an MP3 player, from scratch).

A sort of thing that is used to test the concepts of human factors in monitoring and an attempt to increase the sensitivity and specificity of alarms, reducing the incidence of false positives i.e. unecessary nuisance alarms to you and I.

A lot of monitoring has sophisticated processing but sometimes the audible alarms leave a lot to be desired from a human factors aspect. It's for a post-grad project. Thanks again.

Thanks Jonathan - It was my intention of contacting soon but I'll try the link first - we have a lot of Welch Allyn monitors on site.

if its just for development / trial then maybe the Ohmeda 3740 pulse oximeter might prove usefull, most hospitals have these kicking around and they output data every 2s through the serial port. They can work under computer control and I do have a copy of the protocol handy if you fancied a play with one of them.

You must be reading my mind Joe - I'm in the process of resurrecting an old 3700 at the moment, from a selection of scrapped components. We have the comms protocols and some associated software but if I have any problems I'll get in touch if you don't mind. Many Thanks.

If anybody else has any suggestions in the meantime they will be gratefully received. I always like to have a plan-B.

Try speaking to Lyn Davies at Stowood Scientific Instruments, Oxon. He has written such software for his Winvisi sleep monitoring system

Thanks for the suggestion - I think I'll be able to manage the software - it's just ideas for a monitor I'm after, cheers.

Like I mentioned RL, i do have the protocols with examples available for the 3740 (from a book "interfacing the IBM PC with medical equipment")

Also, in the same book was the interfacing protocol and examples for use with the graseby 3xxx series infusion pumps.

If your into X-ray then you might be interested in the victoreen xray tester as that has some interface / protocol examples in the tech manual.

All the above ^^ have examples in quickbasic which is ideal to 'get it going' but as with most its not too hard to port these into VB or whichever language you wish to use.

Its one of those things which has interested me for some time, but time being the thing which none of us have much of.

****ty death Joe, you sound like you know what you're talking about!!

Thanks Joe - I managed to get the old 3700 up and running and checked out the comms with the Ohmeda Commander software - everything's ok.

I'll take you up on that offer of the protocols, etc, etc, if you don't mind. I've sent you an email (your Hotmail address).

Got the e-mail thanks RL, sent a reply.

Many thanks Joe; I've just received that information - it's just what I wanted. I'll copy and return ASAP, so I don't forget. Cheers.

RL,
SPO2 and BPM aint too much of a problem, but I was curious to how you would decipher the ECG, NIBP,and TEMP from the data?
Would the output consist of 5 lines of serial data?
I like the thought of the MP3 samples, the thought of listening to a Britney Spears alarm sound when a patient has gone into vent.fibrilation is a novelity I must admitt .

Chris-H

Well Chris serial Data is usually transmitted as a sequence of ASCII characters. Any number can be represented by a ASCII string of numbers, in fact; it just depends on how you want to format it.

"Instantaneous" data, sampled at appropriate rates (Shannon, Nyquist and all that stuff) can be used to capture real-time waveform data, as well as the numeric parameter data, if need be. So I don't really see acquisition of any slowly-changing physiological parameters as a problem.

SpO2, BPM, Sys/Dias/Mean NBP, Temps, etc - it's all the same to me as long as it's valid data. Most manufacturers produce standard data-sets for each parameter that can be used to access the relevant data. Of course, if your monitor only produces SpO2 and HR then that's all you can process using a single dedicated interface but the interface does not have to acquire serial data - it could contain an A-D.

Numerical strings of ASCII data can be quite easily converted to numbers stored by a computer. As for the MP3 sounds - I was thinking more along the lines of the standards and recommendations for alarm sounds that the manufacturers can't always be bothered to implement and that certainly don't exist in older generations of monitors out there; plus appropriate alarm hierarchies.

Human factors researchers, scientists and engineers have actually suggested music as an efficient means of alerting or giving cues to clinicians and Nurses i.e. easily recogniseable and easy to associate with urgency of alarms.

Dear all, i am excited to get to this forum thread, i wonder if more updates to the thread could be done?

RL, I wonder if you have gotten the protocol that you needed?

Joe, I wonder if you could send me the related protocol and maybe more of the details?

I am working on the SpO2 part in similar project now. Hope to hear from the 'seniors'. =)

Can't take time to reply at the moment but I will make time to respond ASAP.

Wow! Something really interesting at long last (but, I notice, resurrected from memory lane – and thanks to Samuel Ng for digging it out). Joe, do you still have the book you refer to (…any one else have a copy of “Interfacing the IBM PC with Medical Equipment")? I have cash waiting. Come on then Richard, how did it all end up?

I did respond to Samuel's request in a private email Geoff. With the RS232 protocols supplied by Joe Emmerson I was able to achieve what I wanted to. Thanks Joe.

All very mysterious. A college project, I assume. But RS-232 is a very handy protocol. Almost universal, even. My own interest (casual, of course) used to be in collecting the pin-outs of the various data interfaces found on the back of various pieces of equipment. For instance, on some infusion pumps you can pick out battery voltage on certain pins. For real fun, you can get bits of kit talking to each other (ie, sharing data) – hardware hacking, you might call it (and before anybody starts moaning – only on condemned junkers, of course). Maybe I’ll restart my collection and write my own pamphlet all about it (…yes, sad I know)!

Yes a school project Geoff. I was more interested in establishing a relatively simple method of managing parameter alarm hierarchies and providing alarm sounds based on the findings of human factors research rather focussing on the RS232 communications. Once I'd got the bi-directional, interrupt-driven, communications functioning, the oximeter alarms/alarm-limits/volume/settings under control and parameter data collection then I was happy.

is there anyway that i might be able to get the communication protocol from you with permission from joe for a particular model of probe?