prn: OnCall–Features and Non-Functional Requirement Concerns

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

  1. Clinician
    1. Create Account/Register App
    2. System Level functions
      1. Create Profiles
        1. Create Patient
        2. Create Medication profile
        3. Create Dx Profile
      2. Edit All Profiles
      3. Search All Profiles
      4. Export Patient Profile
    3. Patient Information Functions
      1. Add Patient Profile
      2. Update profile contents
    4.  Searches
      1. Meds
      2. Dx
      3. Episode
      4. Patient
      5. Disposition
    5. Keep Contact List (ERs, Drug Stores, etc.)
      1. 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…


  2 comments for “prn: OnCall–Features and Non-Functional Requirement Concerns

  1. David Gilmore
    August 2, 2016 at 12:48 pm

    There has generally been too much promotion of UCD as a silver bullet – as a process guaranteed to deliver a usable result – but that can never be true. A UCD Process requires that you gather certain kinds of user-centered information and use them in the design decision-making, but as with any design process, it cannot guarantee that the right decision is made.
    So, how to fix things?
    a) We need to educate people that UCD is a change in the decision-making, informed by the new activities. Just doing the new UCD activities won’t change the decision-making by itself
    b) We need to explain that all user experiences are unique, so usability can never be guarantee of anything – this is no different than reliability scores for car engines not promising you anything about the particular engine you bought
    c) user experience goals (and their usability metrics) need defining early and in relation to expectations about user types (novice or expert, clinical domain knowledge). Ideally a customer of a system should be able to read and understand the UX specification of the product, to help them make their judgement.
    Finally, customizable UIs are no silver bullet either – partly because they need designing too, so the amount of UI design has just doubled, and if someone is not good at it for the clinical part, why would we expect them to be good at designing customization features? But also, much clinical work is collaborative and everyone having their own, customized, different UI can be a significant impairment to helping someone else do something. And, then, customization takes time and assumes the user can do a good job of designing their own UI – but these are very doubtful assumptions – there is little evidence that people actually do customize their UI.

    • Jerome Carter
      August 2, 2016 at 1:27 pm

      David, thanks for your comment! I agree with points a-c as well as with the notion that customizable UIs are not a “silver bullet” because there is no such thing as a silver bullet. However we seem to have very different notions concerning what “user-configurable” means.

      When use the term, I am referring to the ability of users to adjust the UI to their needs. I am not calling on users to design their interfaces from scratch, but rather that UIs be created that allow users to adjust them. This could apply to anything from font sizes and colors to window locations and the data that are displayed.

      If the UI is tied to a specific user how could this possibly interfere with any other user? They would never see another user’s interface.

      Finally, perhaps the reason there is little evidence that people would configure their interfaces is because no clinical software that I am aware of permits them to do so. Thus, it is premature to conclude that, given the chance, they would not.

Leave a Reply

Your email address will not be published. Required fields are marked *