System and method for providing a common medical device architecture

• US 9,898,584 B2
• Filed: 03/15/2013
• Issued: 02/20/2018
• Est. Priority Date: 03/15/2013
• Status: Active Grant

• Current Assignee: Johnson & Johnson Surgical Vision, Inc. (Johnson & Johnson)
• Original Assignee: Abbott Medical Optics Incorporated (Johnson & Johnson)
• Inventors: Duff, Richard G
• Primary Examiner(s): Park, Ilwoo
• Application Number:
  US13/841,270
• Publication Number:
  US 20140278473A1
• Time in Patent Office: 1,803 Days
• Field of Search: None
• CPC Class Codes: G16H 40/40 for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
• CPC Class Codes: G16H 40/63 for local operation
• CPC Class Codes: G16H 40/67 for remote operation

Abstract

Systems, methods, and computer readable storage medium for providing a genericized medical device architecture common to a plurality of medical devices are disclosed. The architecture may comprise at least one diagnostics module associated with at least one of the plurality of medical devices, wherein the at least one diagnostics module is configured to monitor an operational status of the at least one medical device. At least one hardware abstraction layer may be associated with at least one of the plurality of medical devices, and may be configured to provide abstracted access to hardware of the at least one medical device.

Claims

1. A non-transitory computer readable storage medium having encoded thereon computer executable instructions which, when executed, cause a computer to implement a software architecture common to a plurality of medical devices, the software architecture comprising:

a plurality of modules each configured to control and monitor aspects of hardware or software related to the plurality of medical devices;

a location independent communications module configured to provide message bus services for ones of the plurality of modules and hide the physical locations of a plurality of communication endpoints, wherein the ones of the plurality of modules are communicatively associated with each of the plurality of medical devices; and

a hardware abstraction layer associated with the at least one medical device that is configured to allow hardware independent control of hardware functionality of the at least one medical device, wherein the hardware functionality of the at least one medical device is dependent on physical characteristics of the at least one medical device.

2. The medium of claim 1, wherein one of the plurality of modules is configured to provide at least one application programming interface (API).

3. The medium of claim 1, wherein one of the plurality of modules comprises a diagnostics module associated with the software of at least one of the plurality of medical devices, wherein the diagnostics module is configured to monitor an operational status of the hardware of the at least one medical device.

4. The medium of claim 3, wherein the diagnostics module provides at least one application programming interface (API) to allow for the monitoring of the operational status of the at least one medical device.

5. The medium of claim 1, wherein the hardware abstraction layer provides at least one application programming interface (API) to allow control of the hardware functionality of the at least one medical device.

6. The medium of claim 1, wherein one of the plurality of modules comprises a datastore associated with the at least one medical device, wherein the datastore is configured to provide persistent and non-persistent data storage on the at least one medical device.

7. The medium of claim 1, wherein one of the plurality of modules comprises a graphical user interface (GUI) module capable of communicating using the location independent communications module, and that is configured to allow implementation of graphical views associated with the software of the at least one medical device to a user of the at least one medical device.

8. The medium of claim 7, wherein the GUI module is further configured to provide at least one application programming interface (API) to manage and transition between the graphical views.

9. The medium of claim 1, wherein one of the plurality of modules comprises a low level services library configured to allow implementation of low level services associated with the hardware.

10. The medium of claim 9, wherein the low level services library provides at least one application programming interface (API) to allow for use of the functionality of the at least one medical device.

11. The medium of claim 1, wherein one of the plurality of modules comprises a workflow module configured to allow implementation of a workflow across components of the software architecture.

12. The medium of claim 11, wherein the workflow module provides an application programming interface to support a state machine.

13. The medium of claim 1, further comprising message bus services associated with one or more of the plurality of medical devices, wherein the message bus services comprise data normalization.

14. The medium of claim 13, wherein the data normalization comprises normalization across GUIs.

15. The medium of claim 1, further comprising:

one or more low level service subsystems configured to provide single core functionality to one or more of the plurality of medical devices.

16. The medium of claim 1, wherein the location independent communications module is further configured to:

receive a plurality of messages from the plurality of medical devices,

determine a priority and a type for each of the plurality of messages received,

group the plurality of messages based upon the type to form one or more groupings, and

route the plurality of messages based upon the priority and the one or more groupings.

17. The medium of claim 1, wherein the hardware functionality of the at least one medical device includes beam steering, targeting, or phaco pump functionality.

18. A method of implementing a software architecture common to a plurality of medical devices, comprising:

accessing information from at least one module included in a plurality of modules, wherein each of the plurality of modules is configured to control and monitor aspects of hardware or software related to the plurality of medical devices;

communicatively associating, by a location independent communications module, one or more of the plurality of modules to each of the plurality of medical devices, and hiding physical locations of a plurality of communication endpoints; and

controlling, by a hardware abstract layer, hardware functionality of the at least one medical device, wherein the hardware abstraction layer provides hardware independent control and the hardware functionality of the at least one medical device is dependent on physical characteristics of the at least one medical device.

19. The method of claim 18, further comprising:

providing at least one application programming interface (API) to allow for the providing of a message bus services.

20. The method of claim 18, further comprising:

providing at least one application programming interface (API) to allow for monitoring of an operational status of at least one of the plurality of medical devices.

21. The method of claim 18, further comprising:

providing an application programming interface (API) for managing persistent and non-persistent data associated with at least one medical device.

22. The method of claim 18, further comprising:

implementing graphical views associated with the plurality of medical devices to a user of one of the medical devices using a Graphical User Interface (GUI).

23. The method of claim 22, further comprising, providing application programming interfaces to manage and transition between the graphical views.

24. The method of claim 18, further comprising providing a low level services library configured to allow implementation of low level ones of the hardware.

25. The method of claim 18, further comprising:

implementing a workflow module across one or more of the plurality of medical devices.

26. The method of claim 25, wherein the workflow module provides an application programming interface to support a state machine.

27. The method of claim 18, further comprising:

normalizing data across ones of the plurality of medical devices.

28. The method of claim 27, wherein the data normalization comprises normalization across GUIs.

29. The method of claim 27 further comprising:

receiving, by the location independent communications module, a plurality of messages from the plurality of medical devices,

determining, by the location independent communications module, a priority and a type for each of the plurality of messages received,

grouping, by the location independent communications module, the plurality of messages based upon the type to form one or more groupings, and

routing, by the location independent communications module, the plurality of messages based upon the priority and the one or more groupings.

30. The method of claim 27, wherein the hardware functionality of the at least one medical device includes beam steering, targeting, or phaco pump functionality.

31. The method of claim 18, further comprising:

providing one or more low level service subsystems configured to perform single core functionality to one or more of the plurality of medical devices.