Epic Integration Upgrades in OnBase

Cailen Myers:
Thank you, everyone for joining the Epic Integration Upgrades in OnBase. A few housekeeping items before we get started. All our webinars are recorded and are made available on our website. All lines will be muted. If you have any questions, please post them in the GoToWebinar question panel, and we will answer them at the end of this webinar. Currently, we have eight 2020 OnBase webinar series going on. All upcoming webinars are listed. If you’ve not already done so, please sign up for the upcoming webinars. If you have any additional webinars you would like to see, please reach out to us here at RPI, and we’d be happy to create those for you.

Just a little bit about myself before we get started. My name is Cailen Myers. I am a Senior Consultant here at RPI. I have over 10 years’ experience of designing, implementing, upgrading, supporting OnBase. I do specialize in healthcare and the EMR and ERP integration. I have quite a few OnBase certifications as well as Epic certifications. And on a more personal note, I am a mom to three Siberian Huskies. I do like baking and scrapbooking in my free time.

Let’s go ahead and get started. Today, I would like to discuss a little bit about the OnBase Epic integration, product licensing and versioning. The main part, of course, preparing for the upgrade. Then, we will do summary and questions. All webinars are solely based…are all RPI webinars. This is not a webinar that was produced or endorsed by Hyland or Epic. This information is of course, current as of March 2020. The advice and content contained within this webinar is educational only and based solely on the experience of us, RPI Consultants.

Let’s go ahead and get started. A little bit about the OnBase Epic integrations. There are so many different products and modules. I thought it’d be best to go through each of them before we get started on the actual upgrade piece.

Integration for Epic MyChart. The integration for Epic MyChart allows organizations to leverage OnBase for storing medical documentation uploaded by patients or guardians through MyChart. Uploaded content is routed and processed using OnBase workflows, giving the administrators and providers the chance to review and selectively add documents to the patients’ medical record. The integration can also give patients access to forms assigned using the Clinical Consents module. Patients or guardians can review and sign patient level forms from the comfort of their homes, using any browser supported by MyChart.

Signature Deficiencies for Epic. Signature Deficiencies for Epic provides the ability to electronically assign and complete deficiencies on documents stored in OnBase. Analysts can view documents and assign deficiencies to physicians and physicians can accept or decline these deficiencies. Signature Deficiencies for Epic automatically routes the documents through the completion process. Signature Deficiencies for Epic integrates seamlessly with the Epic application. Documents stored in OnBase are retrieved directly through the Epic user face. From the Epic Health Information Module, analysts can review scanned documents through the OnBase Viewer to assign deficiencies for missing signatures or missing information. Then from the Epic Inbasket, physicians can retrieve documents and electronically assign deficiencies assigned by the analyst. Signature Deficiencies allow users to open OnBase documents from the Epic application without interactively logging on to OnBase. Analysts and physicians can analyze and complete encounter documents without leaving the Epic interface.

The OnBase Viewer. OnBase segments can be directly accessed through Epic using the OnBase Viewer. Besides offering a rich ActiveX feature, the OnBase Viewer allows users to compare two documents side-by-side and submit documents for corrections. Physicians also can use it to stamp documents sent to their inbox as acknowledged.

The Scan Acquisition Server. The Scan Acquisition Server offers a light scanning solution, allowing users to convert both paper documents and existing electronic files into the electronic documents in OnBase. The Scan Acquisition Server offers several methods of input. You can use TWAIN, Kofax, or ISIS compliant scanners. Definitely are not able to use the PaperStream for these. You can sweep large quantities of existing electronic data files into OnBase without using a scanner. Then you can also send documents directly to the Scan Acquisition Server by printing them through the Hyland Virtual Print Driver.

Front Office Scanning. This is an alternative to the Scan Acquisition Server. The Front Office Scanning integration allows Epic users to scan documents to OnBase through the Epic Front Office Scanning clients. The Front Office Scanning client offers additional features, which would include the ability to mark up documents and capture signatures electronically. Then documents are easily indexed using the information provided by Epic.

Epic Release of Information Integration. The Epic Release of Information Integration allows Epic Hyperspace users to print OnBase documents with supportive file formats using the Release of Information screen. So when your staff is releasing a set of documents, they are able to attach the OnBase documents within that packet to send out for release.

EpicCare Link Integration allows users to view OnBase documents directly from a medical record with an EpicCare Link, PlanLink or EpicWeb. In addition, users can upload documents directly to OnBase.

