[ Silence ] ^M00:00:07 >> In Lecture 4 we're going to discuss healthcare applications and higher level healthcare applications. We have now looked at the lower level hardware components, there was desktop devices. We have looked at middle level software components, line servers applications, and now it's time for us to focus on the domain, which is the healthcare itself. Our learning objective in this lecture, we want to learn about healthcare middleware applications and understand their applicability, what specific problem are they resolving and how did those challenges come about, and how do the higher level applications make use of them to, to meet those problems. And then towards the end we will be discussing an introduction of various types of healthcare applications. So when we look at the middleware components, and in, in our layered structure of all applications and all services in a large healthcare infrastructure environment, the lower part where there are network services, that's our seven layer cake, except that its application layer is, is what the top three layers in this slide represent. And second last, or the, the one above the network services layer is where we talked about internet services, such as the domain name services, our [inaudible] our web itself because the trend being that we are going to write more web based applications than the web services itself belongs into this part of the layer. And the top two layers are all healthcare applications, and we are breaking it up further by saying that there are some common functions, which is what we're calling middleware that are to be used by the higher layer applications. So here are the middleware that we're going to consider. The first one is what's known as interface engine, or in other terms, they're also known as brokers in some area, and what they do is they facilitate efficient data exchange, and we'll go a little deeper into what interface engines actually do. The second one we're going to work, or take a look at is vocabulary services, which address heterogeneity of semantic codes and applications, each applications have their own way of coding various medical concepts and so when we say heterogeneity of semantic codes that means there's no standardization available. There are some standards available, but they're not uniform the way the vendors would write their applications, [inaudible] institution needs to have its own standard or collection of medical vocabulary, which is what the vocabulary service is in the middleware. The third one is master patient index, or MPI, sometimes also called EMPI, enterprise master patient index, it's surprising how often we have this problem that patients get multiple identifiers that maybe because the applications are not communicating with each other, or for whatever's failure reasons one couldn't find the original identifier and one gives the same patient another identifier, so same patient may have multiple identifiers, and master patient index service, as well as the applications job is to reduce the problems associated with that kind of a problem. And then finally, asset systems, which is a catchall for many different kinds of systems that contribute towards all healthcare system applications, definitions of users, definition of desktops, definition of ITD sources, materials, they all come into play in some way or other for the larger healthcare applications and so we are calling asset systems as the catchall to catch it all there. So we're going to go through each one of these, four of these in not great detail, but in some detail to see what kind of applications there are and what services they provide. So the first one we start with is interface engine, sometime in early 1990's when information from one system and typically in those days, laboratory system was the most important one that was implemented, and the second one was the ADT, admit discharge transfer, or registration system that was implemented. The reason the registration system was implemented is because of billing, you know, only when you could record that information with insurance you could actually bill. And on the clinical side, laboratory was implemented because that is the 85% of all clinical data access, and in fact I should just tell you on the side that when you think about a disaster to code a situation in a medical or in a hospital, you have to consider the lab system as the primary one because it takes care of the 85% of information that our clinical providers need. So going back to the interface engine, what's really is the problem? The problem is in Lecture 3, towards the end, as you saw that when we kept adding more and more applications, communicating with our ADT registration system, the picture started to look very crowded with all kinds of lines of data flow that's going from the ADT system to, let's say at least 10, if not 20 different applications that the ADT has to provide data to. So, you can sort of see also that the clinical data that are generated have to flow into the electronic medical records, you can see that the charges that are being generated in ancillary systems because a critical procedure was done has to come back to the billing system, so we want to look at generically and say that it's data flow problem between end applications, okay? So what's the problem? The problem is that the number of flows happens to be of order and square, if you look at 6 applications and then each one of them communicating with the other, in total, you'll find that 6 times 5 divided by 2, 15 interfaces would have to be defined, and have to be managed, and by making each of those links on the right side a different color, basically says that the rules of engagement between those communications are being determined by two end points, and since two endpoints can be very different from each other, their rules about to how to exchange data can be very different from one interface to other interface. So, very soon, if you think of the ADT system, not only ADT systems to worry about registration and ADT, it also now has to worry about 15 to 20 interfaces with different kinds of systems at the other end. What this leads to then, that each application if it has to do this business of communication has to worry about what protocols to follow, am I using a file transfer here, am I using a real time socket transfer there, am I using a web based flow of information, those could be all different. Each application has to consider what the failure situation is, in other words, if any one of the recipients, any 1 of the 5 recipients is [inaudible] not available because it's been brought down, then all the data that was supposed to go to that, each sending application that has to worry about it and keep track of it, and that will be 5 different queues, if you will, that they have to worry about. There are efficiency issues, which is if each of these 6 applications have to worry about 5 other interfaces, there are just too many people trying to look at too many different things, and, and it's definitely not an efficient way of doing things as number of applications keep growing. So, overall problems associated is what formats we are going to use for these exchanges, what coding standards we will use in these exchanges, and the basic maintenance and the operations of so many interfaces becomes a very hard nut to crack. In place like New York Presbyterian, which has over 300 different -- 400 interfaces, between many, many different applications -- well, let's put it this way, the number of applications in order of 100, and if you had to do each one of them talking to the other, it would be 100 times 99 by 2, so that would be of thousands of interfaces. But using better techniques, it's now at 400, and let's see what those better techniques are, better techniques. So, the idea here is we introduce one interface engine, we call it IE, to facilitate data flows between end applications, so we are adding one new application in the middle, but the number of flows of data now has reduced down to, you can sort of see 6 because everybody talks to one central person, and the central person's job is to take care of all those problems that we talked about, the previously each of the applications have to take care of. So we did add one application, but we reduced the number of data flows in the interfaces. And how does all this work? It works by that each application has to address only one protocol, that means how I can give or receive data from the interface engine. Interface engine itself has to address 6 protocols, but it's not addressing 15 protocols. There are 6 queues in the interface engine, and if any one of the systems are down, it can build that queue up, so other applications don't have know that system is down, they can continue to send the data to interface engine and interface engine can queue it up for the system that's down and when it comes back up, it can worry about how to synchronize itself and drain that queue. IE is the logical place where you can work from one code to another, one format to another, as the definitions come, come by. IE is the place where you dedicate people, support people who have to manage the performance and errors and failure and, and new kind of interfaces, and that's a significant activity that in large IT department, you would have a group of people managing interfaces. Application support, on the other hand, manage only one data flow, so they don't have to worry about 5 others and, and 6 application groups don't have to worry about the total 15 interfaces. You can, you can scale it up, and so, so we talked about the efficiency associated with it, performance is, is an interesting concept because of the complexity on the previous one, which is 15 interfaces, performance is usually lower there, even though you're going directly from one system to another system. Where as here, even though we have added one additional steps in the middle, because you can beef up this machine, and you can put multiple interface engines for redundancy and performance, you can actually get better performance because things are much more streamlined. Typically, the message formats that these message go Etchell 7 for healthcare specific messages, in coming lectures from other instructors, you're going to know much more about those standards. Dicom is a standard for sending images across, this comes from radiology folks, impact systems. In fact, they are the people who actually call such interface engines brokers, it's just different terminology used in the imaging world. The kinds of protocols that I used to work with interface engines includes asynchronous or batch communication, which we revise transfers, you can use email to move data, although it's becoming more -- less prevalent, it's becoming rarer, user [inaudible] that is because of security and other, other unreliability issues. There can also be synchronous communications, that means things that happen in real time, such as sockets of TCPAB, and obviously the new techniques of web services, which use protocols like Soap. The interface engines will do the content management, that means they'll convert one set of codes to other set of codes between applications. They'll definitely do the routing component, which means that ADT system is going to send the ADT events in Etchell 7 messages only once to the interface engine, and then interface engine will know that it has to send it to 10 ancillaries, and it will replicate, or it will route these messages to these 10 outgoing queues. Tomorrow if you bring another ancillary system and you hook it up to the environment, you don't even go to the registration people, you just go to the interface people and say I need a brand new interface because you already are getting all these ADT messages, send me the data as well. And, and, and that allows for, for them to have systems that can just simply create another queue, put the routing in it, and, and that's how it goes. Messages may have to be transformed from one format to another format, although if you're using Etchell 7, even there, there are subtle differences between Etchell 7 versions and the messages. And they can very well handle the failures because these queues essentially finds that are being put into, into disks space some place, and if in establishing communication within a recipient or sender, one finds a problem in the communication layer, that means in the layers in the networking layer component, and systems are down, or for some reason the other system's actually down for legitimate purpose, the data can be queued up, and the interface engine without any cost to the applications which, which typically run the way they are running. There's an overall issue about how quickly the data should be moved, and that is part of the performance measurement of the interface engine, it's, it's a question of availability of the other systems than contribute to the availability of the data that's, that's actually [inaudible] So, next we are going to talk about the vocabulary. So we're going to talk about Medical Entities Dictionary, MED, although the more accurate term would be vocabulary [inaudible] in Columbia and New York Presbyterian we have used [inaudible] and Medical Entities Dictionary for a long time, and so I'm kind of comfortable using the word MED. So the kind of problems MED addresses, it simply is that consider that one application uses the letter M and letter F to present gender, whereas another application uses number 1 or number 2 to represent gender. And when we send data from one site to the other site, the interface engine has to somehow know the coding, which say if I see M on one side, I need to convert it to 1, and vice versa. And the place where we store these kinds of equalities and information of mapping is the Medical Entities Dictionary, all the vocabularies. So MED is going to be collection of the vocabularies that we have generated internally, some of the things that we decide as an institution that this what we're going to call this, this is what we're going to call that. The vocabularies that come with the application, one, one of the interesting things to consider with MED is over a period of time, let's say 20, 25 years, you're probably going to replace some of your applications, in fact you're going to replace a lot of your applications, and the data that you have collected from the applications used previously continue to exist with the code that was in that application. Just so that you don't lose the value of that data, you must remember what those codes actually mean, and so MED, over 20 years has collected and continues to have vocabulary of systems and applications that have been long dead. However, their data that as it has been copied over and is available to us is still possible and still understandable because MED keeps the meaning associated with that data around. It's also a collection of all the standards, disease, disease vocabularies at ICD9, Snomed, Loinc is the lab vocabulary and disease the drug directories, and so on and so forth. You could then take all this terminology that we put in the Medical Entities Dictionary and you can arrange them, in other words, put links between them using various kinds of hierarchies, or relationships. They could be hierarchies, or they could be mesh structures in which there are relationship being defined between the entities. And these are typically helpful in terms of decision supports and rules. The most common one is object oriented is a hierarchy, emphysema is a pulmonary disease, and you, you can have this as a hierarchy associated with an anatomy, in terms of physiology, and all aspects of healthcare, aspirin is a type of drug. Similarly, you have other semantic relationship such as causes and caused by, you can say, heart disease causes heart attacks, you could say diabetes causes degeneration of eye sight, and then their appropriate medical terminologies that represent that. And you can also have things like spacial hierarchies, which talks about [inaudible] and anatomical component is adjacent to the other one, and, and can be very useful in terms of, say, oncology, and relationships associated with anatomical placement of, of medical concepts. This dictionary, this vocabulary is expandable and continues to expand with the new knowledge when new genetics data starts to appear and they have started appearing in, in, in care situations, a lot of genome related terminology will migrate into this. And it is something that may or may not be used in real time with all applications, but all applications depend on it working and translating and providing conversion codes to behave and to, to operate properly. And so then they would be generating out of the MED that code translations may be generated and maybe sent over to the applications or the interface engine to take actions there. The next thing middleware component that we're going to talk about is Master Patient Index, MPI, or Enterprise Master Patient Index, EMPI, and what we're concerned here is multiple patient identifiers. We find that in bigger places, and not even that big, it doesn't have to be that big of place, as long as there are multiple ways to register patients, maybe the ED system is following something different from how a regular outpatient visit happens. You typically get multiple registration systems, so when the same patient comes into the, into, into two different places, same person comes in two places, they're given multiple, two different identifiers. One example of getting multiple patient identifiers is when two or three hospitals or healthcare agencies, or healthcare facilities [inaudible] each other, they've already had [inaudible] scheme and now, now you cannot just simply put them together because both of them use something like six to seven digit number to identify patients, and now if you just move them together you're just going to say that two different patients are going to have the same medical record, and that causes clinical issues and problems, as well as billing issues of problems. And applications themselves can have internal identifiers which are separate from the medical record numbers outside. So, how do we clean up this mess? Well, the idea of the Master Patient Index is to run clever algorithms, do matching algorithms, to bring data from multiple registration systems, put them side by side, and use these algorithms to say with this confidence I say that these two patients are the same, and with that confidence, I say these two patients are not the same. And somebody has to take a look at it and then correct it, nevertheless, if it fixes 70 to 80% of our problems, then we have reduced the problem down to 20%, and that, that somebody has to figure out manually whether it's right or wrong. Note that when we talk of duplicate identifiers, things can happen in two different ways, same patient can be identified multiplied identifiers, as, as I said, if we have multiple registration system. But it's also possible that the two patients are given the identifier, and that can happen when a -- one example would [inaudible] multiple hospitals and if you blindly merge the medical record numbers, but also when somebody comes and gives a common name, like John Smith, or, or Angel Rodriguez, when -- and the registrar, and, and registrar is going to ask what's your medical record number, he says, I don't remember it, they're going to look up this person in the ADT registration system, as they're looking up because there's such a large number of such a common name, John Smith, maybe presented, the registrar can very possibly pick up the wrong John Smith for this particular patient who is presenting themselves. There are, there are rules and regulations of checking the data [inaudible] than many other components, but the fact of the matter is, human error is, is definitely something that happens. And so therefore, two patients can be in the same identifier, and then one would have to [inaudible] that this data is not for the same patient. And the way Master Patient Indexes are implemented now-a-days is that we create a central depository, which holds all identifiers, and then we use intelligent algorithms to detect duplicates, and you can then start adding other attributes of a patient, some people would think that, let's say you have a requirement of lots of consents that the patient has to provide, or directives, they have to provide, perhaps Master Patient Index is a good place to put that for all of, all facilities. Another example is notice of privacy that we have to provide as part of HIPAA regulations, and, and to say that, yes, this person has been given such a thing is, is one of the indicators that we have to maintain, perhaps Master Patient Index is a good place to put that, if not your master registration system. So, the way it would work is then Master Patient Index itself has a unique number, typically called MPI number, and then it hangs the same patient, who may go to multiple hospitals, multiple care facilities and all their individual local numbers are then connected to this master record, and that's how Master Patient Index systems are addressed. So, when we look at the picture, we see then healthcare middleware and the lower part, you can sort of see that there are interface engines, MPI and MED servers, and on the top you can see healthcare applications, Eagle being the registration system that we use. And on the right inside, you see a set of ancillaries, as well as you see electronic medical record systems. You can see that the registration system, Eagle, sends ADT once to the interface engine, and it sends its registration Master Patient Index data, that means registration data to MPI system once, and interface engine then makes replicated copies of those ADT's and sends it over to the ancillaries, and the electronic medical records. Contrast this picture with what we had towards the end of the Lecture 3, you would see that the complexity in terms of the flow of data is actually quite reduced. You can see mid server creating codes, translation codes, and in a batch mode, or in a nightly mode it updates interface engines, it updates electronic medical records, it could do it real time, it depends upon what level of integration one has created with their middleware applications. Interface engines definitely are not real time, they actually work in a semi real time, so somebody gets registered in Eagle, the goal is to provide that data within, within a minute to all of the ancillaries in the electronic medical records. However, that is not to say that it happens real time, which means that the moment the registration happens, the EML also has the data. Med servers are much more batch focused in sort of real time. MPI's are sometimes real times and sometimes they're not, so if a particular EML is actually going to use the MPI as the way to identify the patient, it would use something like a web services to correlate EMPI in a real time mode to show the [inaudible] We now discuss the asset systems as the last middleware function, and this is where we're asking the institution, do we know what the list of our applications are, do we know a list of our servers are, list of our users, and their privileges. And you can sort of see that if I go with the users as a concept, you have to have a system in which human resources provides that data, and you have to accommodate for multiple human resources perhaps. And then you also have to work with the people who are hired in a temporary basis, and you then have to provision these users with application access, based upon what their job role might be, and more importantly, you have to keep track of the fact if a user leaves or changes job, how do you terminate their access from individual systems. So, as an example of a user based, or user asset systems, the middleware example in this case would be centralized authentications. So, how do authentication works, that means signing on words. Well, you can have it completely decentralized, which means every application has its own user ID and a password. Clearly, that runs into a problem the moment the number goes more than three to four. You could have centralized completely, in other words, every application authenticates to a central location. The problem there is that applications may or may not have been written to do any authentication other than the local authentications. With the advent of Microsoft's active directory, it has become easier because many applications would provide authentication against active directory, especially if they're Microsoft applications, Windows based applications. And then you can centralize a set of those to active directory, set of others to other directories, such as [inaudible] and, and synchronize the user definitions across multiple directories. There's something called federation, that's another way of doing authentication which basically says that between, let's say an example, between New York Presbyterian and Cornell, which are two different organizations. Cornell can have their own centralized authentication system, NYP can have their own centralized authentication systems, but there is a trust associated with each other so that if somebody authenticates in one place, we will not re-authenticate in the other place, and as long as we get, you know, through the trust that we have created with the other authentication system who this person is, we can then continue and give them access to applications. And the method there is called federated authentication, which is [inaudible] trust, and we all like to provide components like single sign on, so as to reduce the number of user ready passwords for our users, and this would be a middleware function that could be even at the lower data stage. But except that in healthcare, because of its regulatory requirements, because the types of users were specific healthcare, such as the physicians, the nurses, the nurse practitioners, the physician assistants, the therapist, the social workers, it makes sense to consider this at the healthcare middleware function. Multifactorial authentication simply says that we could use two factor authentication using some -- sorry -- from some kind of card that shows numbers, or we can use our identity badge card for different kinds of authentications. Another example of middleware with assets, like and again with people is, is credentialing systems. So credentialing systems are placed where all healthcare practitioners of the highest order are defined because we are legally required to check and make sure that every two years that they're still credentialed to practice in New York State, [inaudible] to credential to perform these kinds of surgical procedures, you wouldn't want somebody who's an eye surgeon performing a heart surgery, and, and there are checks and balances to make sure a thing does not happen. And part of that is the documentation that's associated with each physician's capabilities and certifications. So, a credentialing system defines all physicians, maintains timely certifications for them, it's also the source to the authentication systems that we talked about for user provisioning, and all of these systems are interdependent and connected to each other, same data that [inaudible] the physicians and NP's and [inaudible] then goes into the billing and registration billing system because every bill has to have the associated doctor and the definition of who that doctor was. We finish our Lecture 4 with a brief discussion on healthcare applications, and we start with enterprise corporate applications. Note that even though we call these corporate they have implications to the clinical care site, so the first one, the most important one is in the area of patient management, registration, billing, which is what we have been calling ADT, admit, discharge, and -- admit, discharge and transfer systems. And other kinds of such systems are systems that do the telemetry, as well as bed tracking, bed tracking in a sense of which beds are empty, which beds are available. The second class of such corporate systems, people management, we talked a little bit about how they're useful in authentication and signing on. It's also related to time and attendance programs, which is about who is coming to work and how long they have worked. The third category's in asset management, here all the supplies that are brought in, drug dispensation systems, radio frequency ID, there's a, there's a effort in trying to see how assets move within the institution, and using [inaudible] ID tags is a reasonable way to track them, which is what the device use tracking is also about. And then finally the time management, residents, nurses, on call people, these are all people who are scheduled every day on different shifts. So at given any moment of time, who are the patient care providers, depends upon how the scheduling is actually established, so these all have implications on the care site, although we would [inaudible] of the systems. When we go to the care site of the applications, we start with the departmental applications, for instance, in this case you're looking at ancillary systems. Clearly, for in each of these areas of laboratory, radiology, pathology, cardiology, which includes EKG, pharmacy, neurology, these are all the areas where we have ancillary systems, which when given a particular test, given a particular procedure, they produce information back to be submitted to the electronic medical records, which we haven't discussed yet. Also, along the same line, we have systems that are helpful for transportation folks, for the social workers, for their note taking, as well as scheduling of moving of patients, and in particular spaces. Typically ancillary systems have a very well understood boundary at the departmental work flow. They are helpful in that particular department's capturing of information, along with their people who are working in that area. They do consume ADT, and although it's ADT from the central system must come to them, so that they know where the patients are, and what kind of activities are scheduled for them. And then in return, they produce clinical data, such as it could be notes, it could be lab results, or specific type of reports, which then go back to the medical records. On the site, they also produce charges because that's how the, the activities such as the procedures or tests have to be billed for, and that then goes back to the ADT system. This are of ancillary systems is continuously growing, they're -- as more specialties and subspecialties come into play, we find that this area is in the growth mode. The next set of components are back to the devices on modalities, the large systems like CT's and MR's are called modalities, it can be diagnostic, or they can interventional devices, they could be drug or material dispensing devices, large boxes like snack distribution, there will be drug distribution systems. They could be monitoring devices for cameras, they can be the beds and IV pumps as we had discussed before. A lot of these devices produce images as output, besides just the reports, and those images are captured in a large picture archival communication system, it's typically not one system like that, the radiology has the most important system that does the picture archival communication system. And then, the content of those systems, A, they're obviously rich data types because not only do they have images, they have audio, video, and one uses Dicom for the imaging standards of -- and they're essentially very high volume, and very high network intensive applications as well as storage intensive applications, so in terms of their performance and capacity, the critical part of the packs is their one order, if not several orders magnitude higher than the simple text best clinical system. The final and the most important class of care systems are enterprise care systems, they are inpatient systems, or outpatient systems, inpatient or outpatient both would have order entry in which something is order for the patient [inaudible] procedure, which then automatically get flows into the ancillary systems to conduct that test. Results [inaudible] this is one place where providers would like to see all the results come back from the ancillary systems, as well as existing notes, and what has been ordered and documentation associated with, whether it's a nursing documents, or a MD or physician documentation. Outpatient and ambulatory systems work somewhat similarly, but they're a little different in the sense that they're not 24 by 7 applications. Usually they are working in the time frame that the clinics are open. Somewhat different associated with inpatient and outpatient systems are systems that are specialty, but have the basically same kind of information, transplant is one are like that, psychiatry sometimes is a separate area like that, simply because psychiatric notes and drugs are legally, legally have a higher threshold of protection and security. Transplant sometimes has information that are related to multiple patients in terms of the donor and the recipients. In research world, we see systems that are helpful to do large clinical trials, so they are based on a cohort of patients who are enrolled in specific clinical trials, and they're trials related data are maintained in specific way, which a particular system could support. Currently, in order to bring the consumers, the patients into the patient care areas, personal health records are definitely becoming a very important place where patients are able to participate in their care, they're able to see their records, whether they be lab results or discharge summaries, or instructions, or education material that clinic or inpatient area would, would offer to them. And if they have a long term disease, such as diabetes, asthma, heart disease, they can then interact with their personal health records to record their information, perhaps their reading some glucose or asthma readings, or height and weight, and how they're feeling, et cetera, there are many instruments like that which capture that information and record them in the personal health record. In, in some locations those personal health records can feed the data back into the care scenarios as and when necessary for the physicians or care providers to be able to see the progress for their patients when they are at home. The last class of enterprise wide systems are health information exchange, whereby collection of healthcare facilities agree to exchange information between them in a safe and secure manner for the patients who may be going to any of these locations, these exchanges are becoming quite popular and, and, and are required by the government, federal government to be participating because patients themselves can be moving from one location to another location, and in order to help the flow of the information to happen in the right way, health information exchanges will go a long way to address that, so this is a very short summary of what kind of healthcare applications within corporate world, the care systems that are prevalent in today's healthcare information infrastructure. In our last slide, we looked at various components of information systems as part of exploring what the infrastructure components are, and we found that at lower levels we have components related to networks, hardware, operating systems, databases, and as we went higher into the software layers, we found that there are services, especially with the internet and with world wide web where we could use those services and we used, we -- not just could use, we actually do use those services to build higher level applications. And then we saw that there are special kinds of applications called healthcare middleware that help us do common sets of things that are healthcare specific and that then helped to the highest level at the healthcare applications of corporate and clinical systems to accomplish their tasks. ^M00:43:08