Wireless Devices Are Only As Good As the Wireless Network. a Systems Engineer Will Work

Wireless Devices Are Only As Good As the Wireless Network. a Systems Engineer Will Work


  1. Human Computer Interaction:

McKesson products can include both stationary machines as well as mobile devices. The mobile devices can include many varieties of hardware including handhelds. Each form factor is tested by McKesson in order to ensure that the application looks and functions properly. There are engineers that focus on both full screen and hand held views and operability and analyze the hardware prior to the release of the software. These engineers look at the system and the hardware to determine what types of changes would be beneficial to the end user such as touch screen capability. The machines are also testing in a clinical setting and additional adjustments may be made.

Wireless devices are only as good as the wireless network. A systems engineer will work with the hospital’s IT department to assess the network. In addition, McKesson will work with both the hospital and the wireless access vendor as needed if any issues should arise.

McKesson will come to the hospital site and observe the workflow. Their visit is customized depending on which area of the hospital they are visiting. Tailoring the workflow to match each hospital’s need is done by the business analyst, clinical analyst and human computer interaction specialist. Instead of generic workflow analysis, information is collected based on the hospital’s end goal in mind. The real focus is on the workflow with McKesson assisting the hospital to meet their desired state.

Site visits to a hospital are usually done over multiple visits because it is very hard to get a feel for exactly what the hospital desires in only one visit. The scope of the project is another variable that can determine how many site visits are needed. These vendor visits provide insight to many environmental factors that would not be viewed otherwise. Site visits show the workflow and allow for representatives to speak to the hospital employees and management to find out what they are truly trying to accomplish. They look at what the end user needs to get the job done and get back to patient care. McKesson’s view is that if you don’t understand the workflow, there is a great risk for not delivering the correct product.

Unexpected and expected down time is discussed with members from the hospital as well as the business analyst, clinical analyst and system engineer from McKesson. The level of tolerance of the downtime can vary from site to site and also within departments. Some areas can continue to work without the application for hours and others can’t progress if it were to be down for minutes. McKesson works with the customer to develop procedures and guidelines. Scheduled downtimes are coordinated, in advance, with representatives from both the hospital and McKesson.

  1. Requirements Analysis:

Requirements Analysis is done by collecting data from both observing the current workflow, interviews with end users and management and discussing the business needs and desired goals to accomplish. The business and clinical analysts observe the workflow and discover forms or processes that may be able to be reduced or eliminated with the implementation of an electronic medical record. Many redundancies exist in the paper world and the electronic conversion could make them obsolete. McKesson looks at the end result of having a more effective workflow.

Incremental implementation versus Big Bang is usually a decision that is made by the organization. McKesson will support the hospital regardless of the style they opt for. Commonly, the incremental approach is preferred, especially for complex systems. On occasion, due to time constraints and mandates, Big Bang is used.

The program manager from McKesson works with the organization’s business analyst, clinical analyst, product manager and end users. Validation of needs and goals are made up front before starting to build or customize the product. As product is being developed, McKesson works with the hospital to make sure that the specs of the build are meeting the customer’s requirements. The business analyst, clinical analyst and program manager from McKesson will meet with representatives from the hospital to discuss the variety of reports that they would expect to see come out of the electronic medical record.

The application is usually managed within the organization. On occasion, a facility may request that McKesson manages the product remotely, but primarily the application is managed by the hospital.

Each given product that McKesson creates is done with end user needs, regulatory issues, enterprise requirements and administrative desires and access to the electronic information in mind. One example that McKesson has developed is the Horizon Patient Care Folder. This is a secure product that houses all patient information.

  1. Usability Design:

During the early stage of development of a product, human-computer interaction is assessed. Usability design is done by user design and testing, user observation and user teaching with several people on a team.

Each adjustment is tested and retested until it meets certain criteria. This prototype testing is a line item built into the project plan time line and occurs simultaneously as the product is being created. McKesson does not wait to do their testing until after the product is complete, they test with the prototype up front and at different intervals.

During the usability testing, the human computer interaction specialist is accessing basic functionality of the application. Are there too many clicks, colors, too many required fields etc. Systems analysts are also brought into to test this product. Objective data is needed. This is all completed prior to the general release of the application. Items such as required fields or colors may be added upon customer’s request if desired.

Change management is handled by the product manager in conjunction with the customer. Scope is managed closely by both parties in order to be able to deliver the specified product on time. Changes to the system must be prioritized and the highest priority changes are completed first. In all phases of the product implementation, scheduled meetings take place either weekly or biweekly, depending on the scope and the customer preference. McKesson also holds periodic calls with other hospital sites, usually approximately 10 sites, to discuss future releases and requests.

  1. Safety/Error Prevention:

Safety and error testing is done with every application that McKesson offers. However, the robustness of testing varies depending on the application. The nature of the application is considered. For example, the care plan on a med- surg floor may not be as robust as a detailed ED documentation system with electronic order entry. Each system is assessed individually.

Infection control is a very prominent topic in regards to computer hardware and devices that are taken in and out of patient care areas. Human factors engineers have had many discussions on this subject.

  1. Usability Testing:

All usability testing is done with clinical analysts, business analyst and human computer interaction specialists. This testing is started at the inception of the design of the application and continues throughout the entire build. Hands-on testing is done prior the general release of the application.