Your comments
Hello Jeff,
Thank you very much for response. I'm trying to find the code that acts as a Gateway between DDS and Node.js? Can you please provide the code for that? or guide me where the repository is located?
Thank you
Kind regards
Tim
Thank you very much for response. I'm trying to find the code that acts as a Gateway between DDS and Node.js? Can you please provide the code for that? or guide me where the repository is located?
Thank you
Kind regards
Tim
Hello Jeff,
Thank you very much for your kind response.I'll read and see how we can implement it with MQTT/CoAP with the information you have provided.
Thank you most kindly,
Kind regards
Tim
Thank you very much for your kind response.I'll read and see how we can implement it with MQTT/CoAP with the information you have provided.
Thank you most kindly,
Kind regards
Tim
Hello Rado,
Which Alaris pump model are you guys trying to interface with? and do you know the sw firmware version on the model?
Let me know. contact me at my e-mail rajahtm@mail.nih.gov
Cheers
Tim
Which Alaris pump model are you guys trying to interface with? and do you know the sw firmware version on the model?
Let me know. contact me at my e-mail rajahtm@mail.nih.gov
Cheers
Tim
Hello Jeff,
Below is a recently published article that might be an interest to your group.
Using machine-to-machine/"Internet of Things" communication to simplify medical device information exchange
by Christian Peterson from University of British Columbia, Vancouver, Canada.
using MQTT protocol instead of using DDS.
Cheers
Tim
Below is a recently published article that might be an interest to your group.
Using machine-to-machine/"Internet of Things" communication to simplify medical device information exchange
by Christian Peterson from University of British Columbia, Vancouver, Canada.
using MQTT protocol instead of using DDS.
Cheers
Tim
Hello Nathan,
Do you have the communication protocol documentation handy? I think in the documentation it does illustrate the serial RJ45-DB9 wiring configuration. As a matter of fact you can make it your self which would be much much cheaper, you might be able to get all the items you need from your Biomed department.
Another method to check the wiring configuration, would be to use a digital multimeter, use it as a continuity check (https://www.youtube.com/watch?v=bF3OyQ3HwfU). Check each end point on the connectors one by one.
Hope that helps.
Cheers
Tim
Do you have the communication protocol documentation handy? I think in the documentation it does illustrate the serial RJ45-DB9 wiring configuration. As a matter of fact you can make it your self which would be much much cheaper, you might be able to get all the items you need from your Biomed department.
Another method to check the wiring configuration, would be to use a digital multimeter, use it as a continuity check (https://www.youtube.com/watch?v=bF3OyQ3HwfU). Check each end point on the connectors one by one.
Hope that helps.
Cheers
Tim
Hello Jeff,
To answer to your previous statement. I'm content to see MDPnP group do whatever they want. However I would suggest to implement multiple solutions and compare the results to understand the true potential of technologies available at the prototype level. We should not be married to a single approach but be able to embrace alternative and improved technologies that should be considered and compared based on their functionalities, capabilities and implementation. Hence a true comparison on each technology should be reviewed before a final adoption of a particular technology has been decided. It's fine to embrace a single technology (such as DDS) for your particular use by the MDPnP group, but to endorse it for the entire community should necessitate a wider view. I think other communities such as the federal agencies should have been consulted.
To my knowledge most technology exists and enjoys widespread use before a standard is published. Standard is an end goal, not a starting point. Take for example Linux which has no standard's body behind it, nor does Java, C, C#, or x86. We should be more focussed on technologies that provide full availability of the technology details and ability to use, modify, and redistribute among the community.
I do not think it is possible to attain a goal of of 10ms between off the shelf commercially available ventilator and x-ray/CAT/MRI scanning machines. Because the ventilator itself as to my knowledge spits out a waveform with a latency of >100 msec+. May be you aware of any manufacturer that provides ventilator/s with waveforms at less than 10msec? However you might be willing to align the signals by artificially introducing latency into the x-ray signal as well. This would be a calibration procedure which I am not sure if the scanning manufacturers would be interested. Again this would not be so called true synchronization.
Thank you,
Kind regards
Tim
To answer to your previous statement. I'm content to see MDPnP group do whatever they want. However I would suggest to implement multiple solutions and compare the results to understand the true potential of technologies available at the prototype level. We should not be married to a single approach but be able to embrace alternative and improved technologies that should be considered and compared based on their functionalities, capabilities and implementation. Hence a true comparison on each technology should be reviewed before a final adoption of a particular technology has been decided. It's fine to embrace a single technology (such as DDS) for your particular use by the MDPnP group, but to endorse it for the entire community should necessitate a wider view. I think other communities such as the federal agencies should have been consulted.
To my knowledge most technology exists and enjoys widespread use before a standard is published. Standard is an end goal, not a starting point. Take for example Linux which has no standard's body behind it, nor does Java, C, C#, or x86. We should be more focussed on technologies that provide full availability of the technology details and ability to use, modify, and redistribute among the community.
I do not think it is possible to attain a goal of of 10ms between off the shelf commercially available ventilator and x-ray/CAT/MRI scanning machines. Because the ventilator itself as to my knowledge spits out a waveform with a latency of >100 msec+. May be you aware of any manufacturer that provides ventilator/s with waveforms at less than 10msec? However you might be willing to align the signals by artificially introducing latency into the x-ray signal as well. This would be a calibration procedure which I am not sure if the scanning manufacturers would be interested. Again this would not be so called true synchronization.
Thank you,
Kind regards
Tim
Hello Jeff,
Below are some of my suggestions for the OR requirements that I would like MDPnP to consider.
Compatibility of Medical Devices connectivity
Thanks
Tim
Below are some of my suggestions for the OR requirements that I would like MDPnP to consider.
Compatibility of Medical Devices connectivity
- Plug N Play Recognition
- On demand Hot swapping of medical devices
- Auto-Recognition/Auto discovery of medical devices in each OR suite. (able to display both connected and unconnected devices)
- Development of ubiquitous medical device driver interfaces.
- Pluggable device specific interface library enabling easy support for varying device protocols and data formats
- I/O communication over Wi-Fi, Bluetooth, USB, FTP, LAN, CANBUS and serial port based protocols
- Smart Alarms and messaging Alerts
- Unique/novel alarms and alerts for Patient monitoring in OR setting
- Versatile to allow clinician preferences
- Compatibility of devices
- Interlock equipment to ensure compatibility and reliability
- Smart maintenance
- Support for device enabled events (e.g. battery, supplies, etc.)
- Monitor device connectivity per OR suite
- Monitor overall system performance (network, congestion, latency etc.)
- View status remotely of all connected devices
- Rapid IU display of root cause of any issues
- Alert devices status (device connection, online/offline etc.)
- Automatic device detection, connection and data acquisition without user intervention.
- Notification when device is unplugged or moved away from the radio range and automatic re-connection when device enters the range
- Facilitate collection of desired data (numerical and waveform data)
- Filter clinical raw data per user requirements and specifications
- Close loop control system of medical devices
- Novel methods for displaying physiology data from devices and data from other sources
- Real-time remote display via other platforms (handheld devices)
- Automatic emergency paging system (Communication System)
- A Comprehensive, accurate, reliable database with relevant data for clinical research purposes (retrospective analytics)
- On demand real-time access to data (waveform/numerical) by remote multiple users
- To Synchronize, integrate, and process medical data from all sources
- Allow clinicians to index, search, and assemble data.
- Ensure it is flexible, modular, scalable and evolvable
- Time validation and synchronization with raw data
- Enabling unified feed, frequency selection, parameter & unit mapping, unit conversion and data manipulation
- Flexible clinical systems connectivity with system-specific data management interface library
- A method of communication between clinicians and care givers inside the OR and outside the OR vicinity
Thanks
Tim
Jeff,
Thank you informing all of us. The point I was trying to make specifically towards that Kafka, ZeroMQ and other technologies that have a lot of potential and are far easier to implement. It would be note worthy that we should be looked into these technologies that are completely open source, easier implementation on a large scale. I think it would be beneficial compare side by side technologies such as RTI-DDS, Kafka and ZeroMQ.
Thanks
Tim
Thank you informing all of us. The point I was trying to make specifically towards that Kafka, ZeroMQ and other technologies that have a lot of potential and are far easier to implement. It would be note worthy that we should be looked into these technologies that are completely open source, easier implementation on a large scale. I think it would be beneficial compare side by side technologies such as RTI-DDS, Kafka and ZeroMQ.
Thanks
Tim
Hello Jeff,
A lot of progress has been going on from the pub sub perspective as to which technology would be best suitable on a long term basis that is far less complex than DDS technology.
IHMO DDS is like CORBA. Too complex. A big company might embrace it, but they really don't have a reason to do so. With the existing protocols already well established, DDS doesn't bring "new" functionality to the table. DDS doesn't help the problem of connectivity -- it is too complex and configurable in incompatible ways. This is not the first technology product to be hampered by complexity. CORBA itself is a prime example. A little closer to home, 11073 suffers a similar problem. These things are still very useful, but they are not game changers.
One technology you might look at is ZeroMQ. It is one of a set of message brokers that includes better-known cousins such as ActiveMQ, RabbitMQ, Redis, even SOAP based systems.
ZeroMQ stands out in this crowd as modern, simple, and elegant. Not the universal solution for everything, but a good solution for some Pub-Sub type systems. Already well past critical mass, and continues to gain popularity. Here is an overview comparison:
http://www.bravenewgeek.com/dissecting-message-queues/
ZeroMQ is also data agnostic. It provides the infrastructure of message passing and subscriptions, but the data payload itself needs to be encoded separately. Protobuf is a good match for that, as well as Drager's SOA recommendations of binary encoding of XML messages using EXI.
Just my 2 cents.
A lot of progress has been going on from the pub sub perspective as to which technology would be best suitable on a long term basis that is far less complex than DDS technology.
IHMO DDS is like CORBA. Too complex. A big company might embrace it, but they really don't have a reason to do so. With the existing protocols already well established, DDS doesn't bring "new" functionality to the table. DDS doesn't help the problem of connectivity -- it is too complex and configurable in incompatible ways. This is not the first technology product to be hampered by complexity. CORBA itself is a prime example. A little closer to home, 11073 suffers a similar problem. These things are still very useful, but they are not game changers.
One technology you might look at is ZeroMQ. It is one of a set of message brokers that includes better-known cousins such as ActiveMQ, RabbitMQ, Redis, even SOAP based systems.
ZeroMQ stands out in this crowd as modern, simple, and elegant. Not the universal solution for everything, but a good solution for some Pub-Sub type systems. Already well past critical mass, and continues to gain popularity. Here is an overview comparison:
http://www.bravenewgeek.com/dissecting-message-queues/
ZeroMQ is also data agnostic. It provides the infrastructure of message passing and subscriptions, but the data payload itself needs to be encoded separately. Protobuf is a good match for that, as well as Drager's SOA recommendations of binary encoding of XML messages using EXI.
Just my 2 cents.
Customer support service by UserEcho
There should be a code somewhere written in Node.js that emits data from DDS to the openice.js.
Thanks
Tim