Introduction
Because STEPSTools is simply an API which provides data and recommendations using service-oriented architecture, it will be up to you and your team to decide how to implement the interface through which your users will access what STEPSTools provides. Based on our early evaluations with users of e-prescribing systems, we have learned the following principles which we ask you to consider when designing your implementation of the STEPSTools API:
- Prescribers don't like to be told what to do. However, an un-invasive inline notice that tells them there is helpful, trustworthy information relevant to an action they are currently taking may be acceptable as long it doesn't interrupt their workflow and clutter their screen workspace.
- Prescribers like to be in control. In the case of clinical decision support, a prescriber may want an option to ask for help (using a "help me" button) rather than be offered unsolicited recommendations. They may want a user preference which could be set to turn on or off STEPSTools notifications.
- Too many options can be overwhelming. The STEPSTools API provides a lot of data. This is not intended for users to see but rather to give system developers who are using the STEPSTools API a buffet of information at their disposal. We envision that the best implemenation of the STEPSTools API would be a clever cross-section of knowledge your system has about your user with the information provided by STEPSTools. Using this approach, your system would select the most useful information from what STEPSTools provides for your particular implementation and display only that select information to your users.