MEDICAL DEVICE LOCATION AUTHORIZATION

Certain examples provide systems, methods, and apparatus for medical device management. An example method includes determining a role mapping for a user and determining a location mapping for the user. The example method includes generating a combined location and role mapping for the user based on the role mapping and the location mapping. The example method includes configuring user access to one or more medical devices based on the combined location and role mapping. The example method includes facilitating interaction with the one or more medical devices according to the configured user access.

FIELD

The present disclosure relates generally to medical devices. More specifically, the present disclosure relates to methods, systems, and apparatus to provide location authorization and access control for medical devices.

BACKGROUND

Increasingly, medical devices are becoming electronic or involve an electronic or software component. Electronic devices, distributed facilities, and scattered patients make training, treatment, and troubleshooting difficult. Further, it is often difficult to educate the public, and patients may not seek the treatment they should due to a lack of information and access. Operators and administrators may also introduce inefficiencies in their operation and management of medical devices due to a lack of information and access. Additionally, unauthorized access has potential to introduce harmful error as well as inefficiency into patient treatment.

DESCRIPTION OF CERTAIN EXAMPLES

Certain examples are shown in the above-identified figures and described in detail below. In describing these examples, like or identical reference numbers are used to identify the same or similar elements. The figures are not necessarily to scale and certain features and certain views of the figures may be shown exaggerated in scale or in schematic for clarity and/or conciseness. Additionally, several examples have been described throughout this specification. Any features from any example may be included with, a replacement for, or otherwise combined with other features from other examples.

Although the following discloses example methods, apparatus, systems, and articles of manufacture including, among other components, firmware and/or software executed on hardware, it should be noted that such methods, apparatus, systems and articles of manufacture are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these firmware, hardware, and/or software components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware, or in any combination of hardware, software, and/or firmware. Accordingly, while the following describes example methods, apparatus, systems, and/or articles of manufacture, the examples provided are not the only way(s) to implement such methods, apparatus, systems, and/or articles of manufacture.

When any of the appended claims are read to cover a purely software and/or firmware implementation, at least one of the elements is hereby expressly defined to include a tangible medium such as a memory, a digital video disc (DVD), compact disc (CD), BLU-RAY™, etc. storing the software and/or firmware.

Certain examples facilitate management of medical devices including blood collection or apheresis devices, infusion pumps, drug delivery pumps, and/or other medical devices. For example, an infusion pump infuses fluids, medication, or nutrients into a patient. An infusion pump can be used intravenously, subcutaneously, arterially, and/or epidurally, for example. For example, an infusion pump can administer injections at a variety of rates (e.g., injections too small for an intravenous (IV) drip (e.g., 0.1 mL per hour), injections per minute, injections with repeated boluses, patient-controlled injections up to maximum number per hour, or injections of fluids whose volumes vary by time of day, etc.).

In certain examples, an operator (e.g., a technician, nurse, etc.) provides input regarding type of infusion, mode, and/or other device parameter. For example, continuous infusion provides small pulses of infusion (e.g., between 500 nanoliters and 10 milliliters), with a pulse rate based on a programmed infusion speed. Intermittent infusion alternates between a high infusion rate and a low infusion rate with timing programmable to keep a cannula open, for example. Patient-controlled infusion provides on-demand infusion with a preprogrammed ceiling to avoid patient intoxication. The infusion rate is controlled by a pressure pad or button that can be activated by the patient, for example. Infusion pumps can include large volume pumps (e.g., for nutrient solution delivery to feed a patient), small-volume pumps (e.g., for medicine delivery), etc.

In certain examples, an operator or administrator may configure a medical device, such as an infusion pump, apheresis device, etc., and/or set one or more parameters for interaction between the device and a domain controller and/or a provider data management system. Certain examples provide flexibility in facilitating operator and/or administrator (e.g., user) operation and configuration of a medical device while maintaining device reliability and secure through new authorization protocols and systems.

