Invented by Prakash Kumar Arvind Jha, James Cudney, Benjamin Herr, Mark I. Lee, Matteo D. Picinich, ICU Medical Inc
Medical device communication methods refer to the ways in which medical devices communicate with each other and with other systems, such as electronic health records (EHRs) and patient monitoring systems. These communication methods are essential for ensuring that medical devices are able to share data and work together seamlessly, which is critical for providing high-quality patient care.
One of the key drivers of the market for medical device communication methods is the increasing adoption of telemedicine. Telemedicine allows healthcare providers to remotely monitor patients and provide care without the need for in-person visits. This has become especially important during the COVID-19 pandemic, as many patients have been unable or unwilling to visit healthcare facilities in person.
To support telemedicine and remote patient monitoring, medical devices need to be able to communicate with each other and with other systems in real-time. This requires robust communication methods that are secure, reliable, and interoperable.
Another driver of the market for medical device communication methods is the increasing use of EHRs. EHRs are electronic records of patient health information that are used by healthcare providers to manage patient care. Medical devices need to be able to communicate with EHRs in order to share data and ensure that patient records are accurate and up-to-date.
There are several different communication methods that are used in the medical device industry. These include wired and wireless communication protocols, such as Bluetooth, Wi-Fi, and Zigbee. Each of these protocols has its own strengths and weaknesses, and the choice of protocol will depend on the specific needs of the medical device and the healthcare provider.
In addition to communication protocols, there are also several standards and regulations that govern medical device communication. These include the Health Level Seven (HL7) standard, which is used for exchanging clinical and administrative data between healthcare systems, and the Medical Device Data System (MDDS) regulation, which governs the use of medical device data in EHRs.
Overall, the market for medical device communication methods is expected to continue to grow in the coming years. As telemedicine and remote patient monitoring become more widespread, the need for effective communication methods between medical devices will only become more important. Healthcare providers and medical device manufacturers will need to work together to ensure that these communication methods are secure, reliable, and interoperable, in order to provide the best possible patient care.
The ICU Medical Inc invention works as follows
A medical device communications method that can be implemented in a variety medical devices, including but not restricted to infusion pump. The method can be implemented using a protocol stack at least for intra-device communications. Embodiments provide connection-oriented, connectionless-oriented, broadcast and multicast data exchange with priority handling of data, fragmentation, and reassembly of data, unique static and dynamic address assignment and hot swap capability for connected peripherals or subsystems.
Background for Medical device communication method
Field of Invention
One or more embodiments relate to multiplex communication protocols used by medical devices, such as infusion pumps, but are not limited to this. More particularly, but not by way of limitation, embodiments of the invention enable a medical device communication method for communication between connected peripherals and subsystems that includes connection-oriented, connectionless-oriented, broadcast and multicast data exchange with priority handling of data, fragmentation and reassembly of data, unique static and dynamic address assignment and hot swap capabilities.
Description of Related Art
Devices which exchange data do so by using a protocol of communication.” Data can be sent and received using communication protocols in a controlled way. Medical devices, as an example, may use a communication protocol to exchange data with peripherals or systems that generate or use data. Communication protocols come in many different types, each with a unique complexity, hardware usage and efficiency. The current communication protocols used in medical devices rely on the operating system of the device and its bus architecture. This type of architecture can be problematic because some implementations prevent the time-multiplexed use of the communication link. This may starve or otherwise prevent multiple applications from communicating at once. Applications that use operating system-specific software calls to transfer data must also be modified when the operating systems or bus architecture change. This is to accommodate differences in the operating system calls, or the bus architecture. Medical devices must also undergo rigorous testing to ensure they are not defective. “Changing bus architectures can increase costs for applications that use the bus architecture because the source code must be retested.
Known communication protocols are usually targeted at a particular type of bus architecture. For example, Ethernet, WiFi Bluetooth, CAN Serial I2C SPI etc. Since they are designed to solve a particular communication problem, known communication protocols cannot be used with multiple types of communication buses. Medical devices that have embedded processors, which perform specific tasks or functions, like infusion pumps, are limited in their processor capability and memory. Existing sophisticated communication protocols cannot be used in these devices due to the limited power, processor capabilities, and memory.
In summary: known solutions are tied to specific operating systems and/or communication buses. Unfortunately, these communication protocols are not agnostic to all communication bus types and do not provide an efficient and lightweight protocol stack for intra-device communication that includes connection-oriented, connectionless-oriented, broadcast and multicast data exchange with priority handling of data, fragmentation, and reassembly of data, unique static and dynamic address assignment for connected subsystems and hot swap capabilities. “At least for the limitations described above, there is a requirement for a communication method of medical devices that provides these features described and claimed in this document.
Embodiments of the invention enable a medical device communication method for communication between medical peripherals and subsystems that includes connection-oriented, connectionless-oriented, broadcast and multicast data exchange with priority handling of data, fragmentation and reassembly of data, unique static and dynamic address assignment and hot swap capabilities. Infusion pumps are examples of medical devices which may use an embodiment of the invention. Embodiments provide a communication protocol interface that is detachable or abstracted away from the operating system, and the underlying bus architecture, within the medical device. This allows the communication protocol to behave and look the same across operating systems and bus architectures, something which was not possible in the past for infusion pumps. The same application can be used on different hardware platforms without changing the application. So, embodiments allow for simplified application code and portability, and reduce maintenance and test requirements. Embodiments can use any physical communication path including, but not limited, to a bus. Data bus drivers are used to control the reading and writing data on a bus.
Embodiments” may be implemented as separate layers of software that execute on a single or multiple computing elements. Each layer is responsible for performing operations that are generally independent from the other layers. For example, each layer may create, update or read headers that are associated with the data being exchanged. The headers will contain information supporting the features mentioned above. These layers are known as a “protocol stack”. “Protocol stack embodiments may include a session layer, data link layer, manager layer and transport layer.
Applications can choose to transmit data via connection-oriented data transfer for data that is more sensitive or by connectionless data transfer. Embodiments support data exchange modes such as broadcast, multicast and one-to one, including one-to many and many-to one. One embodiment supports data exchange based on priority and prioritizes high priority data above low priority data in order to deliver high priority messages first. At least one embodiment also supports data fragmentation to meet the demands of a particular physical communication technology. Embodiments provide dynamic and static address assignments for subsystems connected and hot swap capability, which is unknown in infusion pumps today.
Specifically, for connection-oriented communications, at least one embodiment uses a Communication ID, or “CID”, as a token in order to uniquely identify and route data between applications. In connectionless communication, one embodiment utilizes port numbers (for example, source and destination ports) to identify the targeted applications. A least one embodiment provides subscription services to recipient applications. This allows data to be broadcasted across all applications that are subscribed. Multicasting is possible both with and without a connection. In connection-oriented sessions, at the very least, one embodiment ensures delivery of data. For example, acknowledgements. Connectionless communication sessions are also very efficient, but do not guarantee data delivery. “At least one embodiment supports the broadcasting of messages and data, in which the broadcast messages are sent to all subsystems that are connected to the broadcasting system.
Applications may require to exchange data of a larger size than a communication technology or underlying data bus is capable of supporting. In these cases, one embodiment fragments or breaks the data to a smaller size that can be transferred by the data bus. At least one embodiment reconstructs the data at the receiving end to its original size. At least one embodiment is executed on embedded systems with limited resources such as memory, processing power and bus utilization. As a result, embodiments make efficient use of available resources. Examples of data exchanges large enough to warrant message fragmentation include firmware updates and drug library downloads.
In relation to fragmentation at least one embodiment uses window which represents a number of fragments sent before the receiver acknowledgement. In one embodiment, before sending the initial fragment, the transmitter asks the receiver for the window size. The receiver determines how much memory is available to store received packets, and then responds with a window size. This can be expressed as an integral multiple or the maximum frame size which fits in the memory. The fragments are numbered in order and sent to the receiver by the transmitter. The transmitter will wait for the acknowledgement of the final fragment after sending a window’s worth of messages. The receiver verifies the sequence of all fragments received by adding up all fragments received. The receiver acknowledges that there are no missing fragments by sending the fragment number for the last fragment or, if necessary, sends fragment numbers of the missing fragments in the form of negative acknowledgment (NAK).
Since future medical devices, such as infusion pump, may include hot swappable subsystems or peripherals, at lease one embodiment supports unique addresses to connected devices to ensure conflict-free exchange of data and reduce complexity in applications. At least one embodiment allows communication using multiple data transfer technologies, such as serial, USB, SDIO or SDIO over CAN. “At least one embodiment keeps track of the devices connected to each bus, and routes data on that bus.
A medical device communication technique will be described. The following exemplary description includes numerous specific details to help you better understand embodiments of the present invention. An artisan with ordinary skill will understand that the invention can be implemented without all of the details described. Other times, certain features, measurements, or quantities that are well-known to those with ordinary skill have not been described so as to not obscure the invention. The reader should be aware that, although the examples are given here, it is the claims and their full scope, as well as any equivalents which define the boundaries of the invention.
FIG. The FIG. 1 shows an architectural view for a system that includes a user interface controller (UIC) and multiple peripherals which communicate using an embodiment. The user interface controller UIC is shown communicating with peripherals Pump Motor Control (or ‘PMC? ), PMC 1 and 2 as well Communication Engine or ‘CE? Message handling for drug library, diagnostic messages and status is just one example. UIC, as an example, has a device ID and a destination ID. Messages from UIC are sent to other devices over tuples that have been defined in the table. The table above UIC shows these channels, which are between UIC with PMC 1 at ports 10-20, the status and therapeutic ports, using Communication ID. 100 and CID 250, respectively, followed by a communication channel used between UIC 2 and PMC 2 port 10, which is the therapeutic port. In the table, the CE’s address is 7. The table shows that the CE has channels to PMC 2, the UIC and devices 2 and 5, via Communication IDs 250 and 175. PMC 1 has channels to the UIC via Communication IDs 100 and 250. PMC 2 has channels to UIC and CE via ports 10 and 20 and Communication IDs 100 and 250. PMC 3 or 4 can be quickly swapped in the system, or commanded on-the-fly. The embodiments of the invention generally use minimal memory and processing in order to allow execution on devices with limited memory or processing power. This is not known to the general public when it comes to complex communications protocols. In some embodiments, one kernel thread is used to execute Data Link and Transport layers, while the remaining layers are part and parcel of the application and run in context with the application. The minimum thread implementation allows blocking access. For example, read and write operations are blocked until the operation has been completed. In some embodiments, callbacks may be asynchronous. The stack can then use two threads: one thread for read operations and another for write operations.
FIG. The figure 2 shows a hierarchical layering embodiment of the invention as a protocol stack. In the application layer, data messages are N bytes in length. As shown, the application layer can include functionality that is independent of the protocol layer. As the message descends the layers, control information, or headers, are added to the message. This is done when the message is sent from one application, such as to another application running on a subsystem or peripheral. As the message ascends the protocol stack, the various headers and other appended data are removed.
In one or more embodiments a manager layer can be used to implement the first protocol layer beneath the application. The manager layer can provide standard interfaces for applications on any operating system. This layer offers application programmers interfaces (API’s) that enable socket-based communication between applications. The manager layer manages file descriptions and facilitates the opening of ports. The manager layer, in at least one embodiment creates and uses a message header with a file descriptor and port number.
A session layer is a layer of the protocol stack that provides or includes APIs for data exchange and control between the manager layer and session layers. The session layer may provide guaranteed application-to-application delivery of data and enables connection-oriented and connectionless-oriented modes of communication. This layer also allows for one-to one, one-to many, and many-to one multicasting, broadcasting, and broadcasting modes of communication. The layer maintains a translation between CIDs and sockets or virtual ports. The protocol uses CIDs for connection-oriented communications and generates them and uses them in other ways. The connection-oriented data transfer uses a handshake to exchange data between applications. As such, the session layer manages the handshake. It generates a unique CID and notifies the other session layers that are participating about it. Data packets use the CID to communicate after the handshake. In the case of connectionless communications, no CID will be used and therefore both destination and source port addresses will be exchanged within each communication payload or packet. In one embodiment, a message header with control flags, a message type and a communication ID is created and used by the manager layer. FIG. 10A shows this structure, along with an example connection table. This structure, together with an exemplary connection table is shown in FIG. 10B-D. Control flags can be implemented, for example, with a layer bit of 1, a connection bit of 2, and a CID bit of 1. In one or more embodiments, the session layer uses some messages associated with session-session communication and they are not passed up the stack until the manager layer. These messages are used to establish or close connections, acknowledgements etc. The message will be consumed by the session layer if the layer flag has been set. For example, set to True or 1. The connection type flag is used to indicate the type of connection. For example, if it’s connectionless or connectionless-oriented, then set 00. User Datagram Protocol (UDP) is an example of a connectionless protocol, while Transmission Control Protocol (TCP) is an example of a connection-oriented protocol. The CID source bit identifies if data is being sent by the entity who generated the CID or sub-modules that use this CID to communicate. This bit is set by the entity that creates CID to communicate. Other entities using the CID reset the flag. The CID generated by the entity that generates CID may have duplicates in other entities. This layer can help resolve the source of CID via this flag. The message type field is used to associate messages with categories, and tells the session layer what fields are expected. In one or more embodiments, the message type field has a width of 4 bits. The message type field determines the type of message. Examples of values are 0000 for data; 0001 for connection; 0010 CID; 0011 sockets, 0100 service information and 0101 device information. A module that offers a service will generate a unique CID to communicate with consumers. Communication ID 0? Communication ID?0? The Communication ID field measures 1 byte and is used to identify the data sent up the protocol stack. CID can contain any number from 0-255. CID 0 is a valid ID for connectionless communication. CID?0? is used for connectionless communication. It is not valid for connection-oriented communications. CIDs for connection-oriented communications are in the range 1-255. CID = 0 indicates connectionless communication. Any other number in the range of 1-255 indicates connection-oriented communication. Applications can set up one or more notification filter to choose which messages to receive and how to process them. The filtration method may use one or more regular-expressions that specify the location, the length and the content of the matching data within the data portion. In one embodiment, this functionality is implemented at the management layer. The management layer may first check to see if there are any filters defined before forwarding the data. The manager layer filters the data based on the filter and sends it to the callback handlers.
Embodiments” of the invention allow a single application maintain connections with multiple devices over one or several physical communication layers, or bus implementations. Virtual ports are used to achieve this. As an example, a single application like the Therapeutic Manager of the UIC can maintain open connections to more than one PMC drug pump or other device. This would be the case during a multichannel infusion. Many applications can maintain a connection to one device or application. For example, UIC and CE applications, as well as other applications, may connect to PMCs to obtain infusion status data.
The many-to one and/or one-to-many communication relationship can be further classified into three types: unicasting, multicasting and broadcasting. For example, applications can request infusion status via multicasting or a PMC can broadcast the status to interested applications. Listening to known ports can be anonymous or subscription-based. In anonymous mode, the broadcasting application transmits continuously on a port known to all applications. In subscription-based mode, broadcasting applications will not transmit until at least one interested application has requested service.
Virtual ports can be implemented by enabling a handshake between participating modules/applications. Applications that provide the service open the port and connect with the port. The service provider generates a CID for each accepted connection request and sends it back to the requesting entity as an acknowledgement. This CID is used for subsequent communication. The CID will be unique to the entity who generated it. The CID will be returned to the pool to reuse later, or to send a disconnection message to stop the communication. In the event that the service provider is out of CIDs it can return a NAK with an appropriate NAK ID to connection requests. After waiting for enough retries before sending a message in the event of a communication failure (for example, module shutdown, too much time waiting, too many retries etc.), one or more embodiments can assume that communication has ended and CIDs are returned to pool. The CIDs are generated by the provider of the service and are unique to the entity. Therefore, duplicate CIDs can exist on sub-entities. Two CID tables can be used to avoid conflict due to duplicate CIDs. One table will contain the CIDs that are generated by the system and the second one will include the CIDs from other systems involved in communication. The CID creator sets the “CID Source” flag. When other applications involved look at the flag, they will perform a lookup into appropriate CID tables. Each entity can maintain a shared table for the applications that run on it. This table is maintained in the session layer, and it serves as a table of reference for routing data packets from ports/sockets to their respective ports/sockets.
Click here to view the patent on Google Patents.
Leave a Reply