In the last post, I discussed obtaining requirements with use cases. Requirements come in two basic varieties: functional and non-functional. Functional requirements state what the system must do. For custom software, one gathers requirements by working with future users. For prn: OnCall, I began by writing down a list of potential features based on my past experiences. Software that begins this way (as a developer’s idea) needs input from potential users as early in the process as possible. There are many ways to do this: focus groups, surveys, looking at similar applications, and feedback from prototypes. I’ll be using this blog as a survey of sorts. Anyone with feature ideas, please send comments.
Use cases are an obvious way to gather requirements when developing for clients. They are just as useful when one dreams up an application with little initial outside input. Adding detail to use cases has proven to be a great way for me to sort out application behavior and data requirements. In fact, I am beginning to think that use cases should start as narratives and then be modeled using a workflow language. (At some point, I am going to give this idea a shot.)
Here is the preliminary feature list for prn: OnCall.
Preliminary Functionality List
- Create Account/Register App
- System Level functions
- Create Profiles
- Create Patient
- Create Medication profile
- Create Dx Profile
- Edit All Profiles
- Search All Profiles
- Export Patient Profile
- Create Profiles
- Patient Information Functions
- Add Patient Profile
- Update profile contents
- Keep Contact List (ERs, Drug Stores, etc.)
- Add/Update/Delete contact
Prioritizing features is important. Every feature takes time to build, so the idea is to build the most important first. Prioritizing means separating out essential from nice-to-have, from wish-list. Since, I have no clients to set priorities, I will go with the minimal viable product (MVP) principle, which, in this case, likely means adding enough features to prevent anyone I show it to from asking, “When is it going to be finished?”
Non-functional requirements address important issues such as security, reliability, or usability. The challenge is how one obtains all of these requirements. For example, security and usability are open-ended concepts. One can use ONC EHR certification requirements as a basis for setting security features. However, security does not arise from simply completing a checklist of items. If a hacker breaks into your system and makes ransom demands, having a completed checklist is meaningless.
Usability is the current non-functional requirement celebrity. (I suppose security might be, but no one seems to want to talk about security; everyone is talking about usability). Usability is a messy business because users are not generic. What may be unintuitive for some is simple to others. What is helpful to a novice might well irritate an expert. According to the ISO, usability is defined as: “ the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”
Each of these criteria is subjective, and surely experience and knowledge affect how usable one finds a system. For example, touch-typists can talk to a patient and type a note while maintaining eye contact, hunt-and-peck typers cannot. These two sets of users will have different responses to a typing-intensive EHR system. The more complex a software system is, and the more diverse the users are, the greater the challenge of usability testing. (I wonder if there is another clinical software design rule lurking here?) How does one take all of the various skill and knowledge levels into account when testing? What is the minimum number of users of each skill level, job role, and experience level required to produce a reliable usability result?
Recently, Ratwani, et al. published a critique of the UCD processes of 11 EHR vendors. The processes ranged from mature to “you’re doing it wrong.” Given the resources and complexity of usability testing, I am not surprised to find such a wide range of efforts. Every day, I am more convinced that the best way to improve the usability of any complex software system is through user-configurable features (user interfaces and process support). However, I am getting off topic… Usability of my app is a concern, so I will try to follow Apple’s lead and provide settings that users can access to tweak the app’s look and feel.
Clinical concept vs. chart concept???
I am not sure if this is a requirements issue or not. Clinical software should support clinical work. To do so, to some degree, clinical software must capture and manipulate clinical concepts. Here is my conundrum: How does one separate clinical concepts from chart concepts? Are they different and, if so, how? Adding a medication to the chart is not the same thing as a patient actually taking that drug. A medication list is a chart concept—it may reflect clinician beliefs, intentions, or what the patient is actually doing. I may explore this topic further in the next post or jump into looking at classes, depends on how philosophical I feel…