Certain examples provide location authorization preventing a user from accessing data and performing actions in locations other than location(s) at which the user has been authorized to act. By adding location authorization to a medical device authorization protocol, a medical device data management system (such as the Fenwal DXT™ data management system manufactured by Fenwal™, a Fresenius Kabi company) provides application level end-to-end security control to protect location data, application function, patient safety, etc. User permission is assigned depending on not only a functional role of the user but also a location assignment for the user as maintained by the data management system. Thus, data management systems can interact with medical devices (e.g., Fenwal Amicus™, Alyx™, Autopheresis-™ and Aurora™ Apheresis systems, other apheresis devices, Fresenius Kabi Agilia® pump, Optima™ pump, Pilot™ pump, other drug delivery pump, etc.) for flexible, remote configuration and operation while helping to ensure data and configuration safety and security, for example.

In certain examples, a role-based authorization mechanism defines a user type, function, or role (e.g., system engineer, technician, nurse, physician, administrator, etc.) as well as a location (e.g., a particular healthcare facility, healthcare organization, city, employer, etc.) and user (e.g., a user account or profile that associates the user with a defined role, etc.). Thus, if a user has an account and the account identifies him or her as a member of the system engineering group, then that user can access to all resources that system engineers have (pending location limitations, etc.).

Using a location authorization schema, a logical structure of a healthcare organization (e.g., a hospital deployment structure with individual pumps, etc.) is incorporated into a user authorization system so that a user is assigned a specific role (e.g., a pharmacist in hospital A in Highmountain Healthcare, a pharmacist in a particular ward, etc.) and also restricted to a specific location (e.g., all pharmacist group access but only in Hospital A, not at Hospital B or C). Thus, the location and role-based user authorization provides a greater granularity to restrict people at a location even though the users have certain privileges from their assigned roles.

FIG. 1illustrates an example hospital deployment location structure100including a health organization102including a plurality of hospitals104,106,108under its umbrella. Each hospital A104, B106, and C108includes one or more pumps and/or other medical devices110,112,114with electronic configuration and operation ability.

The deployment location structure100provides information about the logical structure of the organization102in which a data management system (e.g., Fenwal DXT™, etc.) is installed. In certain examples, deployment locations can be categorized into the following types: Organization, Hospital, Ward, etc. In such examples, the organization location represents the overall healthcare organization102in which the data management system is being deployed.

The hospital location represents a single hospital104,106,108that belongs to the Organization102. In certain examples, the ward location represents a single ward location that belongs to a hospital location.

FIG. 2illustrates an example ward deployment200. The example ward deployment200ofFIG. 2includes a health organization202including a plurality of hospitals204,206,208under its umbrella. Each hospital A204, B206, and C208includes a plurality of wards210-222, and each ward210-222includes one or more pumps and/or other medical devices224-236with electronic configuration and operation ability. As shown in the example ofFIG. 2, health organization202includes Hospital A204, Hospital B206, and Hospital C208. Hospital A204includes Ward AA210, Ward AB212, and Ward AC214. Hospital B206includes Ward BA216and Ward BB218. Hospital C208includes Ward CA220and Ward CB222. As shown in the example ofFIG. 2, each Ward210-222has a plurality of networked pumps224-236for operator configuration and operation.

FIG. 3illustrates an example mapping300of user role and permitted functionality for a medical device pump example. As shown in the example ofFIG. 3, user roles include administrator, biomedical engineer, pharmacist, pharmacy technician, business analyst, nurse, etc. The example ofFIG. 3also lists functionality relating to the pump device, such as monitor pump status, abort data set distribution, data set distribution report, create data set distribution policy, data set upload, infusion data reporting, etc. For each use role, the mapping300provides which functionality is available to a user in the particular role. Thus, as shown in the example ofFIG. 3, an administrator is able to monitor pump status, abort data set distribution, view/generate a data set distribution report, create a data set distribution policy, upload a data set, view/generate an infusion data report, etc. A biomedical engineer, however, cannot upload a data set but can access the remaining functionality, while the pharmacist and business analyst are allowed access to all pump and reporting functionality in the example mapping300. A pharmacy technician, however, is only allowed to monitor pump status, view/generate a data set distribution report, and view/generate an infusion data report, not abort data set distribution, create data set distribution policy, or upload a data set. According to the example mapping300, a nurse may only view/generate an infusion data report.

