So, it's time to figure out, how you figure out what needs to be done. So, specification for me is, specify means to specify something. We'll be focusing in this module on the needs that the system is supposed to supply, and also what the system needs to be able to accomplish. So we are solidly at the top of the stack, but there are different meanings to these different words. So needs are what people have, requirements are what the system needs to accomplish to help people do their work, and the specification finally is what is the system, how is it designed, and what will the pieces of it be that will help it accomplish the upper tool requirements. So, if I say that providers need to see diagnosis when they order medications, I think we understand that the idea here is that we want to be safe, you want to ease thinking, we want to make sure that the process happens well, so that's a need. On the other hand the requirement is that the module, the computer provider order entry module shall display the problems diagnosis during the ordering process, that's one way of seeing the diagnosis when you order medications, it's not the only way but in this workflow that over in this discussion of this community we may have decided we need to see the problem list. How does this get specified? Well, a specific screen shall display the list which appears in a certain field and in the electronic health record database system, and a certain dimensions to the text box and a certain color, and how long it will be visible for. So, I hope you can see that as you go down the stack you get more and more detail, and even when you get down to it's very low level detail you do recognize that there are trade offs being made, like, how big your box should be, if it's too big and you can't see other things, if it's too small then you can't see it, maybe with color if it's a certain color you may not see it, if it's a different color well it might violate certain code of standards. So, when you get down to the level of specification there are human choices that need to be made, and the decision makers on the top level of the stack should still be involved, these decisions should not to be allocated at only two technologists. So, what I've just shown you goes right back to a screen that I showed before, I mentioned there that in the middle of the screen a problem must help you think about the contents of the patient, and what I just showed you in terms of needs, requirement, and specification could be what was behind the implementation that has what you see in front of you. Your contending forces, on the one hand the client is the expert, elicit to going back to decision makers to make certain low level decisions at the same time as Steve Jobs says people just don't know what they want until you show it to them. So, needs elicitation, requirements elicitation, and specification are all iterative processes that need to be repeated and be made to just confirm that you as a lower level person here's correctly what they want, and confirms what you think you want, and the challenge of course is when do you stop. So, the people who, so, in order to go from needs to requirement for Sydney people these are often called systems analysts, so that's the technologists name for this sort of position, very often it's somebody who has a lot of experience in designing software, implementing software for this community, so they've learned the language of the community. Informaticians can also play this role because they know the language other community as well as the language of the technology, so the skills that systems analysts need may come from technology that may come from the domain, and a huge component of being a successful needs requirements elicited, it needs elicitour is trust. How do you elicit these needs and requirements? Many methods a lot of them come from qualitative research, interviewing is big, so they just want to tell you what they think, sometimes role-playing will say, "Oh, I didn't realize it, that's what I need when I'm in connection". Sometimes the technologists will present the use case imagine that you're giving, that you've got to order medications for somebody who has diabetes, what information would you want to see when you're doing this or you're ordering these medications? A storyboard is like on PowerPoint, is creating a sequence of fake screens or a prototype can be real software that works may be no data behind it but at least, you and the users get to see what would look like, and again, the closer you can get to reality the better criticism you'll get from users about whether it's really meeting the needs and therefore what their needs are. As I've already alluded to when to stop is a big deal and this is called scope creep, whenever you hear the words wouldn't it be great if, or wouldn't it be neat if you should run away with fear and dread because, now the client is enlarging the scope of what you think you're doing. The best way to cut scope creep is to go to the people who are paying your bills and say, "Well, I'm being asked to do such and such is going to raise the cost so much, and all of a sudden you find out maybe we don't need that feature after all". So, the sequence of words goes from shall, so if the client says, "Well, if the needs documented, requirements documented, the system shall display a problem list, if the system does not display the problem list you don't get paid". Should is a lower level, could is even lower, wouldn't it be nice if as I said is one of those phrases you would have to run away from. Now, behind the scenes, right this can and should, so, there's a lot of ways you can do needs assessment are there any theories that tell you how you should do it, or things that you should pay attention to, and we're going to cover a number of theories of information uses, some theories of decision-making. Like with all frameworks and theories, mostly these are helpful for you to think, have I missed something. So, let's see some examples. The first example is don't make me think. This is ubiquitous on the web. You know that if you have to read a screen, it's going to fail. If you had to read instructions to use an app, it's going to fail. So, here's a fun, here's a search engine. I like this because it doesn't track you the way some other search engines track you, and it's one big practically blank screen, there's a box the middle with a little magnifying glass and you know that means search. So, you know what to do, you're supposed to type in the search engine. You're not thinking at all when you do this. Another theory of information use is called berry picking. The idea here is that you're kind of doing an exploratory search, you going through certain resources, you're not sure yet what's going on. So, here if you use PubMed, those little check boxes enable you to save a citation to come back to later. A third theory is called sense making, which means making sense of what you're learning creating a mental model. I could say that I'm hitting you over the head with the stack, because my contention is that understanding the stack and using the stack helps you to make sense of informatic's contexts. But here is a typical environment, that is all about making sense is an online community, online health community, where people share their stories and narratives is a great way to make sense, because making sense involves making a story out of something. You've heard me use the phrase several times. The story I'm telling you is this, again that's to help you make sense of things. A fourth theory of information is called cognitive work analysis, this is more of a way of tackling the problem of eliciting from a user what they really need to do, and it can be done again either through interview or through use cases or sitting in front of a prototype, but, how do you do your work? What do you need to do to accomplish your work? What do you expect here in order to get your work done? This is firmly in the theory that informatics is about helping people get their work done. Now, in terms of decision-making, I'll show you basically two theories. The first is called a dual process theory. Dual process theory which was promulgated by Daniel Kahneman, who got the Nobel Prize Economics for this work, and has been used in many other contexts. He is behind behavioral economics. The idea is that, as decision-makers we are both rationals. We make slow and torturous thinking in decisions. We are also fast and frugal. So, if I show you this screen very quickly, you know that the top two rows, something is good. The bottom two rows something is bad. So, that quick assessment that something is good, that's fast and frugal. This is heuristics and it's also called system one thinking. Now, what this screen is, is a risk calculator. The question of this risk calculator is, number one, what is your risk of heart disease? So, what is your risk of a serious outcome or any complication and should you take action based on that risk? So, the first two rows, you see that the machine has calculated a risk, and it's called green because it's to the left of the threshold for action. Where did the calculation come from? Where did the threshold come from? That's slow and torturous that's a lot of modeling, that's data collection, that's calculation, all the stuff that you don't do as a user, the machine is doing that behind the scenes. The bottom two rows, the machine has gone to the same calculations, but now, the risk is above threshold, so now the whole thing flashes red to tell you danger and so, this is a great example of a system one interface, but system two slow and torturous reasoning behind the scenes. I would argue that this what we should aim for in most decision support tools. Another more descriptive type of decision-making theory is called the transtheoretical model. I love this name because the name of the theory is IMB theory. Those of you who may remember Odysseus, when he's escaping from the Cyclops, he has asked what's your name? He says, no man and Cyclops starts yelling. No man is escaping and anybody who says then shut up already. So, this is the transtheoretical model, there are five phases to it and what I'm showing you on this patient, this is education page to the CDC, all five domains of transtheoretical thinking are on there. On the upper right, you have what's called precontemplation. You didn't even know that Ebola is a problem. The whole transtheoretical model came out of smoking cessation, so this should be, you didn't know that smoking was a problem. Now, for smoking, by now everybody knows it's a problem, but Ebola, you might not have known. The lower left goes through the three phases. The first phase is contemplation okay, and I'm interested what more can you tell me then is preparation, I realize I'm going to be doing something and I've committing to doing something and action is okay now, what are the tools I need to actually get the thing done right? On the right, lower right-hand side you have what's called maintenance, so yes you're already doing whatever you need to be done, you stop smoking, you're putting into place protections against Ebola, but now you want to be maintained. The upper left of maintaining is something therefore, recidivism because that's for people who have gone through all the phases and they've had it, they want to give up, it's too onerous, and now you can use a video which is a real, very strong system one sort of intervention for a strong emotional intervention to get you re-motivated again in emotional position. Can get you be motivated to whatever it needs to be done with Ebola virus. It's not so important to be compulsive about which label I put in which box, but to get a sense of two things, one, the type of information you put out there does tackled different stages of the behavior change model, and number two is, you want to be aware of where your audience is. So, for this course, we presume that you're somewhere between precontemplation and contemplation. I am giving you this stack as a tool, for those of you who are somewhere between contemplation and action, kind of make it easier for you to think about action and so we're using these theories actually in the teaching that we're doing. The last theory is one that's used by a lot of app developers. The two main theories used by app developers are the transtheoretical model and then the social cognitive theory. I'm not going to go and while this transtheoretic model is about your state of thinking, your state of commitment, the social cognitive theory is more about how you feel about what you're doing. So, you can see that at the top, there is a lot about the belief of self-efficacy, do you feel that you can do it? One could argue that perhaps, one could argue that this is something to do with contemplation and towards preparation, and then you see down again going look in the right-hand side, you see there's goal representation and the outcomes is little bit system to flavor to what you want to accomplish. Though, the third level is what you actually do, there is the action planning which is like contemplation and action, and then find the bottom again, almost popping up a level not only realizing that you have capacity to take action on high-level issues like freedom versus determinism. You can see on the left-hand side there are a whole list of bullets from a set of patient decision aids put together by David Justiffson from Wisconsin for the Chess project, and they've consciously thought about social cognitive theory and I'm showing you the association between some of their features needs, the needs and requirements. Some of their features to the elements of social ties of theory. So, to summarize, in terms of thinking about what the system should be, I've suggested these different information theories, information behavior theories as things to keep in the back of your mind, not necessarily to fall slavishly, but again to double check which theory is appropriate for your problem, and have you missed something, that you might not, make you come up with something that you might otherwise have missed. So, I show you how for instance we use the transtheoretical model in building this course. Theories are nice and you're always going to bump into practice. This is should versus can as Kurt Lewin said, "There is nothing so practical as a good theory". As I suggested that helps you keep track of what your, helps you keep track, helps you keep track of what you might be missing, on the other hand Yogi Berra, that great philosopher once said, "In theory there is no difference between theory and practice, but in practice there is".
