Framing The Complexity Of Hit Systems Design

Framing The Complexity Of Hit Systems Design

HIT Systems are complex in so many ways. Besides the fact that they have multiple users, implementation environments, moving parts, standards etc., etc. they need to talk to each other, prevent medical errors, and be supported by standards, policies and services as well. These requirements (functional or non-functional) feeds into both the system design either in the requirements analysis phase or the feasibility analysis phase. In short, some major parts of a HIT system that contributes to complexity in HIT systems are; users, environments, multiple functionality, broken healthcare system for which HIT is to augment, patient safety etc., etc. In the case of user, HIT system users may either be a person (e.g. apps), a practice (e.g. Lab systems), a population (HIEs and Hospital E.H.R Systems), and the public (Surveillance Systems). There is also the system developers who are also users during training and maintenance. System users may be a combination of two or three of these groups. Standards, security and common formats makes it possible for interoperability to happen. When system designers design for HIT, they may be designing for either a person, practice, population and/or public. Below is a diagrammatic view.

Hit Systems Design Vs. User-centered Design

More recently, the term system design has been used ambiguously to mean either IT system design or user interface design where user experience and human factors are explored. This means that the question of what really is design in a health IT system may be subjective and may need to be explored and re-defined. However, in our use of the term system design, we think of the integrated planning, coding and testing of a system. Which means a system designer will ideally think of all system features with same magnitude and equal importance. Thus a system’s front-end feature like interface, functionality etc., is as important as the backend features like security, networks, storage etc. User-centered design, however approaches a system design from a user’s perspective and needs. It places top priority in making a solution usable in the context of the entire list of priorities for system design. Some sub-incentives that are gotten from good user-centered include; the ability to help save time as users navigate the system, pleasant user experience, increased usability of system and decreased cost in system training. System designers as well as users do not want to be spending hours working their way around software which is supposed to
be a business solution and make life better for the user. System design and user-centered design generally work in together as it has been found that better user-centered design usually means better system design.

Planning Hit Systems Design/development:

Feasibility analysis and requirement analysis phases are two distinct phases that are crucial planning phases for system design in HIT. However framing the feasibility/requirements analyses perspectives is needed to understand how both are crucial in systems like HIT. What both phases are and how important they are summarized in the 5K analogy below.
The 5K Runner Analogy:

It is evident that both feasibility and requirements analysis are vital for systems design. The feasibility analysis is developer- centered whiles the requirements analysis is client or user- centered. A better way to frame the importance of both feasibility and requirements analyses is with an analogy. Assuming you are thinking of running a 5k. Feasibility analysis for this run will be the following; considering whether or not you are physically fit to run, whether or not qualified to run, whether or not you have the capacity to run 5k, whether or not you are able to register for it etc. Basically what preparations you will need to run the race. Requirements analysis for this run will be the following; knowing more about the 5k, knowing what is expected of you, knowing what you are running for, whether or not there will be water at specific points, what deadlines you are to meet in terms of registration etc., etc. Which means all the things that are supposed to be done in order to complete the 5k run. In this case, both feasibility and requirements analysis will help you achieve your goal. Sometimes, feasibility analysis may be skipped which leaves just a requirements analysis to be done. In this analogy, some people may decide to get themselves ready and practice for a 5k run before they find a suitable 5k to register for. Others will find a suitable 5k, register and then train for. There is no ideal combination for feasibility and requirements analysis. Everything is basically a case by case scenario where most people do both analyses. On the surface, which one comes first does not make a difference but it really does when you consider individual runners and explore what makes a successful achievement of goal- in this case, running a 5k. Magnify this analogy by applying it to HIT systems, let’s assume that lives are dependent on the outcome of running and winning this 5k. In this case, one begins to understand the role of both feasibility analysis (preparation/self-assessment) versus requirements analysis (marathon requirements) in large complex HIT systems design.