Certain examples provide an authorization model for human users that uses Role and Location Mapping mechanisms to assign permissions to users depending on their functional role and location assignment in the system, regardless if the user accesses the data management system directly from a user interface and/or through an external system (e.g., Vigilant DrugLib, etc.). For example, when both role and location mapping have been configured, a user who wants to schedule a Dataset distribution in Hospital ABC must be authorized to be a Pharmacist who belongs to Hospital ABC location.

Certain examples provide an architecture to facilitate interaction between the data management system and a domain controller. The domain controller defines groups and users, and the data management system maps groups and users to roles and specifies locations using the domain controller information. The architecture provides and/or uses a mapping to cross-reference locations from the data management system to an active directory of the domain controller. Employees/users are assigned to certain location to prevent users from improperly accessing information and/or functionality at other locations. Assignment of a user/group for location is similar to assigning a role to a user and/or group of users as described above.

Thus, mapping dictates user interaction with a medical device (e.g., a pump, apheresis device, etc.) at a given location. For example, if a user has pharmacist privileges at one location, he or she can only distribute a drug library to the pumps at that location for which he or she has authorization.

FIG. 4illustrates an example role mapping architecture or system400to configure, store, and implement a mapping of roles to user(s) and/or group(s) of users. The role mapping architecture400enables an Administrator and/or automated system to configure mapping of roles provided by a data management system402(e.g., Pharmacist, Biomedical Engineer, Administrator, etc.) to groups of users defined within a domain controller404(e.g., Active Directory) of a deployment information technology (IT) infrastructure.

As shown in the example ofFIG. 4, the data management system402defines a plurality of roles such as administrator406, pharmacist408, and biomedical engineer410. Each role406,408,410is associated with one or more device functions, such as configure instrument412, configure system414, upload dataset416, schedule distribution418, monitor distribution420, etc. For example, the administrator406can configure the instrument412and configure the system414. The pharmacist408can upload a dataset416, schedule distribution418, and monitor distribution420, for example. The biomedical engineer410can schedule distribution418and monitor distribution420, for example.

The domain controller404defines a plurality of user groups such as an administrator user groups such as administrator group (e.g., DXTADMIN)422, pharmacist group (e.g., DXTPHRM)424, and biomedical group (DXTBMED)426. One or more users are associated with each group422,424,426. For example, in the example ofFIG. 4, user001and user002are part of the administrator group422. User003and user004are part of the pharmacist group424. User004and user005are part of the biomedical group426.

As illustrated in the example system400the role406,408,410(e.g. Administrator, Pharmacist, Biomedical Engineer, etc.) and its corresponding function permissions412-420are predefined by a permission roles mapping428. For example, when the mapping428between domain controller DXTPHRM user group424and Pharmacist role408has been configured, any user who belongs to DXTPHRM group424is able to use all functions (e.g., upload dataset416, schedule dataset distribution418, monitor dataset distribution420, etc.) permitted to Pharmacist role408by the data management system402.

FIG. 5illustrates an example location mapping architecture or system500to configure, store, and implement a mapping of locations to user(s) and/or group(s) of users. The location mapping architecture500enables an Administrator and/or automated system to configure mapping of locations defined within the data management system402(e.g. Lake Bluff site, Memphis site, Knoxville site, etc.) to the defined groups of users within the domain controller404(e.g. Active Directory) of the deployment IT infrastructure (e.g., Lake Bluff Employees, location 2 employees, location 3 employees, etc.).

