Mate Mulac
We - we can slowly get rolling here. Do you guys agree? Excellent. All right. Well, as the other folks log in I want to provide a quick intro here. Good morning. Ladies and gentlemen Thank you all for joining us today for this exciting webinar. My name is Mate Mulac and I am delighted to have the honor of introducing today's speakers - Alyssa Dennis and Amrit Palaria who will be sharing keys to successful archival projects in healthcare. Before I introduce our speakers I'll take just a few minutes on some housekeeping items and to provide some background on 314e Corporation. Today's call is being recorded. Everyone's mics are muted and the cameras are off. If you have any questions, please put those in the chat and we will get to them at the end. The slides and a link to the recording will be available after the session and will be sent to you. Excellent. Let me take a next minute or so to share some background on 314e. 314e Corporation was established in 2004 and is headquartered in Silicon Valley with a clear and exclusive focus on Healthcare IT. Over the years, our passionate team has dedicated itself to crafting innovative solutions that drive positive change within the Healthcare industry. We understand the unique challenges faced by Healthcare organizations and have tailored our products and services to meet their specific needs. 314e Corporation takes pride in its diverse range of products designed to address critical healthcare challenges. Our solutions encompass a data archival system, a Document Management System, a content management system, a Digital Adoption Platform, a health data analytics platform, and an interface engine. Each product is carefully crafted to enhance efficiency, streamline workflows, and improve patient outcomes. In addition to our product suite, we offer a comprehensive range of services that cater to various aspects of healthcare IT. From EHR implementation and e-learning to training, interoperability, analytics, Revenue Cycle Management, and IT services, our team of experts is well-equipped to guide healthcare organizations toward success in this rapidly evolving digital era. Over our nearly 20-year history, our solutions have benefited many of the country's largest health systems, academic medical centers, county, and community hospitals, and even critical access in independent physician groups. Our affiliations and partnerships allow us to stay current with industry trends and provide strategic advantages for our clients. Without further ado, let me introduce today's speakers. Alyssa Dennis is 314e's HIM product manager. She has extensive experience leading and participating in archival projects for major acute care medical centers. She brings over 10 years of HIM operations leadership. She's Six Sigma certified and credentialed with AHIMA. She strongly believes in the power of effective communication and understands that that is the key to project success. Having been involved in projects where communication gaps led to misunderstandings and confusion, Alyssa is dedicated to helping teams thrive through clear and concise communication strategies. Next, we have Amrit Palaria, who is 314e's director of interoperability. With over 12 years in the healthcare IT industry, Amrit has led multiple projects on data integration, conversion, and interoperability. He is well-versed in technical, functional, and other challenges related to healthcare data. His innovative solutions have tackled complex problems, including the development of 314e's archival solution. Thank you once again for joining us and enjoy the webinar.
Alyssa Dennis
Thank you, Mate. That was a wonderful introduction. So as you heard, my name is Alyssa Dennis, and I'm just going to give a brief overview of what we are going to cover during today's presentation. We have a lot in store for you. Right off the bat, we're going to cover what is an archive project. You know, it's easy to say archive project, but what are some of the key components that actually make up an archive project, and what are some things that you should maybe be thinking about even before you embark on your project of your own? You know, what is the project scope? Saying you're going to start the project and end the project, but what's everything in between? Who are your key stakeholders? Who are your team members that are going to help you get from that point A across to your finish line? One of the things that I'll say repeatedly is you don't know what you don't know, so those team members are going to be so integral to your success. Your project timeline. Again, it's easy to say we're going to start and we're going to finish, but how long is it going to take you to get to that point? That's where it's really important to map some of that along the way as well as ahead of time so you can keep track of where you're at. And then policies and other documentation. You know, you're going to be busy in the midst of your project, so what are some of the items that you can have done in-house before you even start your project? That's where some of that internal documentation is really key. We're also going to be talking about technology considerations and maybe some features that you can even look to see if your archive product supports and determine if it is important for your organization. We're going to talk extensively about data validation and testing because, again, just because the product says that it's done, is it really? There's some ways for you to really find out. How are you going to train your end users? Again, whether it's 10 users or 1,000 users, some of those steps are going to remain the same, and we're going to take you through some of those key considerations. And then finally, how do you know when your project is done? It's easy to say you're done, but what are those pieces that will really empower you to say that you were done and you were successful in what you accomplished?
So, First and foremost, what is an archive project? At its basics, it is a project that focuses on securely preserving healthcare-related data for an extended duration, meeting your legal, regulatory, research, and internal organization needs. That's where that project is going to encompass the key goals of ensuring data's integrity, ensuring your data is accessible to everybody that it needs to be accessible to, and nobody else, as well as ensuring that you are compliant with, again, your state, federal, organizational, all of the other requirements. And then we're also going to look at, it has to manage your storage costs. Obviously, a project has to be for a positive reason, and sometimes a very positive reason is just managing that overall cost. And then how do you do that while you're still minimizing any risks of data loss or, again, that unauthorized access? Probably the best way to try to looking at the start of this project is going to be the only way to do it successfully is through the effective collaboration. And we're going to talk about that probably pretty extensively, because that collaboration needs to take place between your IT team, healthcare professionals, your HIM professionals, legal experts, etc. So there is going to be a large team that's going to help carry you across the finish line.
Amrit PalariaAny other project, an archival project needs to have a strong foundation in a clearly defined scope. And the first thing to figure out is what data you're going to archive? What all would be needed to constitute your legal health record? Are you archiving everything in the designated record set? Which legacy source systems would you be archiving data from? How far back are you going to archive from and for how long are you going to retain? All these decisions would be driven by patient care needs, HIM needs, federal and state laws and regulations, and sometimes also the needs of some third parties that you may need to share this data with. Besides the constituents of the data and its sources, you need to also determine who and how you would allow access to and retrieval of the data, as well as the security mechanisms you would adopt to protect the data and the privacy of your patients in accordance with HIPAA or other laws.
Alyssa Dennis
And then again, within your project scope is going to be determining who those key stakeholders are. Who are your team members? And it might be something where you identify who those individuals are, but they may not be involved with the project in its entirety, maybe just bits and pieces, but again, that's going to be where you scope that. And then finally, your deadline. How are you going to determine when this project is over? Is it going to be done within six weeks, six months? What is the expectation? And that's where you're going to memorialize that in your scope.
So your team members, your key stakeholders, who are those individuals? Because again, depending on the people you bring to your table, this is how you are going to be successful with your project. You know, the first individual, probably you, is your facility project leader. That person is the one who is going to be the ringmaster. They are going to wrangle all of the parts of your project. That person is going to also be probably the key communication point between you and your vendor partner, the one who owns your archive product. So identifying this person early on is very important because this person is going to keep moving your timeline and that person is going to keep pushing for the engagement of the rest of your key team members. Now, another person that is very important on a project team is your project champion. This person essentially is what they say. They champion your project. So they are the ones that are going out to the organization, they're having conversations, they're communicating the fact that this product is going to become available, they're communicating the process and the stance of where we're at in our project timeline, and they are bolstering the enthusiasm. Change is hard. Change in healthcare is hard and constant. So having somebody who's really enthusiastic is really going to help just continue that enthusiasm through the entire organization. One thing that I like is having that champion very high up in the organization. Have somebody who's in your C-suite, have a VP, depending upon your organization's overarching hierarchy, have somebody who's high up because again, the more enthusiasm that person has, that's going to bleed through the rest of your organization and it makes end users feel a little bit more secure that if they see somebody who has a lot of power in their organization, is excited about change, that's going to make it a little easier for them to carry forward with that same momentum. Have the HIM representation. I have an HIM background, I have been there where we haven't been at the table early enough on and it's challenging to kind of pick up those pieces after the fact. Have that HIM representation, whether it's an end user, a super user of a system who can help with the data validation, maybe it's an HIM leader who has more understanding about the regulations and the document retention requirements. Make sure you involve HIM very, very early. And then Amrit, who would you recommend that we involve from an IT perspective?
Amrit Palaria
Yes, Alyssa. It is essential to realize that an archival project would require a gamut of technical expertise. Depending on the nature of your implementation, you are going to need database engineers, legacy system analysts, system administrators, cloud programmers, IT support, and other technical expertise. And more often than not, you're going to employ the services on an ad-hoc basis. So it's very important to plan well. Who all are you going to need and when? Reminds me of a project when we needed to set up the firewall for our integration server. And the one engineer who could have done that was out on vacation. This was a task on the critical path and we were delayed by almost a week because of this. So you need to ensure that the folks you're going to engage are not only aware of their involvement, but also the project timelines and the roles in the broader scheme so that they are available when you need them.
Alyssa Dennis
Absolutely. And then another piece is don't forget your patient care representatives. Those are going to be the individuals that are in accordance with HIM, are going to be heavy end-users of your archive product. And it may not just necessarily be just physicians, but also look at maybe nursing clerks or aides, if they have some responsibilities within documentation and research, nurses, etc. So make sure you really look at it from that full perspective. And again, as you bring people in as a key stakeholder, you're going to be able to rely on those individuals' expertise and opinions to determine if you have holes in your team that you need to fill. And then another piece that I really like to recommend is when it comes to physician representation, there's two sides to that coin. Usually, you're going to have a physician who is excited to be a part of the project. You know, maybe they're going to even approach the project leader and ask to be involved when it becomes circulated in the organization that this product is happening. That person might be a little bit more tech savvy, a little more comfortable with the changes that are happening in healthcare, just has that basis of enthusiasm. That's great. That is a huge, huge asset to your project team. But if it's possible, I recommend also involving somebody on the physician side who's maybe a little bit more reluctant. Maybe they're not quite as comfortable with the tech requirements these days. Maybe they've had a little bit more of a challenge with the changes. You know, just might not be quite as enthusiastic. It's really nice if you can get that individual involved in the product, because one, you essentially create almost a mini champion if you can, you know, waylay some of their concerns because then they're going to communicate just in their day-to-day that maybe the product isn't quite so scary and it helps smooth that way. But it also gives you and your official project champion a little bit of a, you know, a peek behind the curtain, so to speak, of some of the other, you know, little less enthusiastic comments, maybe a little bit more of the negativity that might be surrounding your project whole organization-wide. And it allows you to, you know, plan a mitigation plan a little bit earlier. So if you have that option, I highly recommend involving both. But regardless, the sooner that you can identify who your key players are, then smoother that everything is going to go.
And then identify your key stakeholders' responsibilities clearly and early. So one thing is projects can span months and there are so many competing priorities. So to truly ensure that your key stakeholders remain engaged in their responsibilities, make sure they know what that responsibility is as soon as possible. You know, it's much easier to maintain your enthusiasm and frankly, just plan better if you know that you have a responsibility coming that's going to take three weeks of the fourth month of the project plan. That's better than saying, hey, Tuesday, I need you all day. Well, that gets tough. And it's also just not respectful to your team members, because again, they're with you on a, probably a volunteer or maybe voluntold basis. But regardless, they're here as extra. So it's respectful of them if you can outline their responsibilities early on. And then also another thing that I'm a fan of is at your kickoff go-live call, where you're level-setting, you're talking about your project scope. Memorialize those responsibilities for each key stakeholder. So your team members, you know, six months down the line, when you come to them and say, hey, it's time for you to do X, Y, Z of your responsibilities. You both have a document that you can refer back to and say, yep, this is something that we knew was coming, we identified. It gives everybody a little bit more power in that relationship. So what I mean by that is if you approach one of your team members and say, hey, it's ready, you know, you're ready to kick off your stuff, get going. And they look at you and go, I didn't know I was supposed to do that. That never happens, right? When it does, that's where you both can refer back to your document and say, no, no, no, we had this conversation, you were aware of it. And as a project leader, it empowers you to hold that individual more accountable to what those responsibilities were. Now, on the flip side, if you are that team member and you are suddenly told about a responsibility you had no idea about, and you're thinking, oh my gosh, I didn't know that was coming. You can refer back to that document and say, no, no, no, this was not discussed. And that empowers your team member to either make the decision of, you know what, I'll shift stuff around, I can absolutely take on this additional workload, or it empowers them to push back and say, I'm sorry, I was not made aware of this and I am not able to assist you now. And at that point, the project leader can pivot and determine who else needs to take on that responsibility. So ultimately, memorializing it is very, very important because it is going to continue driving your overall timeline. And then also make sure that you choose some team members to be a part of your project who envision some longevity with your organization. Now, Amrit, didn't you have an experience where that was not the case?
Amrit Palaria
Yeah, so I was involved with this new EHR implementation project where a majority of the existing team members were like one, two, or three years away from retirement. And since they had worked with the legacy systems for a long time, there was a lack of motivation and perhaps even a reluctance to learn and switch to a new system. Luckily, as soon as the project started running behind schedule, the manager noticed the problem. And instead of waiting for the next couple of years to hire the replacement team, he went ahead and hired the new team members right away. The new team had a long-term stake in the project. And so they brought new enthusiasm. And this enthusiasm went a long way towards making that project a success. Moral of the story, motivated and enthusiastic members are so valuable to any project.
Amrit Palaria
Absolutely. And I really do like how that manager handled that situation because instead of being, you know, just simply pivoting and shifting all of the attention to the new team members with that enthusiasm, I feel that the way that they handled it is they just identified there was a gap in their team members and they were able to fill that gap with the enthusiastic new team members while still maintaining all of that legacy knowledge that is invaluable. So I really like how that shows that pivoting I was talking about as a project leader. And then finally, when it comes to your team members, as a project leader, I also feel very strongly that it is your responsibility to create your project as a safe space. So what I mean by that is you're at the very first kickoff call. It is so important to basically lay that stance of leave your titles, leave your egos at the door. Easier said than done. But the reason being is that when you assemble your team members, they are going to come from all walks of life in your organization. You are going to have the entry-level end users. You are going to have potentially C-suite individuals, physicians, etc, and everybody in between. Those individuals come with a wealth of knowledge you cannot get elsewhere. And you need to ensure that you are able to harness that knowledge while still being able to balance some of the stronger personalities. There are gonna be individuals that have no problem speaking up in a large group setting, whether it is sitting around a board table or if you're on a Zoom. There's gonna be those individuals that have an opinion and they want everybody to know about it. And that's great because you need that opinion. But those individuals who are a little quieter, who are a little bit more prone to listening than sharing, that's your responsibility to really tease out. Because again, you brought these team members to the table for a reason. Now make sure they all feel empowered to speak up to the best of their ability.
So not only do you have to assemble your team appropriately, but you also have to do the paperwork. That never goes away. But again, if you plan a little bit ahead, you're able to do some of that paperwork before you need it. And it will stop that mid-project scramble. Because again, some of these are just inevitable. I highly, highly recommend that you ensure that your legal medical record and your designated record set are well-documented, they're updated, and you know where that document lives. I say that carefully for a reason because you would be shocked how many organizations that all of that information lives in the head of your HIM leader. So take that time, document all of those pieces, ensure they are up to date, and you know where to access it. The reason those pieces are so important is because at the time in your project, you are going to be able to turn over that documentation to your vendor partner, and that will help indicate exactly what documentation you need to ensure is in your archive product. It just is gonna smooth the way for you. Another piece is if your archive product does support purging and disposal of records, ensure your documentation in-house is supporting of that. You know, you have your purge policy very carefully outlined of how you handle it, what the expectations are, because again, you're going to be able to refer to that policy, refer your vendor partner to that policy to ensure that the details and the tiny aspects of the purge process in your archive product are built with that policy in mind. So again, it's just going to help to ensure you're not scrambling. Another piece is, as your archive product is getting ready to go live, I highly recommend updating your medical record matrices. So these are typically documents that indicate where all of the different components of your legal medical record or designated record set live in your organization. They generally do not all live in the same system. It's always gonna be little disparate parts, but again, it's really, really helpful to update that information early on, because again, it's going to smooth the way for any release of information processes that you do have that need to rely on your archive product. And then finally, review your access policies. You know, determine who is going to need access to this archive product. And I'm not just talking at go live. So that's another thing you'll have to be thinking about organization-wide. Is this something where you are going to start big and then slowly taper off with staff attrition, meaning that everybody's going to get access to the archive system because you had access to the legacy source system, but then as new hires come into the organization, they will not get access to your archive product? Or is it something where you're anticipating only pockets of users? You know, this group of clinical users, these HIM users, they would only need access. Again, make those determinations early on because it's going to help your end-user training, your go-live, as well as for future additions to your organization. And then also while you're looking at those role-based accesses, if your archive product has any extra security processes, such as like ‘break the glass’, if that's something that you do need as well, just to ensure that you have identified those individuals that should be affected by ‘break the glass’, and maybe you have the option of identifying other users that simply do not need that functionality.
So then project timeline. I mean, right now we have talked about so much stuff and we haven't even talked about the timeline yet. And that can be really overwhelming because essentially, if you think about it, a project timeline, you know, for a fact, you're going to start, you know, for a fact, you're going to end, how do you get there? And that becomes an elephant that you have to consume. So I am a big fan of breaking it down. So you are essentially consuming that elephant a bite at a time. The way to do that is through a communication cadence. So not only are you going to set key goals periodically throughout your timeline, but also you're going to set a communication cadence to ensure that everybody involved in this project knows where the project is at every one of those communication check-in points. That is so important to ensure that your team members know that it's getting close to when they're responsible for a piece of the project. So keep that communication alive. Now, one thing, just as an example, I'm a big fan of setting that cadence maybe at a weekly moment. So we pick a time every single week, like clockwork, the team meets. Maybe, you know, referring to what Amrit said about some of the team members, you know, your IT resources, some of the end-user training resources, maybe those individuals don't need to be at every one of those weekly meetings. That's okay. Because again, we want to be respectful of their time, but you should still be sending out those meeting minutes, those emails, you know, explaining what you touched on during that timeframe. And then also identify to those team members their excusal is only temporary. Trust me, make sure they understand that. But what I'd recommend is when you're looking at your project timeline and you're overlaying your communication cadence, each week, plan three to five mini goals that is going to progress your timeline to be able to be achieved by the time you meet again. And then when you meet again, look back and reiterate, how did you meet those goals? Were you successful? Do you need to pivot? Because something wasn't quite achievable. And then go ahead and plan for your next communication check-in. So again, by taking those little steps, you're going to eat your elephant a bite at a time. And yeah, you're going to be really sick of elephant by the time you get to your close date, but it's going to make it a little easier to just manage everything as a whole. And most importantly, I feel it's really good for team morale because inevitably you're going to reach a point in your project. Usually it's the midpoint where you're at that point of no return. You've come too far to stop, but you don't see enough progress. And you think, why did we do this? This was such a bad idea. I think it's a natural part of any project. But when you reach that point as a team, if you're able to turn around and look back at how far you've come, look at those mini goals that you've achieved. It's easy to see that you are still motivated to go forward. You have momentum, even if it just seems really small right now. And that's going to bolster your team's enthusiasm to reach that finish line. So do not get away from a communication cadence. It is so important to your project.
Amrit Palaria
The technology in your archive is going to play a big role in its long-term use and benefit. It can also heavily influence the operating and maintenance costs in the long run. So what are some of the factors you would want to consider? One is, how easy is a system to use by the clinicians or other users in their day-to-day workflow? Is it well-integrated with your EHR via the OAuth2 or SMART mechanisms? Or is it going to disrupt the user's flow, create discomfort, and cause delays in patient care and treatment? In healthcare, securing sensitive patient information in compliance with HIPAA is critically important. Alyssa talked about police policies earlier. As custodians of patient data, you would need to determine data security policies. Whom all would you allow access to a patient's data? And to what extent? And would your archival system allow for secure access, such as controlling and limiting access to a patient's data based on the user's role? Would you want your archival vendor to be SOC-to-compliant or high-trust accredited? Two major aspects of archived data that can help with compliance are provenance and auditing. Does the archival system record and maintain data provenance, and does it audit user activity? And beyond security, does your archive have the functionalities and the ability to comply with other laws, such as the CURES Act? An archive's primary job is to store data. So you would need to decide on the method of storage and maintenance of this data. Now, a cloud-based system can bring significant cost savings, along with enhanced reliability over an on-premise solution. And most cloud systems are compliant with security standards, such as HIPAA. So you would need to check if your archival system would allow for easy cloud deployment. Is your archive going to be cloud-agnostic and allow you freedom of choice in determining your cloud service provider, or would it require you to go for specific providers? Now, let's talk about the data itself a bit. Remember, you're going to be bringing data from multiple systems, which implies differing data models, inconsistent structures, and various formats. How easily can you use this inconsistent data? Can you drive analytics out of this data? How readily can you report on or find some information in this data when needed? One solution is to consider an archive system with a common data model for all data, regardless of the source. But then, which model? What would be the determining factors? Some to consider might be ease-of-use, reportability, storage requirements, speed of access, and compliance with federal or state policies. You would need to ensure proper usability of this data in terms of its reportability and other aspects. Is the extracted data granular or discrete enough? Is it formatted in the right way, such that it is compatible with the reporting mechanisms or other applications it may need to be used with? Are the right terminology or code sets being used? Data consistency and formatting are two important aspects of good data, but accuracy and completeness of data are fundamental to data quality. How many of us have not heard of an incident where patient safety was compromised owing to a patient matching issue or similar? Both missing data and incorrect or misleading data can have disastrous fallout. One reason for poor quality of the extracted data could be that the data is present at some location other than the expected one in the source database. An archival vendor can help mitigate the risk of poor quality by executing certain data quality checks on the extracted data. And nothing beats testing and data validation to not only ensure all aspects of data quality, but also bring organizational confidence in the extracted data. And I'll be talking more about this in a bit.
Alyssa Dennis
And you know, other features to consider when you're talking about technology is what can your archived product do? And so maybe these are some of these conversations that you would have even before you chose a product. Ultimately, if you have the option of assembling your team members before you have even identified who your vendor is going to be, those perspectives are going to be invaluable for determining some of these features. So just a couple of examples to question is the role-based access. The product that you're looking at or you've agreed to go with, how robust is that? And do you need that robustness? Because that's another thing. Remember, we're talking about some cost savings here as well. So just because a vendor offers a feature, if it is not right for your organization, that might be a consideration point that you should look at. So you don't have to change your ways to meet a product, but the product should really support the ways of your organization. So role-based access, do you have the option of being granular and ensuring that only certain users have access to certain items in the archive? Or is it acceptable that anybody that has access to the archive can see anything? That's a good question to ask. And again, that's where the ‘break the glass’ functionality comes in. You know, some archive products do have that feature where you can even put an extra layer of security over top of that, ensuring that even though the users have access to the system, if they want to get access to these certain document types, especially helpful if you have behavioral health, substance use documents, maybe they have to go through yet another check just so you can maintain and manage that access. Or there's even some other functionality, such as document edition or upload. So again, in my HIM background, I have experienced this. I think if you pull a lot of HIM professionals, they probably would agree. But I tell you, it's a law of the universe that as soon as you sunset an application, within a certain amount of time, you are going to have somebody who shows up in your HIM department with a sheet of paper, a box of papers, a truckload of papers, and says, hey, these documents were supposed to be scanned into that system I don't have access to anymore. What do we do with them now? Well, does your archive product support that edition of those documents? Is that something where you have the option of scanning or uploading directly into the archive where they should have gone in the first place? Or is it an organizational decision to decide to put those documents in your Document Management System? Or do you have another plan in place? So something to think about. And then finally - Release of Information. That one is very, very important. And I'm not saying that just from an HIM perspective, but you have worked so hard to put all of your healthcare documentation in a secure, safe, and archival product. But how do you get it back out? And I'm not just talking for the use of some of your other users, you know, the clinicians and the patient care representatives, but I'm talking for the patient themselves, the patient representatives, attorneys, insurance companies, compliance reviews. So definitely be thinking about how robust of a Release of Information function you need to have. And again, this is where your HIM team is really going to be able to help guide you because depending upon the information you archive, they could tell you that, oh, yes, we have to go into that source system three, four, five, six times a week. Maybe that means you need more robust functionality. On the flip side, if they're telling you that, oh, no, we never reference that information, maybe you can get away with something that's a little less robust. Again, it's entirely an organizational-level decision, but it is something to think about.
Amrit Palaria
So earlier, I talked about data quality. The most useful way to ensure data quality is to carry out sufficient testing and data validation, which is why proper testing and validation are supercritical to the success of an archival product. Testing and validation may need to be completed at numerous times on numerous levels. What I mean by that, for example, is that your vendor should carry out preliminary testing of their own. They should have verified the completeness and the accuracy of the converted data. And even in this process, they are likely going to involve your legacy system experts. But then, at least a good representative subset of the converted data needs to be verified and also validated by the right stakeholders on your end. Identify these stakeholders early on, perhaps during the project kickoff itself. Remember, archived data serves multiple purposes. So you need all the right people to be involved, your HIM, your clinicians, your legal team. Identify the objectives of validation and outline these expectations. These could be, has the right data and a sufficient quantity of data been archived? Is the data complete? Is it accurate? Is it easily accessible in the right ways? Does it serve the patient care, legal, and HIM needs? Is it compliant with federal and state laws and regulations? And what about the product itself? Is it easy for the users to handle? Does it blend well with their workflows? Does it provide good performance? Is it security-compliant? And remember, validation can be a tedious and complicated process. So seek a vendor who can help you provide a structure to it. Prepare a testing script, schedule testing sessions, document findings, and develop a system to report, and then fix the issues.
Alyssa Dennis
And probably most importantly, know when to stop. It is so easy and honestly comforting to get stuck in testing purgatory. Because I tell you, you're always going to find one more bug. It's inevitable. But you need to set some type of threshold of when that testing is done. Is it going to be a timeline where you just simply allow yourselves eight weeks, three weeks, you know, two months, what have you, set a timeline? And at that point, you're done. The testing is over with. Or are you going to set more of a specific threshold? For instance, if you utilize the scripts and some of the worksheets and the structured process that Amrit had suggested, you know, if you have that from your vendor, are you able to look at maybe when you are only reporting 5% of bugs of what you're checking? Again, have an end date. Because if you say you're going to test until it's perfect, that is never ever going to happen, and you will be testing forever. So you do need to have a stopping point.
So once you have stopped your testing and you're thinking, okay, we're ready to go, how do you train your end-users? So again, this is something you do need to identify and think about early on when you're doing your project scoping and your ultimate timeline. But you also have to have some idea of what that format is going to look like. Because that's going to drive how successful the testing is, and also how much timeline you need to provide. Because, for example, if you plan on doing classroom settings, and you expect to have somebody attend in class, face to face, sitting in a room setting for two hours to learn your archive product beginning to end, well, how many of those users need that aspect of training, because that's going to, again, extend your timeline so everybody gets that opportunity? Are you going to be able to simply put a, you know, a webinar or module type training in your learning system for the organization, and allow end-users to progress through it at their own pace? Are you going to send out tip sheets and an email communication? You know, again, depending upon how you decide to do that training, make sure you communicate that to your end users as a whole very, very early on. Because again, if you think back to when we were talking about our team members' responsibilities for the project, every single end user in your organization essentially has a responsibility to the project in the form of completing their training. So again, the sooner that you can notify that end-user, and subsequently their manager, the easier it is going to be to schedule whatever that training looks like. Now, one thing that I found really handy when it comes to that training is almost a hybrid case where you might pick a formal training method like I had outlined just a moment ago, but I also am a big fan of drop-in sessions or lab-type sessions. And what that is, is you have your trainer, whoever that might be, sitting in an available location, whether it's a physical classroom in your organization, maybe it's a Zoom link, and they're just there hanging out. And they are available for end-users who might have a specific question pertaining to their individual workflow. They can go to an expert and get that one-on-one help. That does a lot for gaining a lot of enthusiasm and comfort with the organization. So don't discount that. And speaking of trainers, who's going to be the trainer? Is that something your vendor partner is going to be providing? So that person is going to be training your entire organization? Or is it going to be a train-the-trainer situation? Again, that's going to change your format, so make sure you identify that early on. And then finally, have a conversation about will your organization support penalties for non-compliance in the training aspect? And I'm not talking about end users busting out the checkbook, but more so along the lines of if they do not complete the expectation of training within the timeframe, what kind of a penalty? Is it just the case they don't gain access to the system? That might not seem like much, but if access to the archive product is integral to them doing their day-to-day workflow, that's going to hurt them pretty early on, and that's going to ensure you have a bit more compliance with your training. So again, not a requirement by any means, but it's definitely a good thing to have a conversation about to see what the level of support is you could pose.
All right, so we have gone through the whole thing. We are finally at the point of the system is ready. So again, identify what that means. What is your goalpost for saying that it's ready? Is it simply a case of you have reached that arbitrary date that you set early on, and you've checked all the boxes along the way? That's fine. That's great. I'm glad that everything went smoothly for you. Or is it a case of you have reached X percentage of end-user training, X percentage of bug reports? You know, again, look at what truly completion means to you and your vendor partner. Good conversation to have early on when you're scoping and setting up that initial timeline. Another thing is, when you're setting up that timeline, what kind of contingency plan can you build in to ensure that you meet your project acceptance and closure goal? You know, is that a case where you are able to shave off some pieces of some of the, you know, of your project timeline? So for instance, if your validation testing is just going smooth as can be, you had originally given yourselves eight weeks to get it done. But you know, by the end of six weeks, you're not finding any bugs, things are going well. Well, can you take that two weeks out of the validation testing bucket and move it elsewhere in your project? That's something that you're only going to be able to determine at the time. But as a project leader, that's something to always be thinking about. What can you massage? What can you manipulate to ensure that you don't have that project scramble happening? And then outline a process, and this should be done early on, but at least reiterate it at this point with your vendor partner, of what is the continued support going to look like? What does that future bug reporting look like? Because again, you have tested everything, things look great, there's still going to be bugs that show up. So in that case, how do you report them back to your vendor? How do you get that support to fix those issues? And then do you also have the option for some kind of optimization? You know, once you release that product into the wide world and your end users start utilizing it, they're going to come up with better ways of doing things. So at that point, can you go back to your vendor and suggest changes, or is what you have on the go-live day one, what you will have through the lifecycle of the product? Not a bad thing, but again, something to know early on to make sure that everybody's on the same page. And then finally, make sure that you have that vendor support. Me personally, I feel that you should have that close vendor support through the entire lifecycle of your archive product. But again, make sure that your expectations match up with the reality and the expectations of what the vendor partner is going to support.
We've gone through a lot, and I appreciate everybody's time and attention while we walked through everything. Like Mate had said early on, if you do have any questions, now will be the time to ask. We have some time. Go ahead and put those into the Q&A section, and Amrit and I would love to talk about them.
I know everybody's furiously typing right now, so we'll be patient.
Ah, perfect. Here's a good question. Is there a best practice timeline for purging old health records? Not really. That's probably not the answer you were hoping for, in all honesty. But I don't think there is a best practice timeline. I think it's going to be a best practice for your organization. And I know that's wishy-washy, but it's going to be dependent on your needs within your organization. Not only do you have to look at your state retention policies, which do differ state to state, but you also have to look at, is your organization an education facility? So you need to have some records available. Is there research being done? So there's those pieces internally. If you are looking at starting purging, and thinking, we just got to do it, we have to get our arms around this, I would recommend starting with your deceased population first, because those are the easiest ones where you know their last date of service. There's nothing that's going to slide by you. So at that point, you could look at that date of demise, and then, you know, make sure that it's at least, you know, 20 years in the past, or 10 years in the past, again, based on your state retention requirements. So at least it gives you a starting point.
Oh, how long does a typical implementation take for data archival? Well, again, that depends. It's really going to depend on the scope of data. And Amrit, I'm going to rely on you to fill in some of my blanks here. But I think ultimately, it's going to depend on your legacy source platform, and also how long that platform has been in use. Would you agree with that?
Amrit Palaria
Exactly. And, you know, also, is it an inpatient system, both inpatient, outpatient system, you know, the amount of data changes, system to system? How many systems are you bringing in data from? And, you know, again, the complexity of the systems, the complexity of the data that's present, there are a lot of factors that can play a role here. And obviously, also, how big your team is, right, that's working on it. But this is something that you can always work out with your vendor, and, you know, whatever your timelines are, most likely a vendor is going to accommodate those, right? So...
Alyssa Dennis
Yeah, well, exactly. And I think it's important to have a conversation about your expectations, because you, again, remember, you don't know what you don't know. So if you go into the project with the expectation of - we'll be done in 24 weeks. Have that conversation with your vendor really soon, because the vendor might say, no, no, no, it's not 24 weeks. It's got to be 42 weeks. And again, it's not quite so painful if you have that conversation early on, and you're not laboring under a different preconceived notion.
What is the recommended timeframe for long-term health record storage? Well, again, that one, it really depends on your location. A good basic rule I've seen most common is 10 years past the last date of service. But again, it's going to depend on state. Like for instance, the state I live in, the rule is 10 years past the last date of service, or the age of 21, which is the majority consideration here, whichever timeframe is longer. So again, the best-recommended timeframe is the recommended timeframe for your specific organization based on where you are located. So do some research on state laws, that's going to at least get you started in the right direction.
All right, Amrit, this one's for you. Is there a best practice for data migration? Is it a hard cut over or, you know, limited records, eating the elephant a bite at a time?
Amrit Palaria
So it really depends on the technology you're using partly. So if you're using like a parallel platform, you can probably pull a number of records at one time, and it's faster. And you know, again, the limitation, how much can you do at a time really depends on how complex a system you have employed. So if you have more nodes, if you have more, and you know, also depends on the complexity of the data, and you know, the model you're using, which data model are using, that will play a role as well. So again, I mean, there's no real one answer to this. It really depends on your implementation, on your technology, on your data model, you know, and then on, of course, on, again, how many nodes have you employed, and so on. So how much resources do you have, that also plays a role here. You have a personal preference, like if you could control the price, like what would be your preference to do a little bit at a time or all at once? So a little bit at a time, because, you know, there's always, if something fails, right, then you do have, you know, it's easy to track an issue if you're doing it in small pieces than if you're taking the full big bite. So you never know where the problem happened. It's easier to track an issue if it's in smaller pieces. No, that makes good sense. That makes good sense. All right. Any questions?
All right. Well, you know, like Mate said early on, this presentation has been recorded, and it is going to be sent to every attendee after the fact. So if, you know, be on the lookout for that email. And if you do have any questions that you didn't think of until after the fact, or you think about even a couple of days from now, feel free to respond to that email with your question. And then Amrit and I can certainly go ahead and answer you offline. So no worries there.
And I think I saw one more. Oh, yep. One more question. And then I think we'll wrap. Wouldn't the archival vendor handle all of the staff training? It depends, honestly. Again, I think that's a good conversation, really circling back to what I said about expectations early on. If that is your expectation as the vendor's client, that that vendor should be doing all of the training, talk about that early on, work that into part of the project scope, make it happen. Otherwise, there might be a case where the vendor would, again, train your trainers to then empower your trainers at your organization to be able to train new users down the line. Because again, remember, the vendor may only be available for the training at the actual go-live. So what do you do with any of the new hires that come into your organization who need access? Is that where you refer them back to the vendor? Or is that where the new hire's manager would take over the training or your own training department? Again, really no right or wrong answer, but it's just a list of questions to make sure that you pin down early on. So again, there's no surprises at the end.
All right. So like I said, thank you so much for taking the time to be with us today. We really, really appreciate your presence as well as your engagement. So looking ahead, like I said, if you have any questions, feel free to reach out to us via email. We're here to help. And regardless of what your archive product and your project is looking like, we know you're going to do great. Take care, everyone. Bye-bye.
