Hi, Sam Meiselman here again, welcome to this section of the course. In this section we're going to talk in more detail about how databases play a role in clinical informatics. You may have seen the informatics stack in an earlier section of the course taught by Dr. Harold Lehmann. Informatics stack is a wonderful paradigm to help organize our thinking along how informatics solves or aligns with business issues and global concerns, all the way down to specific technological implementations. I think of it like a Russian Matryoshka doll one where you have a small doll inside another one, inside another one, inside another one, and really it goes from the most abstract level of world or organization where there's a broad need, down to smaller and smaller organizational units. In this stack, there has a separation or what has been called the line, and the line between what and how. Abstraction again, but it's helpful to understand the different players and the different roles that these things play. So, what do I mean? In above the line in the what, you have the world or organization, a perspective, or a goal. That goal can be identified for example as a health improvement goal, or a population health improvement goal, or maybe something specific like a business need, improving customer service, some of these broader goals. But below the line is the how, is the engineering on how do you build a system or organize a system to accomplish the what. So, as we see, databases will fall primarily below the line, in the how. We may have spent a bunch of time in the earlier sections of the course talking about the what, but now we're going to focus on more of the how. Databases share this with things like a laboratory of management, information system, flowcharts, smartphones, these are just implementations of technology that accomplish your goals. So, let's take an example that's kind of abstract. Let's see how this plays out in a example, perhaps it will illustrate it better. If someone comes and says, "I need a database to track tuberculosis, TB cases." Okay. Well, let's decode what they mean by I need a database to track TB cases. First of all, going from above the line, what is the role? We're using the informatics stack, what is the role that you're trying to accomplish? Is this a clinical database? Are you're doing research on tuberculosis? Are you an administrator that needs to discuss scheduling? That would have greatly different design and impact on what kind of database you'd design. Second, what is the function? What does tracking mean? Do you need to track, at what level of detail? The patient level, or the visit level, at the medication level, at the laboratory level, what part of tracking did you mean when you said track? Workflow, so these again, now we've gone below the line in the informatics stack workflow. So, let's identify what workflows do you want to track or focus on and what workflows are necessary to modify in your organization, in order to contribute data to the database. So, a pre-visit workflow, if we said for example we're administrative then we'd need to know the scheduling. So, we'd have to interface perhaps with the customer management systems, even phone systems, to track how many times did the tuberculosis patient call the phone, and who answered the call, and those kinds of things, or perhaps, we just care about the lab results. How are we sending the tuberculosis cases, a proper lab diagnostic test on a timely basis. There's intra-visit, during the visit, how are we taking care of them properly, are we perhaps isolating them, or attending to their needs properly, and then post-visit, are we following up. So, these are all broader architecture of the workflow designs, but again that's just below the line, that's a how. Role and function might be what, what do we want to accomplish, and workflow is the how, starting to get into the how, but the last is the information system. The information system is purely the how, how do we accomplish this? In this context, the company it keeps means that what context is the database in? Can the database communicate and interface with the existing information systems that are in the enterprise? So, again, above the line here, role and function, below the line, workflow and information systems. So, again how do we build it is the questions that databases are going to contribute to more than a discussion about roles and functions. Another aspect of where databases fall in the informatics stack is the discussion about the differences between privacy, confidentiality, and security. Privacy is essentially a higher-level goal. It is part of the what? Above the line. The ability to keep information about yourself private and that is a goal. That is a desired goal or outcome. Confidentiality is what are the ways we keep to the goal of privacy in setting up access, identity management, making sure our workflows are essentially aligned with the goal ultimately of privacy. Again, as we start to go below the line, confidentiality is the next layer, but databases are even further below where we have as I mentioned before, where we talk about security. Security is very much in the how, the details of how to implement a secure system. First of all, there's integrity of the data system and the network. That's how we know that not just anybody can get into the data. There's firewalls, there's virtual private networks, and protection against hacking or intrusion, and these kinds of things. That is done at the technological level, but what goal is all that stuff serving? That goal is serving confidentiality and ultimately privacy. So again, the how, the database, how it's implemented and security will lend itself to assisting with the higher level goal of privacy. Next, how does the informatics stack in databases interact with the paradigm of intellectual disciplines that align with the stack? So, as you'll see, aligning with the line somewhere in the middle of between the what and the how, intellectual disciplines go from more concrete to more abstract the higher you go. Databases are primarily in the realm of data science and computer science, which is usually narrowly focused on how to solve what are the optimal ways to solve various computing or informatics type of problems. Above this though, you have things like decision science, how do people make decisions, the interaction, cognitive science and ultimately higher level disciplines that look at broader kinds of discussions. Next, we'd like to talk about how databases play different roles in how electronic health records systems are typically designed. EHR, electronic health record systems, can either be one of two main methodologies. One is an interface to EHR, where you have different, what is called best of breed systems that communicate via protocols like HL7. But each one maintained its own database or you can have an integrated EHR, where one database fits all different applications. Let's get into more detail with this. An interface to EHR system, you have all these different systems, you might have multiple vendors and they use HL7 messages to communicate. The laboratory would communicate an HL7 messages through a network and that would ultimately go through an interface engine and it would send it back and forth. Each one of these systems would be responsible for keeping it's data fresh and up to date. But there's no, for example, central patient index or laboratory type index that might be relatable to the billing system or the pharmacy system. The advantage of this interfaced method is allowing each software to develop best of breed practices. It becomes much more of a challenge to keep data coherent. Again, remember the nature of a database to be coherent in meaningful relationships. So, interface system has that as a weakness is not as coherent. Also, analytics is extremely difficult to gatherfrom a variety of different systems. In integrated EHR system is where you have one very large database, and different information is stored through relationships within that database. So, there might be a one large central patient index and large central laboratory test type index for example. Those conformed dimensions, those dimensions of data are relatable to a variety of applications. If you think about it this model, really aligns with as we've talked about before the historical evolution of databases, where data is separate from the presentation, but also unified in a way that people and different applications can share in an efficient way. Integrated EHR systems sometimes though have a very high threshold for adoption. They're much bigger systems, they are more difficult to maintain. They might be overkill for certain facilities. A radiology only facility might not need such a centralized database that can track all kinds of things that it's not interested in. Also, it doesn't allow best of breed development sometimes, where sometimes they focused application can have better functionality. So, in the clinical information system context, the notion of a central patient file. If you remember, we talked about how manual systems were replaced with databases. Well, in hospitals, the adoption of a central patient file with a manual process or manual electronic records. So, this centralized approach or the integrated approach aligns well with a centralized data model. Also, client-server technologies. Client-server technologies as we've mentioned, where relational databases have a central server, where clients make request to it. That aligns very well with the notion of trying to maintain a central patient file. So, what in this case of a goal to have high integrity of patient data aligns well with the how, how to implement it through a client-server platform. The integrated EHR provides a really good match for database technology. In clinical informatics, the need for centralization is a bit higher perhaps, than other industries because the stakes are very high. When there's human life on the line, we don't want to make mistakes about which patient, which physician, which facility, which medication. So, the need from a quality and quantity point of view of centralized indices is much higher. Databases are, and especially client-server relational databases align themselves much more to this need. They make a good match for using them in clinical informatics. In emphasizing how databases must be designed in an efficient manner, more so for clinical informatics than perhaps, other industries. Let's take a peek at how it's deceptively simple entities lead to very complex relationships. For example, a patient entity. Patient entity, well, you'd say who's the patient to the patients, no problem, just identify there they are and they come in to the doctor. Well, sometimes patients change names, they married, they divorced, they changed names. What happens if the patient has passed away? How would you know either way if you continue to send them bills or continue to send them scheduling? What about when one patient comes in and two patients go out and when a mother has a baby? How do you build a system that tracks all that? Another very common internal situation with patient data in hospitals, where the MRN, the medical record number can change or merge. A patient might come in one day and somebody types in their name and enters them in, and then another time they might come in where they are unconscious. We're not able to answer what their name is, and we don't know who they are and another MRN gets added. As soon as that happens, different data gets attached to different MRNs and that splits your data integrity. So, that's a common feature and database identity management to keep that straight. Again, that would help lead and emphasize using a centralized integrated EHR database. What about providers? Well, in the simple world you go to one doctor and one doctor helps you. But, a provider is a broader term than a doctor. You can have nurses. You can have techs. You can have therapists. They're all under the rubric of providers. Well, and among them, you can have different types, who is the attending provider or that guy who was just a consultant who referred you. All these are complex relationships. They all fall under providers, but once you start structure in a database and relating and tracking what's going on at a hospital or a clinical situation it becomes quite complex quite quickly. A visit for example, what's kind of all the visit? Here you would think that would be a simple discussion. A patient goes to a facility. Well, what if that facility is a video? What if that facility is just a online class or a recording, is that a visit? Was that a considered a visit? Does it get billed as a visit? Where is it? What happens if it moves? What happens, for example, sometimes patients come, they need to come every day to take a lab test or once a week to take a lab test. How many visits should that be considered? Is that one clinical event or multiple clinical events? So, these kinds of discussions lead to the structure and the database how to track these things. A diagnosis can have ranges of, well, is that the clinical diagnosis or is that how insurance represents it. What type of coding system do you use? ICD9, ICD10, we'll have other slides in the coming sessions that will go into a lot of detail about diagnosis data will suffice to say now that data can quickly get complex and if you remember, we talked about inherently meaningful results. Well, sometimes diagnosis are not inherently meaningful depending on who is asking the question. Procedures. Procedures are things that are done to you, whether it's a visit, or a lab, or a x-ray, and where all the information here can also get quite complex. Who did it? Which provider did it? Where was it done? Was it linked to this visit? Was it considered a separate visit? How many times was it done? We have to be careful about duplication. If there was an order to request a procedure and then a result that the order was fulfilled. So, this data must also be kept in a coherent manner, which is quite challenging. Lastly, billing. A billing is essentially in data models is its own world to itself and linking to coverage, who pays, estimated, what is called pre-AR. What did we estimate payments coming in? What are the actual payments to credits? So, my point in this series of slides is that clinical data really absorbs multiple subsystems of data and it becomes much more complex quickly than you would think. Therefore, the trend has been and will continue to be centralized large databases for large facilities. Probably, ultimately, some cloud based databases for smaller facilities, it essentially mimic that trend by using a centralized database in the cloud. So, in summary, we talked about where databases fall out in the informatics stack. How the informatic stack and databases, their interaction together in a organizational framework to help you understand the importance of their database role and importance in building proper clinical informatics systems.