For example, the data management system402defines and/or stores information for a plurality of facility506locations. In the example ofFIG. 5, locations are broken up by region, such as a North region508and a South region510. Within each region508,510individual cities and/or other sub-regions can be identified. For example, the North region508for organization OrgA506may include a Lake Bluff location512. The South region510in the example ofFIG. 5may include Memphis514and Knoxville516locations.

As shown in the example ofFIG. 5, the domain controller404also defines and/or stores information for a plurality of user groups518,520,522by location. For example, user groups may include a Lake Bluff employees group518, a location2users group (e.g., DXTLOC2)520, a location3users group (e.g., DXTLOC3)522, etc. As shown in the example ofFIG. 5, user001and user002may belong to the Lake Bluff employees group518; user003and user004belong to location2user group520; and user004and user005belong to the location3user group522. A location mapping524stores the relationship between user group518,520,522and location506,508,510,512,514,517. The mapping524can tie a group (e.g., Lake Bluff employees518) to a single location (e.g., Lake Bluff), to a region (e.g., DXTLOC2520to South510), and/or to an entire network (e.g., DXTLOC3522to OrgA506), for example.

The locations506-516and their mapping524to domain controller groups518-522is defined during system configuration and, in some examples, can be updated dynamically based on changes in employment, location, rule, etc. For example, when a mapping between domain controller DXTLOC2 group520and DXT South location510has been configured, any user who belongs to DXTLOC2 group520can access all information for the South location510.

FIG. 6illustrates an example role and location mapping schema600to configure and govern user access to medical device systems at various locations. As shown in the example ofFIG. 6, the role mapping428from the example ofFIG. 4and the location mapping524from the example ofFIG. 5are combined with employee information602from a selected group (e.g., Lake Bluff employees518from the example ofFIG. 5) to form a role and location mapping604. For example, the role mapping428provides an association between user groups and roles, as well as function(s) accessible to the roles. The location mapping524provides a correlation between user groups and locations. Thus, a given user has both a role and a location, and a combined role and location mapping604can be formed by correlating roles and locations according to an employee group list602. Using the combined role and location mapping604, the Administrator406, Pharmacist408, and Biomedical Engineer410can access all information and use all functions412-420(e.g., schedule Dataset distribution, monitor Dataset distribution, upload Dataset, configure system, configure instrument, etc.) permitted to their respective role for the Lake Bluff location512only.

FIG. 7illustrates a flow diagram700for location and role-based authorization of action at a medical device. At block702, a location and role mapping is determined. For example, as described above with respect toFIG. 4, available role(s) and associated capability(-ies) are identified and mapped to one or more users and/or user groups via the data management system402and domain controller404. The role mapping428provides guidance to the data management system402to govern access to medical devices in communication with and/or controlled by the data management system402. Additionally, as described above with respect toFIG. 5, the location mapping524is generated by evaluating available locations (e.g., network, region, city, etc.) and associating users and/or user groups with the available locations. The role mapping428and location mapping524are combined with employee/user information602to form the role and location mapping604for particular users having particular roles at particular locations.

At block704, a particular user is identified. For example, a particular user logs in and is identified as a pharmacist in the pharmacy group424associated with the pharmacy role408and in the Lake Bluff employees518group authorized at the Lake Bluff location512.

At block706, the data management system402and domain controller404configure access for that user based on the mapping604associated with the user. For example, based on the determination of which location(s) and which function(s) the user is permitted to access based on his or her role, the data management system402and/or the domain controller404configure functionality available to the user when he or she logs in and/or otherwise accesses a medical device, user interface, workstation, etc., at a particular location.

At block708, the data management system402facilitates interaction with one or more connected medical devices (e.g., infusion pump, apheresis device, etc.) based on the configured access. For example, the data management system402can provide the access configuration to a particular device for the specific user. The user can then interact with the medical device (e.g., the pump, the apheresis device, the workstation, etc.) according to allowed configuration for that user.

