Hence we went our way down the stack now you want to understand how should the system be put together to accomplish all the goals articulated in needs requirements and specification. To talk about this layer, and we need to use two words; module and system. They're complicated and I want to use this cartoon to help you understand what I'm trying to communicate here. So, I've always been talking about the world at the top is tax, I figured let's use the world as our example. So, the planet earth is not air, water, earth, and fire, it's air, water, earth, and life. Here you see those four spheres operating. So, the atmosphere, in a sense, has its own rules like a layer of the stack, it does its own thing but it does interact with other parts of the earth. If it's over a body of water it gets more water, it's over body land it loses land and things of that nature. But you can't talk about the atmosphere on its own. You can't talk about the hydrosphere on its own, you can't talk about the geosphere on its own and you can't talk about the biosphere on it's own. Here we recognize that all four together comprise the earth as a large system. So, in one sense, each of these components is a module within the larger system, and at the same time, each one of them is a system of its own. This is confusion we get with system and module, plus we will see that modules can be systems. So, let's go back to our friend the handoffs that we discussed before the workflow about, remember that there were many people in many activities and so, the handoff process is its own system. We have people interacting, we're doing things, we articulated a number of activities. Recall in the activity diagram we had all those boxes, each one of those boxes was activity on its own and that could operate on its own. We mentioned maybe providing decision support to some people. So, the components of this system would be modules and yet at the same time, the handoff system itself is a module within the larger ecology, if you will, of how to provide care in the inpatients. So, if there was an inpatient care system, the handoff module will be a module but the module itself is a system. There were three ecologies or worlds that we tend to talk about, there is the provider-centric, the patient-centric and the population-centric. Well, let's look at each one in different ways. So, the architecture of the EHR that I've been showing you is basically the the ecology picture for provider-centric care. All the participants here are providers of one sort or another, their systems or their modules support different functions of different providers, and they all integrate into one larger ecology. This diagram has a lot going on in it and the first thing to show you is that the boxes here or the names represent different types of things. So, they could be a product like a nursing care plan is a thing that a module could put out, it could be an activity like charting, it could be devices, it could be other modules like the other financial systems acting as modules in this case, it could be a functional unit like the blood bank or it can be something in this a little bit of a complicated concept. Then it could be a logical component, it's not necessarily a piece of hardware, it's not software but it's not a system, it's a thing that provides a function to the module. So, a knowledge database is a place where rules are stored, why do we need them? Because they need to be supplied to the Decision Support System. I haven't told you the format of the rules, I haven't told you what hardware, so it's a logical components inside a physical component. The other thing that you see on these diagrams are arrows. So, these arrows again reflect different things. You may recall that I'm going to talking about the fourth chart, I said fourth chart shows the flow of control. Here you see mostly flow of data but you can see the data coming in data going out but you also see verbs like requests for decision support and things of that nature. The laboratory information system, is it a module? Is it a system? Well, when you read the literature on it, they talk about these four layers, I listed them in reverse order. They talk about the executive system which helps the executives of the laboratory do their work. So, that's working at the organization level, you have business support system which is at that level that we used to talk to that before about supporting workflow, the operational system is helping actual getting the little bottles of analytes and the reagents moving along on a conveyor belt, and underneath there is a network infrastructure gluing all the pieces together. A laboratory information system has quite a marvel to behold, if you ever go to a pathology laboratory these days. But you see the EHR is only a quarter of activity, you don't see the whole factory that's going on behind the scenes. We talked about an EHR, we already talked about the different modules that one can have, we went through 100 different systems that can be in any one hospital. Today though, when you look at increasingly with the EHR not as a repository of data, but as a platform for other things to happen. So, in the picture I just showed you with the red ring, there are many pieces feeding off of the EHR and therefore communicating with each other, asking for data, accomplishing tasks for each other. Well, can that be extended to apps that are not supplied by the vendor and the answer today increasingly is yes. So, the question you should have is okay, what is the glue that links that app to the EHR? Or to use a fancy word how did they interoperate? At a top-level, there's something called, an effort called Integrating the Healthcare Enterprise or IHE. They are all about writing profiles, or that choreography of the different participants to accomplish a task. So, if you want to get a child vaccinated, that you have the providers EHR, you might have a supply chain module that is keeping track of how many vaccines, or the error in the office, or you might have the public health agency and the immunization information system. So, all these things have to be coordinated, and what that coordination should be is IHE. In order to get one part of the coordination to happen, you need a protocol. Basically, these are verbs plus data. Increasingly, there are different flavors for these. One increasingly popular type of representing the data is called fire, the Fast Healthcare Interoperability Resource, and those get connected to things like CDS Hooks, which is clinical decision support, Hook, to link both, let's say in EHR, together with some external decision support system. So, the cds-hooks is kind of the verb along with slots for these fire nouns. This notion of a protocol supplying verbs and data is example, it's called an application programming interface or API. It used to be that API was proprietary. You needed to know a particular vendor's API, so you could connect to it. One incredible power of the web was, in fact that that API was, it might be proprietary but at least it was public, and people knew about. Increasingly, there are APIs that are in fact not proprietary and known. So, I'm making the claim, in the sense that the EHR-based information system is the architecture for providers central care. When you start thinking about patient centeredness, you have to think about what is the ecology for the mHealth for mobile health and for health apps. These pictures that I have, basically from UCSF and an open mHealth initiative that they have, starts over the observation that right now, when you buy an app, you buy one little monolithic system that has to do a whole bunch of activities for itself, besides just deliver the interaction that you want. So, there's analysis and visualization feedback that each app figures out for itself from scratch. There's some sort of data processing, it's storage, there's data transport, there's data capture. None of which have to do with the purpose for which you bought the app. So, wouldn't it be nice if, what did I say if you heard somebody say, "Wouldn't it be nice if?" But here, it sounds like you really need a way to work horizontally across these silos, and so there should a layer of analysis that is in common across apps. There should be a layer of processing, again common across apps, there should be layer of storage, layer storage, et cetera. When in fact when you do app development, there is a stack, like this below this stack. But increasingly, the vendors of smartphones are building these higher-level stacks up above the lower level ones that they hand out, so that people build applications on smartphone in the first place. So, here's a fun, the UCSF mHealth mobile framework, can you locate the cell phone in this ecology? Let me just give you a minute to do that. I find it on the left-hand side. The only point I want to make with this picture is in fact that, even a smartphone app is part of a larger ecology, we say here that in fact, if you don't connect the cell phone app to the EHR, it probably will be health out that it's not used, but you can see that. In population centered, the EHR now is a module in this larger ecology of systems. So, I'm showing you here a number of different EHRs. But now, they're feeding their data through some sort of master patient index to a number of different data repositories that are shared in this larger system. I'm ignoring HIPAA. I'm ignoring data use agreements and all the policies, and all that, just to make the point that, just architecturally, there is this type of way of thinking about where your data live. Public health, recall that we've said, that even though there are all these functionalities, they are today still silo-ized. Very similar to how we saw the mobile health environment was silo-ized, and we don't yet have an architecture that makes those common tasks, common across applications, in initiatives that a lot of legislations dictate. In dictating information systems to support, let's say an immunization effort or a lead abatement effort, that legislation ends up forcing further down on the stack. So, that legislation high up in the stack leads to a silo-ization further down. Here's from Europe, an Open Health Information Exchange. I'm using this picture, I once more just to have the fun of showing you the stack upside down because then, everybody uses my way of layering, but the point is, they are layering. So, they do have a layer of applications, in this case, it's at the bottom. They have a layer of platform, and then they have the constituent systems on top, but we would put them at the bottom. So, I think in closing, I don't think you're going to run out and out-develop in architecture, but I want to I think you have an appreciation that sometimes the depending on which world you are in, the information system architecture is heavily influenced by what you're trying to accomplish, and to help with these three examples, you have a little library of ways of thinking about these architectures.