The Epic Image Retrieval API Integration allows OnBase documents to be displayed in locations previously where only the BLOB images were available, such as Hyperspace and MyChart. Some examples of this is, when you’re in Chart Review, you can see thumb base segments as a preview or thumbnails. You’re able to include them in reports, notes, or In Basket messages using the Image Selector. They can be imported into Epic annotation tools. If you’re looking for a more complete list, I would suggest contacting your Epic support representative for that. There are no ActiveX controls required for this integration. Users can view and open thumbnails of supportive file formats without additional client-side installation.

The Epic Welcome Integration. So, patients who register using the Epic Welcome software kiosk can scan and upload documents directly in OnBase. The documents are archived to specific document types using the patient registration information.

The OnBase Patient Window is a medical records retrieval tool that can provide Epic users access to OnBase records and documents within a web-based interface. The integration is available for OnBase systems that are configured for the OnBase Integration for Epic or Signature Deficiency for Epic. Because it is web-based, you actually can also look at the OnBase Patient Window outside of Epic. But of course, in this instance, we would be looking at it within Epic.

Integration for Epic Canto and Haiku. This provides the ability to integrate both the Epic Canto and Haiku iOS and Android applications with OnBase using the OnBase Mobile Healthcare App application on mobile devices. So, physicians can perform familiar tasks within Epic Canto and Epic Haiku with the added ability of using buttons configured in Epic to launch the OnBase Mobile Healthcare App. When the OnBase Mobile Healthcare App is launched from Epic, physicians can view OnBase documents, complete deficiencies, create forms, take photos all within their mobile device. And of course, using their device camera, if they’re taking photos and all these documents and photos would be attached to the patient’s chart in Epic and OnBase.

So, a little bit about the integration modules. Let’s now talk about some product licensing and versioning. In addition, I do want to discuss a couple items to consider when you are upgrading some of these modules. The Integration for Epic MyChart, all the licensing and the versions that are supported are here on the screen. A couple of things to note that in EP1 or later, you need to make sure that the API URL has PPL at the end of the path. Also, as of OnBase Foundation EP1, the Endpoints MyChart setting in the application server web.config file has to be renamed to Endpoints PPL. Then as of OnBase Foundation EP1 as well, Epic encryption settings must be configured in OnBase configuration. You definitely would want to look into that. Lastly, as of Epic Foundation EP1, the URL query string configured for this integration must include Epic timestamp parameters. Again, please reach out to your Technical Resources for this, any assistance of setting it up, but just some things to consider when you are looking at upgrading.

Signature Deficiencies for Epic. Again, the licensing is on the screen. You definitely want to make sure you have the Signature Deficiency for Epic license. All the Epic versions and OnBase versions are listed here. There’s a of couple things to consider when using the Signature Deficiencies for Epic. As of OnBase 18, there are new setting controls. The sending of HL7 messages to Epic when deficiencies are created or addressed. So, you definitely want to look at those settings, which are available in the HL7 tab in the Medical System settings. Also, as of OnBase 18, Signature Deficiencies for Epic, no longer needs to be configured to send the HL7 messages to Epic in order for the deficiencies to be burned. And as of OnBase 18, if deficiencies are addressed using the Mobile Integration for Epic Canto or Haiku, then the Notify Epic of completed or rejected deficiencies settings must be selected. And the associated HL7 message template and destination must be configured. Again, definitely some things to consider when upgrading, if you do have the Signature Deficiencies for Epic, please take a look at the MRGs or reach out to your support

For the OnBase Viewer, this one’s a little bit easier. You need the Client (Concurrent, Named or Concurrent Client for EMR Integrations), Integration for Epic, and HL7 Listener, and the web server. Again, all the versions are listed here. Most of them are the same for the modules, but there’s a few differences. So each screen it could be different. The only thing really to consider when upgrading with the OnBase Viewer is just make sure you have a backup of the Epic integration config file. It never hurts to have that backed up just in case something goes astray, or you need the original version.

Then for the Scan Acquisition Server, again, you would need one of the clients, the Integration for Epic, HL7 Listener, web server, and you would definitely need a Desktop Document Imaging for each scanning workstation. So you’re going to be scanning, you need a scanning license. The versions that are supported are listed below. Then just a few things to keep in mind for this. If you’re upgrading the Scan Acquisition Server from a version of OnBase prior to OnBase 16, you must update the Acquisitions Server progID in Epic. And then of course, also a good idea to back up that Epic integration config file.