FIG. 8depicts a data flow diagram800for system configuration of role and location mapping. The data flow diagram800provides further detail for certain examples of block702of the example process700described above. At block802, configuration begins. At block804, a role is selected. For example, a role805(e.g., Administrator, Nurse, Biomedical Engineer, Pharmacist, Pharmacy Technician, Business Analyst, etc.) is selected from a plurality of options and/or specified to the domain controller404and/or data management system402. Block804can be repeated for a plurality of roles.

At block806a user group is configured for the role805. For example,FIG. 9Aillustrates an example user interface900to configure a user group name (e.g., DXTBMED) for a biomedical engineer role805, andFIG. 9Billustrates an example user interface950to configure a user group name (e.g., DXTPHRM) for a pharmacist role805. An example interface such as interface970ofFIG. 9Cdisplays the configured user group name(s)807for the role(s)805. The group807information is used to form a role mapping428.

At block810, a hospital and/or other health location is selected. For example, a hospital811is selected from a plurality of options and/or specified to the domain controller404and/or data management system402. Block810can be repeated for a plurality of hospitals. At block812, a user group name is configured for the hospital811(e.g., Geri Hospital A1). Block812can be repeated for additional hospital(s) (e.g., Geri Hospital B1, etc.). For example,FIG. 10Aillustrates an example user interface1000to configure a user group name (e.g., Geri_Hospital A1) for a first hospital location, andFIG. 10Billustrates an example user interface1050to configure a user group name (e.g., Geri_Hospital B1) for a second hospital location. An example interface such as interface1070ofFIG. 10Cdisplays the configured user group name(s)813for the hospital(s)811. The group813information is used to form a location mapping524. The location mapping524can be combined with the role mapping428to form a location and role mapping for one or more users, for example.

FIG. 11depicts a data flow diagram1100for location authorization of a user with respect to a medical device at a location. The data flow diagram1100provides further detail for certain examples of block706of the example process700described above. At block1102, monitoring begins. A user name1103is provided. For example, the user name1103can be input, retrieved from a database, scanned from a barcode, radio frequency identifier (RFID), determined from a photograph, etc. At block1104, the user group name is read for monitoring. For example, based on the user name1103and a user group name807retrieved from the role mapping with user group permissions428, a user group name is provided and combined with the user name1105for verification.

At block1106, the user name is evaluated with respect to the identified user group to verify whether the user name is in the user group. For example, the user name1103is combined to a list associated with the user group807to determine whether or not the user is in the specified group. If the user name is not found in the user group, then, at block1108, the user is labeled as an unauthorized user. If the user is labeled as an unauthorized user, the user may be blocked from accessing the system, may be flagged or reported, may be warned, may be prompted to enter different and/or additional information, etc.

However, if the user name1103is verified as a member of the user group807, then a location of desired user access1107is provided and, at block1110, the user group name807is read for the accessed location1107. The user group name807and location1107are combined with user group name(s) for location813provided by the location mapping524. Then, at block1112, the user name and group name(s)1111for the location1107are verified to determine whether the user name is in the user group for the location.

If the user name is not found in the user group, then, at block1114, a device interface is launched without including medical device(s) (e.g., pump(s), apheresis device(s), etc.) in the location1107. However, if the user name is authenticated as being in the user group, then, at block1116, a device user interface is launched which includes medical device(s) (e.g., pump(s), apheresis device(s), etc.) at the location1107.

For example, a biomedical engineer configured in the Geri_Hospital A1 has proper permissions to monitor pumps in the Geri_Hospital A1 hospital.FIG. 12Aillustrates an example user interface1200including pumps for which the biomedical engineer has authorization to monitor at the Geri_Hospital A1. The biomedical engineer launches DXT UI1200and then selects Devices from the Navigational panel on the left. The example user interface1200shows the pump in the Geri_Hospital A1 hospital, but the pumps in other hospitals are not shown on the screen1200.

