For tracking the reliability name, is there a process that you use all the time or there's a process you use depend on, it is always new or is it like a framework use to tackle a problem? It's good question. Let me start with the inter-team communication. We rely heavily on collaboration systems. Of course, there's always email. But we use a variety of products for issue tracking and knowledge base and wiki management. We definitely have a communication process where if there's an issue raised, it goes into this issue tracking system, and it's communicated appropriately. After that, we essentially walk our technology stack. When we have a problem, we have a full procedure where we'll start from our own. Was the end result reporting data, the staging data, the transformation going back to the sources? So you go backwards through the ETL process. Exactly. Got you. At the end, you took whether it's been plugged in or not. Yes, right. Which is always a fun experiment at home. "I didn't plug it in." I think the last one we'll talk about, we talked about maintaining the meaning of this or talking about how does this data mean that you're delivering to the customer. Do you understand it? Do they understand it? How does that work? That's a very good question. Most development projects require tremendous amounts of collaboration between the subject matter expert, the data architect and project managers and business leaders. So I call that where the DBA has to extract the implicit knowledge in the subject matter experts because it's in their head, but very often they don't know how to express it, and it's your job to get it out of it. Would that be true? That's true. It's a duality. The subject matter expert will say, "Well, this is my requirement." Here's a great example. A professional billing is a tremendously complex intersection of clinical and financial data, and within each one of those has a variety of domains of expertise. The clinical data, as I've talked about and Heidi spoke about very well in the different datatypes, follows a certain pattern, but the financial data and also the predictive financial data. Professional billing is not just about what charge happened, but what do we estimate? What is the accounts receivable? What is in these things? Subject matter expert might say, "I have an expectation of this," but in order to understand the data and how it's been represented in the data gets quite complex and these several engineers to interact with that. I'm glad you brought that example up because we spent so much time talking about clinical data. Sometimes I feel that the financial folks don't get respect that they deserve because, actually, all the technologies, we talked about informatics where they have not been applied to them. In my view, they're still working with 1990, 2000s technology. Well, it's a great example because in Epic and in other big EHRs, financial data does play a core role in the data. However, in my experience, I've worked on what can be considered mainstream accounting packages Great Plains and other types of big accounting packages, SAP. Their entire backbone of the data is built around transactions and customers and vendors and AR and AP and GL, these accounting terms that, you're right, does stem from an older, if you will, set accounting practices to retrofit that into a clinical data model is really sometimes a difficult fit. But the flipside, decision support and ontologies and all the modern technologies that were using for medical informatics, and that really gets applied to financial. But I don't want to spend lot of time all about these with technology because I think a lot of our viewers may end up working in an environment where you do that. One of my slides and in module one where I talk about deceptively simple clinical data. So the reason why some informatics has not been applied to the same depth and accounting systems is because a vendor is a vendor is a vendor essentially. Now you might have a vendor that holds other vendors or a holding company or a pass-through entity or these other accounting concepts. But the range of identifying what is a vendor is much less than trying to identify a patient across enterprises or a patient across facilities with multiple medical record numbers or these things. So I pace an identity is much more challenging than customer and vendor identity. That's true. So I think that's quite a fair mix of things. Is there something else you want to communicate about what is it that you do? We haven't spoken too much about the data, ironically enough. This is all the stuff that goes around the data. Then somebody give you clinging in a question that you've got to answer the question. Right. So the data, a large part of my role is doing design review and really trying to make the database understandable and easier for adoption from report writers or other analysts. Often it's easy to make something complicated. It's much harder to make something. So, for example, we have a lot of work going on now tracking opioid and opioid use and opioid tolerance and opioid documentation. It takes design reviews to see, "Well, what's the best way to articulate that in a simple form in the existing data models instead of building another little silo of data that maybe has a good immediate use, but long term would break the data models?" This often puts me in a bit of a tense situation because projects are very focused on getting it done now and don't put roadblocks in my projects. So, often the easy thing to do is just put it in there and don't worry about all that. It's classic can as you should. Exactly. So it's a balance. It takes, again, a lot of upfront communication with subject matter experts and project managers and building expectations. But, overall, we've seen the long-term benefits where our data warehouse within the last even 12 months, the use has greatly, greatly expanded, and by doing the preplanning of better design, it's led to a much broader adoption, and we project a much broader adoption. So it sounds like you spend a little time in building a construct to deliver it to the user based on the data model. Then you have to store that construct somewhere to make it easily retrieved next time somebody asks about it again. That's correct. So part of what I do is code reviews and storing examples in our knowledge base of how to access certain data. For example, what are the top 10 allergies or what are the most common medication orders for a particular demographic or these kinds of things. So with these kinds of queries, we store, we share. They're not always immediately reusable, but they're very good building blocks. This week, we're happy. How do you find these examples? Well, we have several ontologies. The nice thing about using a wiki product is that we are able to create articles and then after the fact figure, "This article would relate here and that ontology of, for example, by major diagnostic category." So a query that finds diabetics with high lab values, that would relate to diabetes, but it also could relate to laboratory or it could relate to patient visits. So we're able to build several different ontologies where people can drill down to get to the same article. So using ontology to navigate your way through this knowledge base. That's right. So, in summary, we have an ontology based on diagnosis. We have an ontology based on a patient-centric view and also which table gets out to the database table, which table or specific data elements are we using so people can see related queries. So just to kind of wrap up, clearly, we've gone over the stack, right? We've talked about above the line stuff. No matter how much you want to be just technological, you have to deal with people. It sounds like you start. You got the subject matter experts, you get their analysts, you got the report writers. You left at your boss, we're not going to get into that. So there's a lot of involvement above the line. There's lot of, obviously, organizational issues, the business continuity. You're delivering business continuity technically, but if the business were to be discontinued, you'd be in trouble. So your job would be on the line, so that organizational need to maintain continuity. I'm not going to go on, but it's really fun to hear how we've gone all over and to hear how the concepts that we've talked about in the course of both this course and other courses has come into play to see. It, actually, it makes sense for reality. Right. Thank you. I think one of the most rewarding pieces of this, all these different elements of the informatics stack play out in day-to-day. But I wanted things I've said in some of the courses that I've taught, is that when people have the ability to get at the data, they become free thinkers. They don't have to rely on other people's interpretation. They know they can get the information themselves, and it's very empowering. That's something I find very rewarding where you can increase people's abilities and give them so they can make better-informed better decisions. Which is a great way to close with that, even though the job is technically a technical job, you're actually empowering people above that line and actually speaking to their better angels of their souls. That's right. That's going all the way up to the world of informatics stack. So thank you very much. Thank you.
