[MUSIC] Welcome back. So, so far we've talked about interventions and decision support in general, what you want to accomplish and how you know you've accomplished it, a little bit on design of these interventions. In this module and the next, we're going to discuss the knowledge that goes inside these things. This is something a bit more specific about informatics. Because it's informatics folks, we tend to talk about the knowledge in a system, rather than simply the design or the programming, which tends to be more of the IT side of things. In this module, we'll talk about the knowledge that's used during the decision support, and the next module, how do you get that knowledge into the system? So, just to remind where we are. So, this cartoon basically points out that in the center, you have the clinician, or the user, or the patient, or the population health management interacting with the computer. The computer takes its data on the ground situation either from the patient or from the physician, and then applies certain knowledge to that specific data to come up with a plan for action, or a specific recommendation for action. So, the knowledge that's in the knowledge base here, is what I'm calling knowledge for use. It's actually applied at the time that decisions are being made. The next module, we had to get knowledge into the knowledge base, but today we're going to be talking about what that knowledge is and how does it look like? We discussed in the past, a number of different types of widgets that one has for decision support and other interventions. So, this list reminds you what they are. A little bit of screenshots from the past, we're going to be going through this list in a minute. You can see that I divide the list of interactions in terms to the knowledge that a system has. So, first we're talking about providing information. When the knowledge base is providing information, it's not actionable knowledge per se, it's not telling you what you should do, its basically giving you a file as it were of information. It's almost like going to Wikipedia or going to a website that is giving you authoritative, which is important, authoritative information. The knowledge really lives in the mind of the user than in the knowledge base itself. It's not actionable knowledge. We will see that there is knowledge and perhaps, which files to present which is something else. But very often, if you go to a website of information, there's nothing active. It's static knowledge that the user reads. The next type of knowledge is what I would call implicit knowledge. Here, the computer knows something, but in a sense that knowledge is inaccessible. If you've written any computer programs, you know that there are "If-then" statements, and there are all sorts of knowledge that the computer uses. When the "If-then" statement is part of computer coding in JavaScript and Java, whatever language you're using, that's what I'm calling implicit knowledge because if the knowledge changes, you need a programmer to go dig up how that knowledge was implemented in that code, and then to change the code, and to go through testing and so forth from there. So, the knowledge is there but it's kind of not accessible. You need a programmer and certainly, the machine can't reason about its own knowledge. So, the list I've shown you, when you have an order facilitator, simply which orders are put on that screen, is kind of programmed in. If you want to change the list, you need to talk to the programmer to make requisite changes. You may have a form that the physician fills out, kind of modeling what the screen looks like, but in that case, the knowledge is not accessible to the computer for reasoning. You'll see what I mean about that as we go along. So, the same thing with the other interventions I'm showing you there where the knowledge is kind of in the structure of the screen, but maybe not accessible to explicit reasoning. Here are examples where the machine can use and does use explicit pieces of knowledge, and where that explicit knowledge is accessible to reasoning. So, you'll see what I mean as we go along. So, let's take as our first example, our favorite little widget, the bilirubin application to help pediatricians and the neonatologists manage babies who may have jaundice. You may remember this graph. The x-axis which I don't label here is time, and the y-axis is levels of bilirubin. Technically, transcutaneous for the group in the bilirubin that's measured through the skin. You remember the story of the nurses in the '50s figured out that babies exposed to sunlight did better than babies not exposed, I won't go into all of that story. So, you can see that above the level of 20, things are red, below 20, things are orange. So, red means critical. So, I can make a rule that implements this graph here to say that if the transcutaneous level is greater than 20 milligrams per deciliter, then babies are at critical risk. Straightforward. If in English, the if statement is on the left hand side and the then is on the right hand side, so we'll call the left hand side the left hand side or LHS, right hand side, the RHS. Sometimes, these are called the antecedent and the consequent. You don't need to go into the history of logic going back to Aristotle. So, this is straightforward rule. There is information around the rule, metadata about rules. So, something like its purpose. Why is it there? If you are writing computer programming, this information would go in the comments section before the actual code and it will generally be inaccessible to anybody, but here it can. The rule can be an entry in the knowledge base. One come to be the left-hand side, another come to be where the right hand side, and the third come to be the purpose. Another come to be the explanation. Why 20? Where does that come? Third, is very important for an institution. It has to be a human being, or it was a committee, who's responsible for that rule. So, if the technology people have a problem, they know who to go to. If somebody else in the organization says I just read a paper about bilirubin, again, who should they go to to talk about modifying the rule, that's listed in this column as it were. Related to who takes responsibility, is the source of knowledge of the rule. What authority, what authoritative source do this committee or this person use to say that it's 20? Again, an item that's really crucial for an organization is that date of this rule was tested either within the knowledge base itself, or in practice. When I say within the knowledge base itself, I'll explain a little bit about that later. The last item is a little complicated. It says when should the rubin even be considered. So, if you think about transcutaneous bilirubin, if somebody gets a physical exam and a heart memory is noted or if somebody has a love value of sodium, or something else happens, it's a waste of time until you ask him about transcutaneous bilirubins, right? Because it's totally irrelevant. So, you'd want the system to say something like, "if a transcutaneous bilirubin is entered into the system, then immediately evoke this rule." The notion of when to evoke doesn't know what the rule is about. All it knows is that this rule should be evoked. So, it kind of cuts down on confusion. It also helps you manage your rule set, your knowledge base because you can say, "Okay give me all the rules that are evoked by the transcutaneous bilirubin." Then, remember I was talking about testing within the knowledge base. I can say, "Okay, are all those rules consistent with each other in a number of different ways?" The last important part of the information is this subtle point about the following. All right, you're telling me if transcutaneous bilirubin, I got the idea of transcutaneous bilirubin. I have the intention as human being managing this knowledge base, but the computer is an idiot. How do I get the computer to find the right data in this morass of the HR to link to this intention of transcutaneous bilirubin? Well, in general, that value is going to be in a field in a table. So, which table should look for? What's the table called? Also bet I could think of three kind of possible names, right? Then, which field in the table? Again, I can think about four different possible names. Then, how do I know that it's really transcutaneous bilirubin? I can come up with two possible names. The first one is in English. The second one is, well, these link codes that I mentioned a while back as a standard to data exchange. So, right off the bet, you can see there are three times four which is 12 times 224 different ways of writing transcutaneous bilirubin. Who makes that decision of how to write it? Is that whether you've written the rule consistent across rules? If I'm going to modify the bilirubin rule, how do I make sure that people are consistent going forward?Finally, do I care that the way I write the rule is consistent the way other people and other institutions write that rule?