FIG. 12Billustrates an example user interface1250including pumps for which an administrator has authorization to monitor in the Geri_Org1 organization. An administrator configured in the Geri_Org1 organization has the permissions to monitor all pumps in the organization, so the example interface1250shows all three pumps in the organization and their locations (e.g., Geri_Hospital A1, Geri_Hospital B1, and Geri_Hospital C1). The administrator launches DXT UI1250then selects Devices from the Navigational panel on the left. The example user interface1250shows the pumps in all hospitals in the Geri_Org1 organization.

FIG. 13is a block diagram of an example medical device monitoring and control system1300. The example system1300includes a role mapper1310, a location mapper1320, and an access controller1330communicating with one or more medical devices1340-1344. The example system1300can be implemented in accordance with the systems and methods described above with respect toFIGS. 1-12B, for example.

The example role mapper1310uses user group information from a user group database1350in conjunction with role information from a role database1352and maps user(s)/group(s) to role(s). Additionally, the role mapper1310uses information from a functionality database1354to determine what device1340-1344is available to which role and, therefore, to which user(s)/user group(s).

The example location mapper1320uses user group information from the user group database1350in conjunction with location information from a location database1356and maps user(s)/group(s) to location(s).

The access controller1330takes role mapping information from the role mapper1320and location mapping information from the location mapper1320to generate a role and location mapping configuration controlling which user(s) and/or user group(s) have access to which functionality for one or more medical devices1340-1344at one or more locations. As described in more detail above with respect toFIGS. 1-12A, the access controller1330restricts and/or permits information and functionality displayed on a user interface associated with one or more medical devices1340-1344and can customize display and device interaction for a user, for example.

FIG. 14is a block diagram of an example processor platform1400capable of executing the instructions ofFIGS. 7-8, and 11to implement the example systems and interfaces ofFIGS. 1-6, 9A-9C, 10A-10C,12A-12B, and 13. The processor platform1400can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, or any other type of computing device.

The processor platform1400of the illustrated example includes a processor1412. The processor1412of the illustrated example is hardware. For example, the processor1412can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. In the illustrated example, the processor1412is structured to include the example role mapper1310, the example location mapper1320, and the example access controller1330of the example system1300.

The processor1412of the illustrated example includes a local memory1413(e.g., a cache). The processor1412of the illustrated example is in communication with a main memory including a volatile memory1414and a non-volatile memory1416via a bus1418. The volatile memory1414may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory1416may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory1414,1416is controlled by a memory controller.

The processor platform1400of the illustrated example also includes an interface circuit1420. The interface circuit1420may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.

The processor platform1400of the illustrated example also includes one or more mass storage devices1428for storing software and/or data. Examples of such mass storage devices1428include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

Coded instructions1432representing the flow diagrams ofFIGS. 7-8, and 11may be stored in the mass storage device1428, in the volatile memory1414, in the non-volatile memory1416, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that examples have been disclosed which allow access to, configure of, and control of one or more medical devices to vary automatically based on user, group, role, and/or location. Such access control can be dynamically and/or automatically determined. Access control information can be used to generate and/or otherwise customize medical device user interfaces for particular user(s) and/or group(s) of user(s) based on role, location, etc.

Certain examples facilitate determination of employee group membership. User decides what group the person belongs to. In certain examples, personnel roles are configured to map to organizational structure, which is mapped to enable and/or disable access to hardware, software, firmware, and/or other resources. Using such mapping, each person can be analyzed according to his or her role and organizational structure. Using external active directory system and domain control provides flexibility to organize users in an organization regardless of application. Rather than creating a special group with certain users or embedded users and access in a directory in the application itself, a mapping can be provided between role and group without creating a new role and/or new group and without affecting the active directory system to move users around. In certain examples, roles and groups can be created separately and linked dynamically. For example, an application provider can define a biomedical engineering role, and a hospital can define a biomedical engineering group. The hospital's installation and active directory system can map the role to the group dynamically. Access is determined based on the linkage, and the medical device data management system then determines what functionality is and is not available to the user(s) identified as biomedical engineering (e.g., by communicating from the medical device data management system to the active directory and connected devices using the Windows™.NET API, etc.).

