The purpose of the Feed is to listen to apparatus waiting for incoming data and then transfer it to a artefact data server. It consist three different modules:

• A deamon running main module which can be configured to receive data from one or more apparatus through a driver, obtain patient information through pidio and transfer the information to an artefact server.
• A driver module implementing apparatus specific communication flow and control.
• A library offering shared functionality between the drivers.

The software are supposed to be light weighted, flexible and easy configurable so that for example a thin client easily can be configured to communicate with one or more specific apparatus. Furthermore all the running clients should be easily monitored from a central point, so that failure on a client running Feed can be handled from a central point.

Besides what is described above writing Feed also includes discovering and documenting the protocol of communication of the various apparatus.

• Document Devices (Protocol, discoveries etc.)
• use the new debug functionality

• Write test cases
• Support write access

• Error reporting (cleanup and test)
• Simple validation
  • Detect when comm. terminates unexpected
• Write test cases
• Centralize parsing of device-specific configuration
• Keep status after returning from run()

• Visutron 900+

• Run as a deamon
• Write test cases

Make a thread for transmitting data and a thread for gathering data. Share the data between the threads through a FIFO queue. By separating the transmitter and data gatherer we obtain that the data gatherer can be available for the device continually (which is good for instance when dealing with heavy timing dependant devices).

• Only median values when there exist more than one measurement
• Handle when IOP-data has >2 decimals