For the Front Office Scanning again, the Clients (Concurrent, Named, Concurrent Client for EMR Integration), Integration for Epic, HL7 Listener, web server, and then you need the Front Office Scanning licenses for each scanning workstation. The versions of Epic and OnBase are listed. Then also, a few things to keep in mind for upgrading the Front Office Scanning is as of OnBase 17 Service Pack 2, the Front Office Scanning Client Consent Epic is service date, effective date, and received date to be used for all documents included in a single upload.

By default, users are prompted to enter these dates when indexing documents. The dates can be disabled using the Epic FOS XML configuration file. So this is definitely something new, the service date, effective date, and received date. Also, as of OnBase 17, the Front Office Scanning client can load a different configuration file when scanning as initiated from registration context. To take advantage of this feature, you must create and configure the new file, so an Epic FOS config.registration.xml. If you do not want to use this feature, then you don’t need to make any configuration changes.

If you’re upgrading the Front Office Scanning integration from a version of OnBase prior to OnBase 16, you must update the Scan Acquisition Server progID in Epic. And then again, please, please, please back up your Epic FOS config.xml. And if you are using the additional file, please update … or I’m sorry, please back up the Epic FOS config.registration.xml. And also, the Epic integration.config files. So a couple of to back up there, if you are using this module.

For the Epic Release of Information. The ROI printer plugin integration is probably what most of you are familiar with hearing this one called as, but a few things to keep in mind here is take note of the current path to the printer’s directory … I’m sorry to the printer’s directory for the OnBase printer plugin file. Then also please back up the OnBase printer plugin.config file.

The EpicCare Link Integration. Again, the licensing and supported modules are there on the screen … or I’m sorry, supported versions. A few things to note here is as of OnBase 16, Epic web.ini file has been replaced by an OnBase Epic web.config file. If you’re upgrading from our version prior to OnBase 16, again, please take note of the settings in Epic web.ini because these will need to be populated in the OnBase Epic web.config file. Also, again, please back up the OnBase Epic web.config file, so you have it for reference.

For your Epic Image Retrieval API Integration, just wanted to note that the domain account used to run the application server … I’m sorry, that the domain account is used to run the application server and is used by this integration. So, after upgrading, configure the application server to run under this account or another account that has the same permissions.

Then for your Epic Welcome Integration, nothing really to note here except for the licensing is a little different because in addition to the licensing that you need for all the other modules, of course, you need workstation clients for Epic Welcome kiosk license, and this is per each kiosk. So however, many Welcome kiosks you have is how many of these workstation client licenses you would need.

For the OnBase Patient Window, again, the licensing is pretty similar. However, you would definitely need the OnBase Patient Window license. If you’re using the document corrections process, you would also need the workflow license. Then a couple of items to know here. These items to note actually would be with both the OnBase Patient Window and if you’re using DocPath. As of OnBase Foundation EP1, Epic encryption settings for OnBase web applications must be configured in the OnBase configuration. Similar to what we mentioned before also, again, as of OnBase Foundation 1, the Epic timestamp parameter must be included in the encrypted query string, which is used to launch an integrated web application.

Then as of OnBase 18, the Epic integration no longer supports RC4 encryption. If you’re upgrading from a version of OnBase prior to OnBase 18, please be sure to update the Epic encryption setting for the web applications integrated with Epic. Again, if you have any questions regarding Epic, please reach out to your Epic support. If you have any questions regarding the OnBase Patient Window, please feel free to reach out to us.

Then lastly, the integration for Epic Canto and Epic Haiku. This is a little bit different. As far as the licensing goes, you still would need the HL7 Listener, and a web server, and an Integration for Epic. But as far as the other licenses, it really depends on what you’re using. If you’re using Epic Canto on an iOS device, then you would need that license. If you’re using Haiku on an iOS device, then you would need a license for that. Then if you’re using Epic Haiku on an Android device, then you would need a license for that. It really is going to depend on the Epic mobile application you’re using and the type of device you’re using. If you’re going to have your physicians do signature deficiencies on these devices, and you would need a license for the Signature Deficiencies for Epic. If you’re going to have any unity forms filled out within these devices, you would need that license. If you would be using any image forms again, you would need that license. And that was it.