Certain examples provide computer-implemented methods for medical device management. An example method includes determining, using at least one processor, a role mapping for a user based on a user account including a user role and functionality available to the user role; determining, using the at least one processor, a location mapping for the user based on the user account and a location available to the user account; generating, using the at least one processor, a combined location and role mapping for the user based on the role mapping and the location mapping, the combined location and role mapping providing allowed functionality at an allowed location for the user; configuring, using the at least one processor, user access to one or more medical devices based on the combined location and role mapping; and facilitating, using the at least one processor, interaction with the one or more medical devices according to the configured user access.

In certain examples, configuring user access further includes generating a user interface for the one or more medical devices based on the combined location and role mapping for the user. In certain examples, the one or more medical devices include one or more drug delivery devices. In certain examples, the one or more drug delivery devices include one or more infusion pumps.

In certain examples, determining a role mapping includes an analysis of one or more roles with respect to the user, the one or more roles including one or more of administrator, pharmacist, or technician. In certain examples, determining a location mapping includes an analysis of one or more locations with respect to the user, the one or more locations including one or more of a region, a city, or a hospital. In certain examples, the method further includes determining one or more user groups to which the user belongs.

Certain examples provide a tangible computer readable storage medium including program code for execution by a processor. When executed, the program code is to implement a method for medical device management. The example method includes determining a role mapping for a user based on a user account including a user role and functionality available to the user role; determining a location mapping for the user based on the user account and a location available to the user account; generating a combined location and role mapping for the user based on the role mapping and the location mapping, the combined location and role mapping providing allowed functionality at an allowed location for the user; configuring user access to one or more medical devices based on the combined location and role mapping; and facilitating interaction with the one or more medical devices according to the configured user access.

In certain examples, configuring user access further includes generating a user interface for the one or more medical devices based on the combined location and role mapping for the user. In certain examples, the one or more medical devices include one or more drug delivery devices. In certain examples, the one or more drug delivery devices include one or more infusion pumps.

In certain examples, determining a role mapping includes an analysis of one or more roles with respect to the user, the one or more roles including one or more of administrator, pharmacist, or technician. In certain examples, determining a location mapping includes an analysis of one or more locations with respect to the user, the one or more locations including one or more of a region, a city, or a hospital.

Certain examples provide a system including a processor and a memory. The example processor and memory are particularly configured to implement at least a role mapper, a location mapper, and an access controller. The example role mapper is configured to determine a role mapping for a user based on a user account including a user role and functionality available to the user role. The example location mapper is configured to determine a location mapping for the user based on the user account and a location available to the user account. The example access controller is configured to: generate a combined location and role mapping for the user based on the role mapping and the location mapping, the combined location and role mapping providing allowed functionality at an allowed location for the user; configure user access to one or more medical devices based on the combined location and role mapping; and facilitate interaction with the one or more medical devices according to the configured user access.

In certain examples, configuring user access further includes generating a user interface for the one or more medical devices based on the combined location and role mapping for the user. In certain examples, the one or more medical devices include one or more drug delivery devices. In certain examples, the one or more drug delivery devices include one or more infusion pumps.

In certain examples, determining a role mapping includes an analysis of one or more roles with respect to the user, the one or more roles including one or more of administrator, pharmacist, or technician. In certain examples, determining a location mapping includes an analysis of one or more locations with respect to the user, the one or more locations including one or more of a region, a city, or a hospital. In certain examples, the user belongs to one or more user groups.

Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent. While particular embodiments of the invention have been shown and described, it will be obvious to those skilled in the art that changes and modifications may be made therein without departing from the invention in its broader aspects.