^B00:00:11
>> Hi. Welcome to the Healthcare Systems Infrastructure section of the Health IT Certificate Program. My name is Soumitra Sengupta and I'm happy to talk about the systems infrastructure components. As you can read from my bio-data, I'm an Associate Clinical Professor in Department of Biomedical Informatics at Columbia University. I'm also the Information Security Officer for Columbia University and New York Presbyterian Hospital and I joined the department in the Medical Center in 1987 and since then I've had great opportunities to work on very different aspects of healthcare computing, be that in networking, in systems and interface engines using interfaces and it's been great experience for me and I'm happy to share some of the information that I've gathered with you today so that you can understand how healthcare systems interact with each other, what do we look for when we think about those systems running well and doing the right thing for our patients as well as our providers who care for those patients. So welcome to the section and we move on to the next slide. So in this section we have four lectures or four sections, one lecture each, and what we are going to cover are an introduction, which is simple terminology associated with what are the parts of infrastructure. Then in section 2 we're gonna go deeper and so [inaudible] desktop devices, networks. We're going to be discussing what should be the properties of these kinds of things in a healthcare information infrastructure. Then we go a little higher and talk about programs like client server models, what kind of applications and what, how do applications gather data and use data, and then finally we'll conclude in the last lecture talking about healthcare middleware and applications. That gives you a whole spectrum of different kinds of components that are used in the infrastructure to accomplish the task which is to create an information environment for our providers to be able to provide the best care. So our learning objectives in the very first lecture is that we understand what are the distinctive computing components in our infrastructure. We should be able to look at those components and classify them. There are many reasons to classify them. Reasons to classify them could be how to manage them. Are there dedicated people needed to manage special kinds of systems or we look at them and, and see what the dependencies between the systems are. That would be a different way of classifying systems. So we learn a little more of that and then for all of these systems to work well we have to look at them critically, looking for what are the properties that we are interested in for those systems, what should be monitoring for those systems to bring the best value to our users as well as to the institution. So how well they're performing, are they scaling, are they providing the right functionality? So what are those properties? And the word we use for that is quality attributes. What are those properties of those systems that we should be specially paying attention to. Our sections 2, 3 and 4 which will follow after this lecture, we'll be talking about additional components and go deeper into the components in healthcare and learn a lot more details about them. We start with simple terminology so we say computing infrastructure includes first, a collection of powerful backend computers called servers. Now, you all probably have seen them. They are big fat computers, lots of disks, sometimes disks are outside, sometimes disks are inside. They have CPU, powerful CPU or many CPUs. Nowadays, you have two, four, 16 CPUs in the servers. You have blades which are multiple CPUs on, on a blade rather what we used to call PCBs, that are plugged into the other inside one chassis. So even though we call it one server, it could be a collection of CPUs with a collection of servers, lots of memory, 16 gigabytes, 32 gigabytes, 128 gigabytes and those are typically sitting backend. In other words, users of the system don't get to see them much. So what do the users see? You will see the next point which is a collection of front end computers and these are known variably as desktop computers and as they become lighter and movable we call them laptops. You all have them, I'm pretty sure, and this day and age we have nowadays new set of laptops which are now tablets. Tablets may replace all the laptops eventually and we all carry telephones and [inaudible] small devices which we do a lot of computing activities. So those are all front end computers used by the users to work or participate in this large infrastructure. Now,, if data is going to be sitting all on the servers and users are sitting with the PDAs we know that the desktops and servers now need to communicate information over the network. The network can be wired, which means it's going to be faster or it could be wireless which means it's going to be convenient but not that fast, and we'll be going deeper into these topics of servers, desktops, networks in our section two. But for our terminology perspective we understand that there are backend things called servers, front end things called desktops, laptops and there's a network that's connecting them.  Following on then, the information that we're trying to capture in our systems get muddled [assumed spelling] as data so we will be always be talking about where's my data, bringing data from the server to the desktop. Data is moving over the network, is it encrypted? So, information which is real world information gets converted into data that are physically stored on the servers. You could store them in files or you can store them in more powerful abstractions or systems called databases. They can also be something called warehouses. They're just terminologies. They're all technically all databases. Typically, you would call a database dedicated for a particular function whereas warehouse is collecting data from multiple databases. So it's a database of databases in some sense and it's able to give you much more insight when lots of data from different places are put together. All this data is then manipulated using applications. Applications are programs that are running both on the servers and desktops, communicating with each other, bringing data as necessary to the users or storing data as necessary from the users, then getting manipulated, analyzed, transformed, exchanged and all of those things are done by applications which are a collection of programs that are running at any given point of time to do those actions. We call that set of things data processing as well, and the next point basically says that the applications create, modify, delete, show, print and you can take many different kinds of verbs, whatever you want to do with data, you do in the context of a set of programs that are part of an application. The last thing, the last point I'm making here is that the large and important applications are often called systems and people could agree or disagree with the terminology here, but stick with it, stick with it for, for this section. Sometimes we may casually call what's your system, maybe you might just simply mean hardware or the servers. Sometimes we might say this is my large registration system. Now, a registration system whereby patients, when they come into the hospital, are getting registered and their data are captured in terms of where do they live, who is the person to contact, also next of kin data, what's their ethnicity, what's their race, insurance information, all that thing is collected in a registration system. It's not one application. It's several sets of applications so when I say large or important applications are often called systems, I mean in that context that perhaps there're many applications together as a larger systems. So we'll talk more on that. So systems, as we explained, which may be collection of applications, they don't stay by themselves. They exchange data between them and as data moves, whether it moves manually or whether it moves in an automated fashion, they then trigger action in other systems. So they're all interconnected and they're all interdependent in some sense to get you data, to follow up actions. And as you follow up pieces of data as it moves from one system to another system and comes back in a transformed way or gets replicated to some other systems, these actions we call them workflows. Now,, you have heard and you have seen examples of workflows that are real world in first class or perhaps, it was the second, first, I think, and in which one of things you may have seen was emergency department's workflows. When we try to capture what happens in the real world in terms of information transformed into data in our health information infrastructure, then we call them workflows in our infrastructure and these workflows typically are representing what is happening in the real world and so those would be the business processes. So systems and workflows thus implement the business processes to ensure whatever the business objective is, is being met. Systems themselves are dynamic because people are dynamic and the business processes are dynamic and therefore systems are dynamic and they require reconfiguration, sometimes we replace them because we're changing the workflow and so, as the needs and the requirements change, systems need to accommodate the same changes. An interesting observation we could make here is when someone has a particular workflow in a real world environment that has no computers, that means everything is manual, when you first bring in a system from outside to automate the sys, processes, you find that the systems when you bring from outside, influence how the real workflow then changes. So it's not only dynamic, it's also interdependent between what the real world functions are, which then get changed because we have introduced automated system, and then automated system needs to be configured and reconfigured, depending upon how our real world efforts of our business process changes are going to be. So it's a feedback loop and both are interdependent. But how well do the systems and workflows work? So, what's the efficacy of the systems and workflows? That depends, not only how well they model the business processes but also depends upon their basic performance and those basic performance, in turn of the system, depend on their components, the servers, the desktops, the networks, the programs that are running on them, their functionality, their speed, their ability to bear load as time passes by. So if the systems have to be dynamic, components have to be dynamic. If I am suddenly expecting that this is the flu season or, or winter is just starting, I'm going to see many more asthma cases in my ED, is my system dynamic enough to be able to handle 50% more load in terms of number of patients coming in, which then transfers into the question is the hardware sufficiently big enough, do we have disk storage capacity so that if there're 50% more patients, can we handle that within that system with no sweat, and if we can do that then we have a good system. Goal of the systems enterprise, often it is the responsibility of the, what, generically, I would call Information Technology and Services Department, sometimes they're called IT, sometimes they're called IS, some people call it ITS, is then to optimally create or buy, build versus buy, or then implement, manage, project management, and deliver the systems and their components for the best implementation we can for the business processes of our users and the business itself. So goal of the IT department is to make these systems run as well as they can by doing the good planning, good monitoring, good capacity and performance evaluations and expectations of what the future is going to be. So if an IT department is going to be managing this entire health, healthcare system infrastructure, how should they be organized to do this job the best possible way? And this gives us an opportunity to look at all the systems/applications that we have in our, in our purview today in terms of classes of systems and you could say that these classes reflect, in general, how IT departments are typically structured in terms of a hierarchy office say perhaps a Vice President and a group of people working under the Vice President, perhaps directors of areas and within the directors' of areas, there are managers of applications or systems, as we said. And the idea of this classification is this is one way of managing the systems so that there're dedicated people, professionals who, who address systems in their class. So our first and foremost important class is clinical systems and these clinical systems, their job is to collect and manipulate clinical data about patients and examples are electronic medical records, radiology systems, PACS, images. PACS, by the way, stands for picture archival and communication systems. So it's a generic term of imaging databases such as the x-rays and CTs and MRs. And other examples of clinical systems are order-entry and you sort of see billing. Ever since we have many more federal regulations about privacy and security of clinical data, also known as, in regulatory lingo, protected health information, you should remember that [inaudible], protected health information, PHI, or we simply call them clinical data. You could say that one way of thinking of clinical systems is wherever, in a system, a patient is identified and there's some clinical data about them, the special federal regulations require us to protect that data in a very special way and that in itself works as a classification of the systems. Contrast that with the second category that we're going to call corporate. Corporate is, is a set of applications or systems to manage the healthcare enterprise in an administrative sense. So an example is, it's a very large organization, so let's say hospital, they have a group called human resources and they're working on who is hired, who is fired, who [inaudible] changing job, what level, what title, who they work for, did you get their performance reviews and all that falls under the human resources department. They're not dealing with the patients, they aren't dealing with the patient clinical but they're dealing with the people who work on the patients or work with the patients. Similarly other examples are materials management, if you take a large hospital, it gets millions of dollars worth of equipment as well as supplies and they need a dedicated group to get the best possible value out of those systems. Telecommunications, payroll and one thing you note is billing. Billing shows up here in corporate again and the point we're trying to make here is that some systems such as billing can be classified as both because the part which requires us to go talk to the insurance company then get the money and that money flows through our banking systems and our finance department looks at it and all the information systems there belong into the corporate [inaudible]. However, those bills don't just magically appear. Those bills come from the clinical systems because some clinical service was given to that patient. An example could be that we took a blood sample, blood from a patient and analyzed it and found the chemicals that are in the blood and basically what we call a lab test. If we did that procedure, then we have to charge the insurance company for that procedure and so that clinical activity generated that charge, and if you think about the patient identification, you would see that the bill must have a patient identification because the insurer would like to know, if there is a patient who, which patient is actually, was provided service for which this bill has been generated. So, there can be systems which belong in both categories of clinical and corporate. Now,, we can have, if there are 10 systems or applications that are in the clinical area, you could have a vice president with 10 directors who, in charge of each of those applications, or maybe three directors in charge of three applications with a manager for each application. Same kind of architecture or, or hierarchy can be thought of for the corporate systems and typically in an IT department these clinical and corporate departments are [inaudible]. Going next, then, is a set of activities that are clinical analytics. In the previous case when we were looking at a clinical system, you have to think about how, how the real world is operating. Patients are coming to the clinics, patients are coming to the hospital, they've been given a service, that service generates clinical data, clinical systems capture that data, it generates charge, corporate systems take that charge and bill for the patient. What we call them is a transactional system. Something is done on behalf of a patient and a set of information are generated that are then moved on to other systems. What we're talking about here now is something called analytics. So clinical analytics basically says we take that clinical data that was generated in the clinical systems but we now analyze that data about the patients to identify trends to improve care. So we want to do better care, better operations in our environment. Now, we're looking at the clinical data to generate knowledge so that we can do that. Examples would be clinical alerts. A clinical alert could be that we cannot give a patient a specific type of a drug because they have an allergy and that is something that would, is an intelligent activity and falls under the category analytics. Another example could be infection analysis. When somebody comes to the hospital infections can spread because they're immuno-compromised and, and such infections, in technical jargon, they're called [inaudible] infections, one would have to do some analysis of why am I seeing this kind of an infection in what area and that has to be looked at with many patients data put together and then asked the question is there a connection between them and then finding the root cause for that infection or a vector for that infection and addressing it. Similarly, other examples, patients have a big risk if they're frail and old and have handicap and they might fall as they try to get off the bed or try to go to the bathroom, and fall risk is one of the important risks that need to be looked at from the perspective of collection of patients, same thing with quality reporting. Analogous to clinical analytics we have the aspect called business intelligence. Don't ask me why they won't call it business analytics. They could have. Clinical intelligence would sound strange but anyhow. Business intelligence, and the idea there is to analyze all data to identify trends to improve business processes. Makes sense and an example would be revenue cycle or revenue estimation and recognition in terms of are we making the right kind of quoting which, which helps do the revenue, and quoting right is an extremely important concept from legal perspective. We're, we're not supposed to, we shouldn't be under-quoting that which means getting paid late, less, because that's inappropriate for the services we have provided, but definitely, legally, we're not allowed to over quote, if there's a word like that, meaning that we cannot be charging for something that we haven't done, so doing the right quoting and finding the right balance is an important activity for business intelligence to take. Compliance monitoring, joint commission and there's, there's a commission called Joint Commission of Accreditation of Healthcare Organizations, JCAHO or popularly called "JAYCO" even though is JCAHO. JAYCO has many rules about, and they, they, they basically govern healthcare facilities, typically hospitals, and they have many rules about what should hospital be like and monitoring those for compliance whether its JAYCO compliance or federal regulation compliance. It's part of the business intelligence activities. So these systems, specifically the analytics and intelligence, these systems require data coming from multiple systems and then an inferencing capability, a rules engine, our data mining techniques that then "intelligently" discover answers for specific targeted questions that may have been asked before and now you're looking for a trend, or there's a new regulation and we're asking new targeted questions. You've had a lecture on meaningful use, meaningful use has many clinical indicators and those clinical indicators maybe part of where the clinical analytics and business intelligence are the ones that are going to produce those answers. So those stand as a special case and you could have a group of IT personnel looking specifically in those areas which are separated from the -- The next set of classification of application, again we call this domain classification because of the kind of activity that's going on in these systems, in a large, academic medical center, research is a very big deal, and to conduct research and discover your new knowledge and techniques, especially in healthcare, which is, which is what makes healthcare better than yesterday, as well as most exciting, as new techniques, new drugs, new procedures, new knowledge are discovered using research and there's a special place for the IT departments to help in research by providing research alerts. So if you're doing a study of a particular type of patient who are greater than 50, have had history of heart disease and have been admitted because of perhaps stroke and you're looking for such patients and when hospital gets such patients they could send a research alert to the researcher that here is a potential candidate for your research and, if appropriate, steps are followed and that patient could join the research. Large clinical trials, large [inaudible] identified clinical databases, all of those would fall under the category of healthcare systems that are created to help research. The next category is reference and education. Part of, part of the academic Medical Center's mission is obviously to train the healthcare providers of tomorrow. We know that most of the time you hear about medical students but there is obviously nursing students, students in ancillary services like therapy, physical therapy, physiotherapy or occupational therapy. We will get at Columbia dieticians and interns and dieticians, social work interns. So there's a whole class, various different classes of students who are coming into this field and they need to have experience, knowledge and education on real world practice of medicine. So they have to access healthcare knowledge from their learning perspective and to conduct retrospective educational tools, be they as reference material, such as UpToDate, which is considered one of the best reference material that's accessible, to the latest medical knowledge and I suppose PubMed which all of you should have used by now, and if you're learning, if you're a first year medical student, you need to look at the college's slide databases. People don't really look at microscopes anymore to see the slides, which some people agree is a good thing, some people agree it's a bad thing, but nowadays most of the pathology slides are actually, you're looking at images on the computer and trying to recognize what the cells are all about, whether they're good or bad or they're doing something interesting or different. And these kinds of systems then become part of the reference and educational components. Now, this is not done only for the students. It's also done at the time care is being delivered so at the time care is being delivered JAYCO would say do your practitioners have access to the latest medical knowledge such as the PubMed or UpToDate, and we have to provide that information for the people. Our final category is customer focused. More and more patients are now part of doing the work of looking at the clinical data and part of it is when the customer is in-house we try to help them by making their lives easier such as providing patient entertainment systems, but we also are creating new systems in which they get to know who their care providers are, putting questions about some of the fears or worries they may have about their care and somebody, using perhaps our social network, answers those questions. And these are customer focused so we're finding that IT departments are now trying to create groups of people who are focused on those kinds of systems. And the next category under domain specification, the big one, is medical devices. Again in large places there are, there's a group of people called biomedical engineers and while they, at some level, manage large CT scanners or MRI machines, they also work with smaller devices that are everyday devices sitting right next to the patient beds also more complicated devices such as, such as the ones in ICU and, and this group of people are looking at those devices from the regulatory perspective because these are all managed by FDA. So they are monitoring and capturing clinical data but they are connected to the patients and they have to be kept up-to-date so wrist monitored, corrected if there is a problem because they're the frontline data-gathering systems. And all of these devices today have two properties. One, they're actually computers with sensors attached to them, and second, they're not only computers, they're networked computers because the way they're taking the data and sending it back to the backend databases is using the network. So IT department now gets to be the owners of the biomedical engineering folks because they're part of the same family and now they're providing that medical device functions. And the last thing is systems monitoring which is that in this large infrastructure where we have thousands and thousands of desktops, thousands of networking components, hundreds and hundreds of medical devices, telecommunications is now part of the IT so if you consider phones as end devices, as you know phones have become computers as well nowadays, especially in this day and age of IP-based phones which are networked phones, there is a large, large need of monitoring systems. People who are dedicated to monitor servers, people who are dedicated to monitor and fix and replace and bring new desktops, people who are dedicated managing networks, people who are dedicated managing performance of databases or file systems or web servers and, and, and people who are doing security aspects on each and every one of these. So there's, that's one of the larger groups which has the idea to monitor and manage system components also part of the ITS. They could be taking backups, they would be taking service desk or what used to be called help desk, nowadays we call them service desk, take the phone calls from the users and try to help them get their jobs done. So these are the various sub-classes of systems that then translate into the operationally how IT departments are arranged so that they can provide effective management in monitoring and well-being of the systems back to the users. A second way of classifying healthcare systems is, is a way of looking at systems in a layered structure. We'll be talking about layered structures much more when we come to networks but it's instructive to see that there are dependencies between one class of systems to another class of systems. So here what we're saying is that systems may be classified based on layering concept where system in one layer make use of systems in lower layers and we're, we're gonna say let's say there're four types in this particular case, and we name them, going from bottom to top, the infrastructure layer, middleware layer, transactional layer and analytics layer. We referred a little bit, obviously, about the analytics and transactional, so let's go ahead and see what kind of things belong in each of these layered, [inaudible] layered cake. So in infrastructure layer, which is the lowermost level, is where we're supporting all infrastructure components like servers, networks and databases. So back again, if you think about the backup systems, the service desk systems, security tools and [inaudible], they sit at the bottom layer because every system that comes after it needs to make use of this infrastructural lowermost components. We have dedicated people managing servers, who make sure that the backup gets taken, they're dedicated people on the desktops, they make sure that the desktops are well protected and patched and, and, and antivirus systems are running on them. We have service desk folks who are taking phone calls from users and passing their requests to the right group of people or trying to help them change their passwords and whatever else they do, and these are all fundamental things that happens regardless of what the higher layer applications are doing and what the main, or whatever else way we think they should be classified. So the next layer above that is what we call healthcare middleware layer and the idea there is that it provides common healthcare application functions and services. This is, this is a topic that we will cover in detail in our last section. Suffice it to say that there are examples here which say that if you are going to have a healthcare higher level application, you need to know how to exchange data from one system to another system and it turns out that we need to provide a middleware solution called interface engine, again, something that we'll discuss in detail later, that helps you do that most efficiently. Other examples, that every healthcare system is going to be identifying patients using some identifier. If each one of them is going to identify them differently, some by name, some by numeric identifier, one, two, three, four, some by an alphanumeric identifier, A123 or B777. If they all did separately, then they won't be able to exchange information, be able to put the right information under the right patient. So there is a place where we have to say that there is a single medical record number or what we call master patient index, has to be created so that every application above it could make use of it and again we'll talk more in detail about that in section 4. But we call these sets of functions that are healthcare specific but help every application above them as middleware layer systems. The top two layers then are transactional and analytics. Transactional systems, they are enabling the workflows that we talked about for day-to-day management of patients' clinical care and organizations, all our electronic medical records, all our order entry. Order entry application, what, by that what we mean is a physician looks at a patient, decides that this patient needs to have an x-ray, enters into the order entry system that this patient needs to have an x-ray, let's say chest x-ray of specific type, that then goes to the Radiology Department which schedules the x-ray, gets the x-ray done, x-ray is read by a Radiologist or another physician who creates a note talking about what he or she is looking at into the x-ray and that note then goes back to the order entry system as a result that comes out of, as a result of the order. You get a result back which is the note from the Radiologist about the x-ray. All of these systems are transactional and similarly we talked about corporate systems in which the billing is going on, registration is going on, these are all transactional systems. And the topmost layer are the analytics. Now, analytics by themselves cannot do anything unless somebody gives them the data and the data that's given to them comes from the transactional systems. So analytic layer basically has the applications that provide the analytic intelligence, whether its clinical analytics or business analytics, and they also provide intelligence for retrospective analysis and [inaudible] business for the trends and mapping. So layered way of looking at any set of systems, one has to understand that a higher layer is typically making use of the lower layer applications for its purpose and it's usually not the reverse and we'll see more examples of that when we talk actually in section 2 when we talk about the networks. So we've talked about classification of systems, we've talked about IT departments allocation of resources and people taking care of those systems. We now have to talk about what is it that we are looking at in the systems to guarantee or hope that these are well-run systems and are providing value to our users. And so now we're going to talk about properties, also called the quality attributes of the system and when we talk about system, system is built upon several components, so if there is a property of a system, that actually translates into property of the components as well. That then contribute towards operational success of the system. So purchasing or development of a system requires evaluation of these properties against the requirement of our business processes, that means if our healthcare business processes behave a particular way, I am trying to buy a system that matches these things, we have to use our properties to apply them towards the systems to see if it's a good match. And also has to be matched corresponding to the existing IT infrastructure and expertise, to give you a concrete example of that, an obvious mismatch is possible if an IT department is an expert on the Windows systems, Windows-based systems and an application is brought in that works primarily on the Macintosh server. If that were to be the case, and IT people did not know how to manage it, there would be a mismatch associated with it and the quicker it's recognized and addressed by either giving additional resources to IT department or finding an outsourcing arrangement, the better it is. So you have to think of these properties as not only looking at the operational success but it is basic competencies or basic properties of the IT environment of the organization that then should be looked at for matching or not matching with the systems that are being brought in. We see examples of this in many different ways. Many vendors and users who will talk to each other and they'll come and say, okay, this is one of the best systems ever and it, it is all very simple, all you have to do is provide it wireless connection of this type. Now,, it is possible that that's the kind of wireless connection that our IT department does not support, mainly because it's most likely, it's perhaps insecure or not sufficiently secure, adds to the risks to the system and, and they have to be able to express that and say no, that's not the way we operate here because there are security risks associated with it. So then security becomes one of those properties that we ought to discuss it. These properties can be classified first by, by simple criteria which is, are they visible to the end users. So if they're not visible to the end users, we'll call them internal, which is the first type here. And what we're talking about in the internal side of these properties of our systems is, are related to things such as implementation flexibility, something called reconfigurability, something which is how quickly can these system and programs be written to add functionality to the system, that would be called speed of development. So what are these properties? These properties relate to system development methodology. So it's more like a vendor or if your IT department is actually writing programs, then they are the systems development people so they have to have the methodology, the choice of programming language, i.e. writing it in DotNet with CSharp or are you writing it in Java in a Tomcat Apache environment. What are the internal structures, components, decisions about storage, communication, what databases you choose, what tools you're using to develop. And those choices are critical because as the system grows, additional functionality has to be added, you must match the right kind of programmers to the right kind of tools with both of them being optimal would give you to a rapid development cycle. So these properties are important developers and implementers but are less obviously visible to the end users, so you would find that the end users discount this property because they don't understand it but you, as a healthcare professional in the IT world must understand that if somebody is using Visual Basic as a programming development language and they bring that system to us, you have to understand the deficiencies of that system because you know that Visual Basic is some, somewhat deficient compared to CSharp or other object-oriented systems. And you have to be able to express that even though end user may love it, it's ability to run and expand and be more functional, would be severely limited if it happens to be Visual Basic, at least that's the way I feel about it. So, knowing this as a healthcare IT professional is important for [inaudible] systems. However, more interesting set of properties are the ones that are visible to the end user and we would call them external properties and there are four externally visible properties that we are to pay attention to. The first and foremost, the most important one is, well, second most, well, they're all important. Reliability and availability and we have to be careful about these terms because they do have different meaning. So we start with availability first. Availability can be measured by whether the system is available for use when it is needed, whether the system is needed 24 by 7 or not, depends on the purpose of the system. Let's take an example, if it's a hospital which is open 24 by 7 as an Emergency department, then its registration system must be available all through the day. Similarly, all its clinical systems should also be available all through the day because when a patient is in the hospital, and there are hundreds of those patients in the hospital, their care situation can arise anytime and it has to be up. The systems have to be up as providers would want to see data about their patients. On the other hand, if it's a clinic and a clinic opens at 8 o'clock in the morning and closes at 6 o'clock in the evening, then the availability requirements of that system, which we typically call an outpatient system in the clinic, is primarily between 8 to 6 and, other than that time, maybe other activities can go on but maybe the end users are not on the system and therefore it can take advantage of the downtime, as we would call it, to do other things with the system, such as maintain, update, upgrade and other such functions. So the availability has to be measured in terms of when the system is available for use. You don't always divide it by 24 hours, it depends upon only when the users really need it and the question we are asking is how often, or how long or on average, how much time per day, per week or per month the system is not available. Reliability, on the other hand, measures how variably the system is available when it needs to be available. So, okay that sounds like a complicated sentence, but let's look at example. For example, if a system is needed 24 by seven and it is available for 23 hours, on average, so your availability is 23 hours and it may not be great, but 23 hours is not bad out of 24 hours. But, if the one hour of non-availability that we are talking about is different hour every day, in other words, it is un, less reliable if the 1 hour of unavailability is different every day if one day it's at 1 o'clock, another day it's 2.30, another day it's 11.30 in the morning, that for 1 hour the system's not available, then we would say it's reliability is low because it's not predictable in terms of how it's going to be available or is going to be unavailable. So, if you want a system that is reliably available, then you'd say that whatever down time it is going to incur it has to be in a predictable and known up-front way. So you have to understand the difference between then the reliability and the availability. Reliability problems can happen because you may have a transient problem on the network. It maybe that, for whatever reason, one day the server blew one it's CPUs and you have to change it and that can happen at any given point of time but if it happens often enough that it is at different times then reliability is [inaudible]. The second concept, equally important, is performance and scalability.  Performance is measured by how responsive the system is to user actions, now users are directly involved in this, when it is available. So one should not mix availability with performance directly, although it is extremely common to mix those two things, you should measure availability separate from performance. Performance is saying when it is available, is it moving fast enough for the user. In general, performance will vary with the amount of data that is to be dealt with. If you are making a complicated and analytics work, then the user may have to wait until that analytics works on thousands and thousands of patient completes. And so volume of data does affect performance. The other things that affect performance is load, for example, number of users of the system as it goes up. So if you put in a system, a brand new system with all its CPU power and disks and you start ramping up users over a year, then in the beginning you don't have any performance issues, and by the time the system is extremely successful, you're adding users every day, a year passes by, now the number of users have quadrupled and so now there's an issue about how is performance going to be affected. You will note that it varies even over the day. An example would be a typical day in a healthcare organization would say that's starting at around 5:30 to 6:00 when the next shift is coming, the use of the system starts to go up, it goes, continues to move up and, in terms of let's say number of users who are concurrently accessing the system, goes up all the way at some particular point at 11 o'clock. Then between 11 to one, there is a dip which is your lunch dip and then the next highest amount of concurrent users will be around two o'clock and then it'll start to fall down and by the time it's seven o'clock and the evening shift comes in the numbers have gone down significantly. Now, this particular, what we call, a double hump curve, over the years, would continue to rise as the humps will go higher for a popular system where the number of users keep going up. So performance of the system, not when it is less number of people signed on but at two o'clock or at 11 o'clock, 2 p.m. or 11 a.m., is the critical issue. So when it is the worse situation, what is the performance and that's how you measure one of the performance issues. Scalability, comparatively, is being measured for the performance deterioration that happens when there is more users into the system, is acceptable or not because we've either increased the amount of data or we've increased number of users as new data and new users are being added. In other words, is the system able to handle more users as time passes by without making the performance so bad that it becomes lesser and lesser useful. If the performance goes bad with new users being added then we would say that the system is not scalable. A non-scalable system sometimes actually, unfortunately, fails suddenly and rather non-gracefully. In other words, the system may just simply crash and if the system crashes like that, typically the problem is that your data that's, that's been stored, is in an inconsistent state and that's what we call a data corruption problem. So scalability is important because when it fails, it starts to tell you that it's behavior is bad because performance is going slower, it's not getting [inaudible] but it can then lead to a catastrophic [inaudible]. The third of our properties that the users really care a lot about is usability and it's reasonable. We don't, in this section discuss a lot on the usability. I hope that there are other opportunities talking about why systems are successful in terms of what functionality they provide and how well they provide. I'm happy to provide you with some pointers here. They're straightforward pointers but these come from the usability studies. So usability is measured in several ways. First of all, let's just put it out front, good performance and reliability are critical for usability. One of my ex-bosses basically said that speed is the only criteria. You can get away with not having great functionality, you can get away by even having somewhat of a [inaudible] functions but speed is something that must be there for the most 80% of the kinds of things that you're doing every day. So a good usable system must have good system performance and reliability. In addition to that, a good usable system permits users to learn the system as they use it. That means they incrementally find out what the new functionality are instead of having to go to a class. Over time, the users learn to use more efficient ways to use the system because the system has multi novice and expert user interface. This is critical when somebody starts fresh in an environment and the system has been there before and all the workflow of the place has, has its system counterparts and the system has influenced the workflows of the people, a brand new user comes in and, if it's a physician, they aren't have time to go for the training, they aren't gonna go for the training, they're just gonna jump in and start taking care of the patients. It is helpful to have the system for such a physician. A novice interface which allows them to go through things, step by step and discover, okay, I can do this next, I can do that, and helping there is a good idea. However, the same physician, after using the system for two years now knows the system very well and basically understands that when I am in this particular situation, I don't have to go through menu one, menu two, menu three, menu four, I want to jump to menu five where I know I have to do the right thing. And in order to do that now the system has to provide an expert interface to that user. So, how many systems do we know which provide multiple ways of doing the same thing, get to the same thing. An example I would actually suggest to you is one of the latest Microsoft Office suites. They do have shortcuts, they have more than one way of doing the same functions and easy discoverable ways, appropriate for the novice, whereas a quick shortcut way is more appropriate for an expert. We need to have healthcare systems that have some of the, some of the ways to improve usability. The user interface is conducive to easy discovery of functions and memorization of how to initiate a function which also goes by the novice but at the same time things are done consistently on the user interface that, that a user can quickly memorize that if I go here to there, or through there to there, I can expect the same kind of behavior if the structures look the same in terms of starting a particular function. Then finally a superior system allows users to gracefully recover from human errors and reduces the chances of making errors in the first place. This is also a very critical component of usability which, which needs to acknowledge that human beings can and do make errors, and it is not an offense or a crime to make errors because we do make errors much more than the computers do, and in that case, we expect a system to not belly-up and say, oh, I'm just going to do this bad thing because the user told me to do the bad thing. Instead, what we expect is for the system to then work with human errors, knowing what kind of errors it might do, protect the system and the user from making a big mistake and these are a [inaudible] concepts of usability, very few systems actually have such things but these are the various aspects of usability that, even if no one else talks about in these lectures, what usability is. Our final property, the fourth property, is security. Security has become more and more important in past 15, 10 to 15 years, so much so that we actually see some negative consequences because of the security. However, it is, it is obvious that since healthcare data shouldn't be private to the patient and there are, there is harm potential if some data can be known to other people, security becomes critical and the government acknowledges that, the healthcare providers in the hospitals acknowledge that and therefore we have lots of security [inaudible] regulations which again we will cover in some other section in, in this course. So, what we want to say here is that system is secure if it guarantees confidentiality and integrity of information, when it is properly configured for, for fundamentally basic three things. One is called authentication, that means everybody has a user ID and password to sign on to the system. Authorization which says that not everybody gets access to everything. The access is actually made based on need to know and is actually classified that way, and there is an audit log which is that there is always a record of who looked at or who accessed what data and typically when and how. Having these three components is the most important parts of starting to do good security with healthcare systems. A superior security system permits integration with enterprise-wide sign-on. If there are ten applications and one has to remember ten pairs of user ID and password, that is a usability problem but it is also a security problem because we, because we have to know that a human being can't remember ten user ID password combinations. Only way they can remember is by writing it down and when they write it down that piece of paper then becomes a big security risk if it falls, falls out of someone's pocket and into a nefarious person's lap. So when we provide enterprise-wide single sign-on which basically says to the provider that you use the same user ID password to access all the ten systems, we've not only improved usability, we have also improved security. There are good security which support encryption for sensitive information especially on the most risk issues, examples would be laptops. If you are [inaudible] carrying protected health information on the laptops and going out, on, those are known to be a problem from security perspective because laptops do get lost or stolen and when that happens and the protected health information, the systems were not encrypted, we have a security problems. So security you done well follows best information security practices best done healthcare regulations for the system. So now we have learned that there are four external properties against which we should be evaluating our systems and therefore the components of the systems, and as we do that our next, next lecture would be on servers, desktops and networks in much more detail and as the case will present, we will be looking at these properties on those components and asking the question how could we improve on those properties. So until next section, thank you for joining me in, in Healthcare in Systems Infrastructure lectures and we move on to the next section.
^E01:05:45