Welcome to week 3 of our introduction to medical software class. In this week's lectures, we will look at the clinical environment and the constraints that come with it. Both constraints that come from the environment itself, that doctors and nurses, all the stakeholders are involved and also the associated technology that is present there. The database that we have to interact with, the electronic health record, the parks, the imaging databases, and then issues to do with the regulations that are in this area, the data privacy and security issues and increasing emphasis on cybersecurity. Those are our topics for today. This is what we'll cover. We'll talk about health environment software. What we need to interface with data, privacy, laws and regulations. As I mentioned before, cybersecurity, we have six segments here. First, we'll talk about the stakeholders. I labeled these patients, doctors, and all the rest of them are involved. We'll talk about clinic on information technology in two segments. The first one is a general introduction. The second one we'll focus in on medical imaging will have a demo presentation of the imaging and the health records databases from person medium, eyeball [inaudible]. Then the last two segments we'll talk about data, privacy and cybersecurity. In just like every week, the presentation here to space and on the textbook and here we're looking at material from Chapter 3, of the textbook as we go. Segment 1, patient, doctors and who else is involved in this complicated process called the healthcare system. In the past couple of lectures, we have talked extensively about the regulatory environment. Here we'll talk about environmental issues software will operate in. Who are the users, who are the buyers, what would you have to interface with? That's an important I will underline that we'll come back to this. There are other laws and regulations, especially regarding data privacy and security. There's HIPAA in the United States. This is medical specific and as GDPR in the European Union and discovers all forms of data of which medical setup is just but one example. The example I like to always use for my students to think about this is this concept of the, no man is an island is comes from a point from John Don for about 400 years ago. The point begins with the words, no man is an island entire of itself. Every man is a piece of the continent, a part of the main. When you think about medical software, take this palm and transpose it a little bit and make it sound like no medical software is an island entire of itself. Every piece of software, piece of a workflow, a part of them in system. Tongue-in-cheek, that gives you the picture of what we're talking about. Your software is not going to run the entire process. You have to go back and forth with others. Let's just look at this. Our software is likely to be part of a workflow. This graphic up on the top left, this purple box is your software, but the user is something else before and there'll be, well you something else after. Keep that in mind. You're not controlling the whole process is very rare. We must understand what comes before and what comes after it. What Bridges do we need to build. Are we connected databases? Are we connecting to hardware? What standards do you have to follow, is there s communication standards are the most common age of seven for health records, DICOM for images, and what other constraints come into play? What data privacy, security, cybersecurity, and other regulations do we need to worry about? When you enter this business, when you start a new project in the medical world, would you want to do is to understand the lay of the land would come through for you what comes after you. Where's the data coming from? Where is the data going? Who is providing the data? Who's consuming the data? What format is this data coming in? All of those things are almost the first step in designing any piece of medical software. You have to map the world, figure out where you are in that world, and just work around those constraints. Let's talk a little bit about the health care system and we're going to give them a little bit more of a basic description of this. But similar to a doctor legally represented in week 1. The US healthcare system is complex and often hard to understand even for those people who are working on it for many years. Part of the issues are historical. Beginning in the 1930s, health care benefits were and are for the most part, primarily provided as part of employee benefits. Typically the employer covers some of the cost of health insurance policies, and this varies from employer to employer. There are three major components already here. They're the patients, the healthcare delivery organizations, doctors, hospitals, etc, and then the other payers, insurance companies. This sets up an interesting triangle. The, patients pay the insurance companies, who pay the hospitals to provide health care to the patient. You don't have this direct exchange of fee-for-service. This is an indirect system and this causes all kinds of complications. There are other parts of the health care system. You have insurance provided by government agencies such as Medicare. Medicare is a picture from medicaid.gov in the corner. Individuals may also purchase insurance directly from companies is a webpage called healthcare.gov. The setting up of this webpage cost measure software issues. We're going to discuss that at the end of this course in one of the sooner presentations. Finally, we have the Veterans Administration, the so-called VA system has its own hospitals. This is the closest the United States comes to having a single-payer health system. This is for people who have served in the military. Other countries have their own complexities and you may need to interact with them as well. We may have government subsidized mandatory health insurance policies, that case in Germany. Distaste probably to the oldest piece of welfare legislation, Bismarck's Health Insurance Act of 1883. We have single-payer systems as the UK and Canada where the government is responsible for all payments out of tax money, of course. Then we have combinations such as public free plus private enterprise and countries like India, Singapore, Native Cyprus, many other countries. All of these are important because you need to understand who's paying for your software and whose needs do you need to meet? Keep those things in mind as we move forward. What are the stakeholders involved in the health care system. This is from a report from ANSI. You can see title below. Of course we have points of care. We have hospitals, long-term care facilities, assisted living, and anybody else who provides care to patients. We have pairs, insurers, Medicare, Medicaid, employee benefits, and all those people come into play. We have clinical support, things like clinical labs, imaging company's pharmacies, with business associates, people who benefit managing administrators, payment agencies. We have IT services, people who data storage, we would web portal support mobile access. There are all kinds of other people playing in here. There's insurance companies, law firms for malpractice purposes, contract research organizations, and all of this complicated list of people comes into the picture. Your client, your user may be in one of all of those things. You do medical software, but you may be working for customers or primary law firms that need violet claims of malpractice that could be on example. Keep this more expansive view of medical software in mind. Most people think that this is software's going to be used by doctors and nurses, but the reality is a lot more complicated than that. This leads to the fundamental question of who is my customer. You need to identify the needs of the user. This is the start of the medical software lifecycle. But some products user, the appeal a pair might be the insurance companies. Anything that reduces the cost of care will appeal to insurance companies. Others may appeal to hospitals and in that improves the efficiency of care. We can see more patients in a finite amount of time. Those may appeal to the patients directly. It makes life easier, it lets you schedule appointments unless you get your results. The customer varies who is interested in the software will vary depending on what you're doing. To conclude the circuit, we have this quote and paraphrase in from Dr.Kirashi. You'll hear from her in week 12, but it's a comment makes many times the end user of software whether a doctor, and nurse or a patient is often not the customer who purchases a product. This dichotomy between the buyer for potential piece of software and the main uses of a particular software make the design of software even more challenging. The problem here is, and we're going to hear more about this in week 12. The problem here, fundamental is this, the user of your software may be a doctor party payer, person will pay for the software as insurance agency. You have to satisfy the needs of the doctor, has to be easy to use, you have to let her do what she's needs to do. But if the insurance agencies paying for it, you also have to demonstrate that this particular piece of software is going to reduce the cost of medical care. As an example, there may be other situations like that. With that, we conclude this introduction to the healthcare system. We'll discuss clinical information technology in the next couple of seconds. Thank you.
