EBME Forums Forums Maintenance Technical Assistance Communication with Alaris/Asena Syringe Pump

Guys
Does anyone been able to communicate with Braun infusion pumps. trying to connect to a braun Infusomat Space pump. I think there is a European version that goes with a different name.

Thanks
Tim

No money to be made from it?

What I would like to see is an Open Source library of the data comms available from all medical devices, with full technical data, plus pin-outs and what-have-you.

Then ... the data inputs expected by the various "clients", be they "intelligent" (or central) patient monitors, other devices, hospital information systems ... or whatever (including our laptops, for example).

Then ... we could begin to think about the "bit that goes in the middle" - which (for want of a better description) I shall call the Interface Box.

These Interface Boxes will need to be as simple as possible, and cheap (as one will be needed for every connected device).

In addition to Input and Output, I imagine they will also need a third port ... one that allows us to interrogate what's going on, and "inject" our code(s) in order to control the thing. That one could use BlueTooth ... whatever.

Something like this could be the basis of an interesting project (for anyone still looking for an interesting project, that is).

geoff,
What you are suggesting is a interface box that contains Device Drivers for all kinds of medical devices.
If the data can be converted into readable format i.e. .csv or .xls that would be nice.
I mean the ability to save the data in .csv format and then view data for troubleshooting purposes.

Thanks

The Interface Box I envisage would be essentially passive - "driver" is not the word I would use - and it certainly wouldn't (couldn't) forsee the communication protocols from (and to) every device!

Instead I would suggest the word "interpreter" - being the computer code that would do the work of marrying up the output from one device to the input of another (device, network etc. as mentioned before). That's what I meant by "the bit in the middle".

But yes, we (you, me, or the next guy) would have to write that code! And, as it would be "our" code - that is, we would have full knowledge of it - we should be able to extract from the data stream whatever our little hearts desire (export to our favourite formats, and all the rest).

Meanwhile (and hopefully), the hardware of the Box itself would be as simple (and cheap) as we could make it.

Conceptually then, a sandwich:- on one side we have the active device (one that we shall know all about from our Library of Device Comm Details); on the other the client we are passing the data to (again, about which we shall need to know all)!* And the special bit in the middle will depend upon what device(s) and (or) network(s) etc. we are dealing with. If we write our code well, we should (I expect) be able to re-use at least the core of it over and over again.

OK ... it's only a dream. But it might be a bit of fun drawing up (and agreeing) a spec.

* It could also be in the other direction (or, indeed, both), but let's keep it simple for now.

Geoff,
I would be more than happy to discuss the overall Architecture and design level of the system. However we need someone who has C++ or Java software programming experience. There is a lot of details required for such a project and I think we should start from the documentation process. Requirements and Analysis phase.

Let me know..
thanks
Tim

Better yet, use QuickC ... or Turbo-C ... or any of the other good old C compilers that are freely available for nowt these days. Not to mention using "basic" C code that is readily transportable across various flavours (plus - with a bit of effort - into other programming languages) and OS platforms.

Open Source!

"Knobs and whistles" (and pretty displays) could always come later - if at all - once the real work has been done.

Geoff
I'd prefer Turbo C++ or Java caviet for programming for embedded real-time systems. On the hardware side we could use Arduino or BlackbeagleBone. However they are mostly use LINUX systems.

The CORE- CLIENT system would require:
1. Physical connection to the device (LAN, Serial, Canbus, Wireless)
2. Ability to extract raw data in real-time ( 1Hz upto 400 HZ Sampling rate) both Numerical and Waveform
3. Data parsing of the raw data
4. Translate the parsed data into meaning data format i.e XML, HL7, etc
5. Display Numerical and waveform data in real-time.
6. Data storage of translation data.
7. Ability to set the data rate of storing the transitional data. (i.e every second, every minute etc)
8. use open source DDS (Data Distribution Service) as communication and transport layer for data instead of TCP/IP and UDP or use Jini Technology by SUN if using Java code.

All that looks a bit too modern - or advanced - for me, Tim. I have enough trouble these days just trying to maintain legacy stuff.

I had best just leave you to it, Mate.

Meanwhile (and as you must know), there is a fair amount of stuff about all this available on line. Lots of "papers", and talk about "Physical Layers", "Application Layers" ... and so forth; but very little about "actually doing it"! Unless, that is, folk have been beavering away behind the scenes on their individual projects, but now prefer to keep their lamps well and truly hidden behind* their bushels!

* It should be "under", but it didn't seem to read right.

Hello Geoff,
The big mighty million dollar question is!! do we have any developers who can code in C++ or Java. If there are any java developers I can help them to find the source code.

But we need someone who is sauvy in Java code and in embedded programming.

So how about it Geoff?
What are your thoughts on that.

Cheers