[MUSIC] EHR, electronic health record, systems can either be one of two main methodologies. One is an interfaced EHR, where you have different, what it was called best of breed systems that communicate via protocols like HL7, but each one maintains 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. In interfaced EHR our system, you have all these different systems, you might have multiple vendors, and they use HL7 messages to communicate. The laboratory would communicate in HL7 message through a network, and that would ultimately go through an interface engine and it would send it back and forth. And each one of these systems would be responsible for keeping its data fresh and up-to-date. But note, there's no, for example, central patient index or laboratory type index that might be relatable to the billing system or the pharmacy system. And 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 and meaningful relationships. So an interfaced system has that as a weakness, it is not as coherent. Also, analytics is extremely difficult to gather from a variety of different systems. An integrated EHR our system is where you have one very large database and different information is stored through relationships within that database. So there might be one large central patient index, one large central laboratory test type index, for example. And those conformed dimensions, those dimensions of data [COUGH] are relatable to a variety of applications. And if you think about it, this model really aligns with, as we 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 efficient way. Integrated EHR systems sometimes, though, have a very high threshold for adoption. They're much bigger systems, they're more difficult to maintain, and 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. And also it doesn't allow best of breed development sometimes. Sometimes a focused application can have better functionality. Emphasizing how databases must be designed in a efficient manner more so for clinical informatics than perhaps other industries. Let's take a peek at how is deceptively simple entities lead to very complex relationships, for example, a patient entity. Patient entity, well, you say who's the patient patient? The patient's, no problem, just identify, there they are, when they come in to the doctor. Well, sometimes patients change names, they get married, they divorce, they change names. What happens if the patient has passed away? How would you know 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, 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 a hospital is 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're unconscious or 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. And so that's a common feature in 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 a simple world, go to one doctor and one doctor helps you. But a provider's a broader term than a doctor, and you can have nurses, you can have techs, you can have therapists. And they're all under the rubric of providers. Well, and among them you can have different types. Who was the attending provider, or who was just a consultant, who referred you? And all these are complex relationships, they all fall under providers. But once you start structuring a database, and relating, and tracking what's going on in a hospital or a clinical situation, it becomes quite complex quite quickly. A visit, for example, what's kind of all the visit? You would think there would be a simple discussion, you go away, a patient goes to a facility. Well, what if that facility's a video? Or what if that facility is just a online class or a recording? Is that a visit and was that considered a visit? Does it get billed as a visit? Where is it? What happens if it moves? And what happens, for example, sometimes patients come, they need to come every day to take a lab test, right, 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 lend to the structure in 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, ICD-9, ICD-10? We'll have other slides in the coming sessions that will go into a lot of detail about diagnosis data. Suffice to say now that data can quickly get complex. And if you remember, we talked about inherently meaningful results. Well, sometimes diagnoses 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 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's 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 would be estimate payments coming in? What are the actual payments? Do we do credits? It's essentially, so my point in this series of slides is that clinical data really absorbs multiple subsystems of data. And it becomes much, much more complex quickly than you would think. Therefore, the trend has been and will continue to be centralized large databases for large facilities. And probably ultimately some cloud-based databases for smaller facilities that essentially mimic that trend by using a centralized database in the cloud. [MUSIC]