Now let’s discuss preparing for an upgrade. The first step when preparing to upgrade is to create the testing scripts. This should really be a joint effort between the analyst and the superusers. It’s best to go through all the OnBase Epic integrated modules that you own and creating the scripts from there. If it’s testing OnBase Patient Window, you know you want a line item to view the documents, you want a line item to make sure that the document is linked to OnBase Patient Window. Same thing with encounter-level documents, patient-level documents, order-level documents. If you’re using the Haiku or Canto integration, are you able to create a form? Are you able to create an image form? Are you able to view documents? Are you able to do the signature deficiencies? Really you just want to review everything in your system that you’re licensed for as far as an OnBase Epic integration and document what you want to test with each one of those. Viewing, retrieving, creating, anything like that. Of course, always, always, always test in your test system first.

Step 2. It is best to confirm your test system is currently working before you do any upgrade. Is your OnBase test system currently working? Does Epic test currently work? Whatever the environment is that you’re planning on upgrading, does it currently work today? And when I mean does it currently work, I mean, can you view your OnBase documents today? Does OnBase Patient Window open correctly today? You want to make sure that you have a fully working system before you upgrade that system. Of course, make sure that your interfaces are running and pointing to the correct systems, make sure your services and app pools are running in your OnBase environments. Like I said, make sure your OnBase documents will open in Epic, make sure they’re linking an Epic, makes sure they’re going to the right places. You just really want to make sure that your test system is running the way you want it to be running right now, so that way when you upgrade it, you know what actually if anything broke from the upgrade versus maybe something that was broken for a while.

Step 3. Now we want to review your test servers and your versions. What version of OnBase are you on? What version of Epic are you on? What versions are you going to? Are they compatible? Do you need to upgrade OnBase for Epic to work? Do you have the right Microsoft .NET Framework, these C++ requirements, your web browsers? A lot of the OnBase application servers are now 64-bit, the newer versions. So, make sure that you have that set up correctly. You just really want to review your servers and your versions to make sure that they’re compatible.

Step 4 is knowing your team. When I say this, you really should know who from Epic, you’re working with, your analyst. If you have a certain HIM group, EpicCare Link group, Resolute, Prelude, whatever Epic analysts are part of this upgrade, you should really know who you need to go to if something’s not working. If the server engineers are part of the upgrade again, know who they are in case you need any assistance, any DBAs. Then of course, the superusers. So, who is using these integrations? Is it physicians? Is it the HIM staff? Know who these people are so that way you can be engaged all at once. You can determine your plans, the timelines, everything all together.

Step 5 is to have a plan. So, when I say, when, where, who, what it’s a little bit more than just four things. We want to know what day are we doing the upgrade? What time are we doing the upgrade? Are we doing the upgrade altogether in our conference room? Are we going on our WebEx? Am I responsible for doing my piece, sending out an email, and then somebody is going to do their piece? Of course, know the team members, but not only the team members who are doing the upgrade, but what team member is doing what for the upgrade? Is one person updating the .NET on the server? Is another person actually upgrading XML file or a .config file? Know who’s responsible for what. Of course, know what test systems are being upgraded. That includes what application servers, what Epic environment, anything that’s being upgraded, definitely know what all is involved. And then what are the steps?

Again, is OnBase going first, which is recommended, and then Epic? Or is it team effort? Is everybody doing it at once? Definitely have a plan in place because that’s the easiest, smoothest way that things will work.

Then you want to prepare your test system. Before even the upgrade, start moving the files to the server you need. If it’s the .NET Framework, if it’s the installers, start making the backups of the config files we talked about. Determine a freeze date. So after, I don’t know, March 20th, nobody is allowed to make any changes in OnBase on Epic. So that way, you know when you are upgrading, nothing was changed because Sally Smith did it instead of the upgrade doing it, which is the same thing. Then you would also want to lock out your users from the system. You don’t want them going in and making any changes as well or adding things or changing anything.

Now finally, it’s time to upgrade your test system. So, go ahead and install those files and definitely document what you did to install them and on what servers. When upgrading both OnBase and Epic, perform the OnBase upgrade before you do the upgrade in your Epic system. When upgrading to a new build of OnBase, also upgrade all the OnBase application servers used by the Epic integration. Upgrading to a new build will not require changes to the OnBase database or other aspects of OnBase environments. Then when upgrading OnBase, use the latest builds available for the new obvious version when possible. But it’s really important to really document what you did to do the upgrade. So that way, when you go to do it in production, you have a guide to follow.

