Modern healthcare organizations cannot depend on homegrown software alone. Medical and healthcare software (MHS) has blossomed over the years and is a market worth hundreds of billions of dollars, with hundreds of MHS companies. These companies are involved in building and delivering products, systems, services, or solutions within the medical space. The software solutions generally address these needs—medical record keeping (or electronic health records), hospital management, medical practice management, networking and content management solutions, medical services through web-based portals, and software/middleware—to operate a medical instrument or device, software for medical research and analysis, etc.

Attend the Medical Device Software conference, March 21–22, 2017 in Washington, D.C. | In-person or Virtually | LEARN MORE This article discusses considerations to identify user needs and translate them into design specifications. The users range from a small doctors office to a large hospital. These considerations should provide insights for companies to make the product development process efficient, expeditious, predictable and cost effective. This further enhances the speedier and efficient implementation of MHS and potentially becomes a competitive advantage that should be a strategic imperative for MHS companies.

Considerations in Identifying User Needs

The following are considerations from lessons learned of various MHS implementations (e.g., International Classification of Diseases, 10th edition transition or the Computer Assisted Coding for a hospital):

Innovative Technology: Some MHS are innovative and powerful, but complicated (i.e., the Computer Assisted Coding application). They may sound great from engineering/scientific perspectives. However, companies may lose the first-mover advantage if rushing into the introduction prematurely without conducting thorough testing of the technology in different software environments at different healthcare facilities. It should be noted that a successful change requires all three elements of technology, people and process. A stable and mature technology is the critical foundation on which the other two build.

End-users: Designers must keep end-users in mind since most of them in healthcare facilities are not engineers/scientists with daily productivity metrics to meet. The user interface ease-of-use is critical for a successful MHS adoption. Simple things (e.g., terminology) can create a challenge. In addition to a stable technology and clear process, a change management process is necessary and should be considered for the adoption of a new technology to be successful (e.g., the “super-user” model should be deployed and started early on). Managing change for user adoption is very difficult after the distrust of a technology already set in.

Version: Newer MHS may not operate as older versions due to additional capabilities and complexities. For many MHS, it is not appropriate to market a latter version based on the limited functionalities and excellent results of a previous version (e.g., to market version 2 of a brand new software to other facilities may be inappropriate using the testimonials/phone conversations by staff of a well-known brand in the industry from their experiences of version 1 software that has limited capabilities compared to version 2). Different software versions may have different levels of maturity. Therefore, each major version should be treated as a new and different product.

Interface: MHS can range from standalone to fully integrated applications. As a designer of the software, one should keep in mind that the fewer the interactions with other software the easier for implementation of the product. Therefore, boundary condition analysis and testing are critical for a successful implementation of an MHS at a healthcare facility. In other words, clear specifications of boundary conditions in different MHS environments must be considered for different healthcare facilities.

Implementation: Clear metrics as leading and trailing indicators must be established to gauge successes. In general, the quicker with less hassles for implementation, the better for users. However, if possible, it should be noted that business partners at facilities may attempt to remain on schedule by curtailing recommended testing windows. This will likely exacerbate difficulties for technology issues and undermine the end user adoption. Short-changing for thorough testing was a bad decision because this may take longer or fail to achieve a successful implementation. Therefore, the company should try to prevent this short-changing by business partners and make it clear to the business partners’ executives when the company cannot be confident for a successful implementation.

Management: Conflicts between ongoing operations versus new implementations must be addressed up front. A project plan with clearly defined milestones and required testing that are well managed from the beginning to final user adoption must be followed. In other words, don’t cut corners. Project planning in many healthcare facilities may not exist or are not well established. Planning help from MHS companies may be required to ensure successful implementations without significant interferences with daily operations of facilities.

Technical support: Operations downtime and impacts should be factored in for each update. There should be defined agreements for the timely release of required software for regulatory updates since these are mandatory by regulatory agencies, and all facilities must meet the requirements regardless of their sizes. It would be inappropriate for an MHS company to prioritize any facilities as lower priorities or less important for these updates. In other words, MHS companies need to prepare to have sufficient technical coverage for system updates to cover all their healthcare facilities. Furthermore, responsive technical support can potentially determine a smooth implementation and successful maintenance of an MHS at a facility.

Risk sharing: To encourage joint partnerships for successful implementations and operations of MHS, risk sharing terms to determine MHS payments in association with clear milestones should be considered for inclusions by healthcare facilities in contracts. As we move further down the path of changing from volume-based to quality-based performances in healthcare, it is anticipated that risk sharing terms should become more common in healthcare contracts for MHS.

Regulated software: In general, MHS used in healthcare systems such as hospitals are not regulated.^1,2,3,4 Therefore, to pursue quality innovation, it begs the question if there should be an independent testing/certification of an unregulated MHS before its release in the future towards quality-based performance in healthcare.

References

1. Health Canada. (September 25, 2013). Software Regulated as a Medical Device – Frequently Asked Questions. Retrieved from http://www.hc-sc.gc.ca/dhp-mps/md-im/activit/announce-annonce/md_qa_software_im_qr_logicels-eng.php
   Kim, L. and King, P. (February 13, 2015). Medical Device Regulation in an Evolving Health IT Landscape. Retrieved from http://www.himss.org/medical-device-regulation-evolving-health-it-landscape
   Monegain, B. (November 8, 2013). EHR Association backs no FDA regulation for electronic health record systems.  Retrieved from http://www.healthcareitnews.com/news/ehr-association-backs-no-fda-regulation-electronic-health-record-systems
   NiQ Health. (July 30, 2014). Unregulated medical devices used extensively across Australian hospitals. Retrieved from http://www.careplus-niqhealth.com.au/news/niq-health-reveals-the-extensive-use-of-unregulated-medical-devices-in-australian-hospitals.html