Your upgrade is done, everyone’s done their piece, you’ve done your Epic upgrade, they’ve done …I’m sorry, you’ve done your OnBase upgrade, the other team has done their Epic upgrade. Now it’s time to test your system. It is best to use those scripts, have your OnBase admins go through and test everything. When you’re testing in the scripts, it’s best to note the patients you use, the encounters you use, the orders you use. Put those MRNs on them, put the CSN numbers on there. Include dates of when you tested it. Obviously, note if it passed the test or if it failed. If it failed, note the issue with as much detail as possible. What failed? Something didn’t link, you got an error, you’re unable to view it. What was the actual issue? Then if there is an issue and you are able to resolve it, document what you did to resolve it, document who had helped to resolve it. Was it just you on the OnBase team? Was it an Epic analyst? Was it maybe a DBA? Who helped resolve that issue? And then how they helped to resolve the issue.

Again, these are all really key things to note with as much detail as possible. So that way, when you do your production upgrade, if you run into the same issue, you have it all documented, you know who to go to, and to fix this problem because he fixed it in test. It’s really important to note these types of things. I know sometimes it takes a while, but it will save you in the long run.

Once your OnBase admins have done their testing, everything is working from their point of view, go ahead and have the superusers start testing. They should be using the same testing scripts. It’s best if you could have an analyst there to support them and help them. And for the analyst to actually see what problems they’re having because I think most of us will know that a lot of the end users cannot relay issues as well as probably just having the analyst there to watch. When possible have a WebEx or be there in person to kind of help them go through their testing scripts, to see what happens. Then definitely, get some type of sign off, a signature, an email, something saying that, “Yes, Sally Smith and HIM tested everything and everything’s working perfect.” Of course, if something doesn’t work, we would follow the same steps that were in Step 8, document what’s networking, document who helped fixed it, how it was fixed. Then you would of course, want your superuser to test it again.

Once everything is fully functional in your test system, now you would definitely want to move to your production system. Step 10, we’re going to review the production servers and versions. Similar like we did before in our test system, what OnBase version do we have? What OnBase version do we maybe need to go to? What Epic version are we going to do? Do we need any of the additional requirements? Just make sure your production servers are ready for the upgrade. Hopefully, you should already have this information if your test and production servers are the same, but not everybody keeps them current.

Again, know your team. Maybe with the test system, some other people helped out, but the day of the production upgrade, maybe you have some different analysts that will be there, different engineers. Definitely know who is responsible for the upgrade.

Same thing as before, have your plan, your date, your time, who’s doing what, where they’re doing it, how it’s all gonna work, how you’re going to communicate. Everything we’ve talked about on the test system, you should know it for production as well.

Again, I know these are very repetitive, but Step 13, prepare your production system. Again, move your files to your production servers, move your installers there. Make sure you have your backups of your config files. Definitely, definitely, definitely freeze any build changes. After a certain date, you definitely want to make sure nobody is in your production system, making any configuration changes. Of course, obviously users will need to be in the system, viewing documents and things like that, but we definitely don’t want any build changes being done.

Then Step 14 of course, would be to upgrade your production system. You should be using the install documentation that we captured in our test system, which was Step 7, and really being able to go through that documentation to upgrade your production system.

Well, I promise we’re getting there. We’re almost done. Step 15, same thing. We’re going to test that production system. Before you let your end users back into the system, you should have your OnBase admins and even probably your Epic analyst, depending on what their responsibilities are, to go through your testing script, make sure everything’s working. Again, if you have any issues with something not working, know what the issue is, note how you resolved it, because you’re going to have to do another upgrade again in months or years. It’s always good to have these things documented. Of course, when testing, know what patient you use, what encounters you used. Because you’re going to be asked, well, what patient did you have this problem on? So definitely make sure you have all that wrote down.

Step 16, even though it may say Step 9, which is our last step I promised you, is then let your superusers go in the production system to test everything. So they should be using those test scripts. I know you probably cannot physically be there to help them, but you could definitely have some WebEx or a call center line, a bridge line that they can call in and let you know if everything works successfully or if they’re having a problem, so you can remote in and see what that problem is. Then of course you definitely want sign off on this. So that way, you can release, or I should say, unlock the system, so all your users are able to access it.

I know that was a lot of information. I’m sure you have a lot of questions. I will read through the questions on the question panels. Again, just an overview. Hopefully, it was helpful hearing about all the different OnBase Epic integrations that there. There are tons. So, I know it’s hard knowing what ones to use and what ones are all available. The product licensing, versioning, and even things to consider when upgrading, hopefully added some value. So that way, you know if you are going to start using a module, what license you need for those, and then the steps of course, for the upgrade.

Now, I’m going to read through the questions. Like I said earlier, if you have any Epic-specific questions, please go ahead and reach out to your Epic Technical Resource. But I am happy to answer any OnBase questions for you. Let’s see what we have in our panel. Ryan, hold on, I’m just trying to make my screen a little bit bigger here. Ryan noted that you can use a PaperStream TWAIN driver. Yes. That is correct. You can use the PaperStream TWAIN driver with the SAS. You can’t use PaperStream by itself. Ryan had another question, when you were talking about testing scripts, do you mean testing grids? Most people call them testing scripts. It’s just what you need to do to test the system. People may call it different things, but typically, I hear people referring to it as testing scripts.

Then Ryan’s last question. If you had a client considering switching from SAS to FOS, what are the pros and cons and why would you suggest or not suggest them to consider this switch? Ryan, I think it’s a two-part, to be honest with you. I think it really depends on the customer, what would be best for them. If they use SAS or the Front Office Scanning, FOS, what are they used to today? Does your registration area or your other areas, departments that do the scanning, have they ever used Front Office Scanning? Because then I would definitely just recommend using the integration with the Front Office Scanning because it’s going to be something that’s a little bit more similar and something that they’re already used to. Do you want that streamline scanning with using the SAS? I mean, it really would depend on the organization. I’m not sure I really can tell you one way or the other to go. I think it really would depend on your users, your organization, and how your system’s currently working.

Heather has a question here. We are unable to communicate with an acquisition device. I’m going to assume that is an error message that Heather is receiving. And then Heather wrote, I’m sorry, later on, using the TWAIN driver and it’s hit or miss, sometimes it throws the error and sometimes it doesn’t when scanning. I’ve heard this before as well. A couple of things I would definitely suggest is, depending on if you’re are launching it from Citrix or on a desktop, what TWAIN drivers do you have installed? What type of scanners are you using? Those would be something to definitely look at to see why this is happening. There also is a setting in one of the config files to look at as well. Heather, we could probably talk a little bit more offline about this, but I think we have some different troubleshooting techniques to look at as to why you’re getting some communication errors.

Is high-level scanning possible via FOS? It depends what type of documents you’re doing and where you want them to link to. But if the document type is built in Epic and it is saying to link to Prelude or any of the other Epic screens, you can definitely do the Front Office Scanning through there. I know people who are using Front Office Scanning for encounters, patient-level, order-level, they have some hyperlinks that go directly to just like a DNR section. So, there is definitely a lot of capability between Front Office Scanning and where the documents link in Epic. It’s just probably something you would want to go ahead and reach out to probably us, as well as your Epic analyst to see where the document types are built out and what document type you want to use.

Does anyone have any additional questions? Anything that I may be missed? We will definitely follow back up with you after this webinar. I think though I was able to address all the questions. I’ll keep an eye on the question panel, but just to go through a couple of additional slides, because I know this webinars took a little bit longer than most, so I don’t want to waste too many people’s time. I know everyone has a lot going on right now. RPI does offer free automation assessments. If you would like us to identify any enhancement opportunities for your current solutions, maybe identify opportunities for new solutions or departments, even just do a review of your license and modules that you currently own, we’d be happy to do that for you. Please, just reach out to us if you need any assistance with any of these items.

Always, we have our additional resources on our website. Any upcoming webinars or any previously recorded webinars, you can find on our websites. We do have an OnBase Knowledge Base. Then if you’re looking for some information about the OnBase Professional Services, that is also on our site. Once again, we have the last three 2020 OnBase Webinar Series coming up. If you’ve not signed up a form yet, please feel free to go ahead and do that. If you’re unable to attend them on the day, just know again, they are recorded and will be available afterwards.

Then just a little bit about RPI Consultants. There are over 100 of us, full-time consultants that does include project managers and architects. We are based in Baltimore, Maryland. We do have some additional offices though in Phoenix, Arizona, Tampa, Florida, and Kansas City, Missouri. We have both technical and professional services. We have technical strategy, architects, new installations, upgrades, maybe just you need some assistance with some process analysis, or system design, staff augmentation, or maybe even just project and change management. Those are all services we’d be happy to assist with.

We are a Hyland Authorized Solution Provider, so we are able to provide service and licenses for Perceptive Content, Enterprise Search, Brainware, and OnBase by Hyland. We have tons of industry and solution experts. So, in accounts payable, human resources, student transcripts and applications, of course, healthcare, manufacturing, you name it. We have a lot of people on staff here who are willing to help each other out and of course, help you out. So please, feel free to reach out to us.

That was the end of the slides today. I appreciate everybody’s time for joining. We will definitely reach back out to you. If you have any questions, feel free to reach out to us. Thank you and have a great day.