Transcript:

Keith:
Good afternoon everyone, this is Keith Wayland from RPI Consultants, I wanna thank you for taking the time to attend today’s webinar on Perceptive Content, departmental security, woo hoo! With us, presenting today, we have two very talented consultants, Mr. John Marney, Mr. Jeff Jones, straight from Kansas City live in Tampa. Without further ado, I give you John and Jeff.

John:
Yay. All right, thank you Keith, as he said, we are going to be discussing the department security and perceptive content. This is new as of version 7.0 and has not been taken advantage of by a lot of people yet, so we hope you can learn something here today.

A little bit about RPI, well first, let’s start with us, My name’s John Marney like Keith said, I have been working with Perceptive products for about six or seven years and I’ve been with RPI for around three, and this is my colleague.

Jeff:
Yeah, hi, my name is Jeff Jones, I’ve been working with image now Perceptive Content for seven or eight years now. I’ve been with RPI for about four years.

John:
Great. Apologies, this first part will be a little repetitious for those who dialed into last hour’s webinar on file conversion component, but bear with us and we’ll get through this. RPI has been working with Perceptive products for around 15 years, our team, the imaging team, is approximately 15 members, mostly based in Kansas City. The remainder of the company, RPI, focuses on Lawson consulting services. That’s approximately 60 people. We have offices all over the US, people all over the US, but we are focused primarily in Baltimore, Tampa and Kansas City.

What does the imaging team do and what can we do for you? Well, we do a lot. We do a lot of eForm and iScript development, workflow designs and redesigns. Right now, as I’m sure, many of you have seen or are getting ready to see, we’re doing quite a few upgrades as the push for 715 is underway. We do a lot of health checks, security audits, migrations and system consolidations, and we do a lot with clinical and HL7 integration.

What is departmental security? Well, in short, as an overview, it is splitting the owner and the manager roles that exist previously into separate roles. The owner will now be called Perceptive Manager and the manager is now called Department Manager. This allows for segregating entire portions of the system from each other and in different physical departments, so the entire system configurations are siloed up and down. So you can have your back office or even more so that you could have an accounts payable department that has its own drawers, workflows, views, users, groups, that are completely and wholly septate and managed separately from your clinical or patient records.

Jeff:
Yeah, so to elaborate a little bit more on what John just spoke about, so prior to 7.0, you really kinda had one super account, which was the, Image Now owner account. That was specified at the time of an installation. The owner account had pretty much every possible administrative permission across image now from workflow, users, you name it, you could do it with the owner account. The owner could promote managers and the managers had all the same permissions as the owner with the exception of the ability to create or promote users to managers.

In the new version, what they’ve done is they’ve kinda gotten away from the owner account as it was so when you upgrade to 7.1, your owner account will become the Perceptive Manager. The Perceptive Manager can create departments and add users to the Department Manager role. I cannot be assigned as the Department Manager. I should rephrase that, cannot assign itself as the Department Manager, but if you can have multiple Perceptive Managers and they can effectively assign another Perceptive Manager as a Department Manager, not to be too confusing.

The Department Managers are pretty much like they were prior, only they are specific to the department that they’re assigned. So as departments are broken out, you can assign one Department Manager across all departments or you can assign specific Department Managers to each department. Department Managers cannot create users and they cannot promote other users to manager.

John:
Yup.

Jeff:
Yeah, pretty much.

John:
All right.

Jeff:
We kinda already talked about this a little bit in the last slide, but the new roles do allow separation and a solution based configuration versus application based configuration. So the Department Manager would be considered the solution based, handling workflows, views, learn modes, et cetera and the Perceptive Manager is more application based. Handles allocation of licenses across departments, creating, promoting users, creating departments and then diagnostics.

Now once a Department Manager’s assigned to a specific department, they cannot see any other department’s permissions, workflows, anything, unless given permission by the owner, by being assigned to that department. This allows for the IT administration and department separation. IN each department, in the next slide, you’ll see your Department Managers still have full administrative rights of Perceptive content, but like I said, only over the department they account as assigned.

Let’s go to the next one and we’ll talk a little bit more about that. As you’ll see here on the left, the Perceptive Manager has access over the cross departmental settings. That’s the first thing you’ll see new in 7.1.

The cross departmental settings just contains your auditing settings departments where you would create a new department, diagnostics such as client performance, server information, and then here’s where they’ve put the sessions as well, so you can actually go in here and if you have a hung user session or something, you can actually go in here and disconnect that user through the diagnostics area. This is where you would set up Envoy services if you’re licensed for Envoy, new groups outside of the departmental level and license distribution can be done here. System management such as migrating from, let’s say you wanna migrate from prod to test to replicate, that can be done all through here. Creating new users in system wide views can be done in here.

Where on the right, the Department Managers, as you’ll see now, is you have a dropdown, and if you’ve created new departments, you will see that department there that you have access to, or that as an administrator, that you have access to. And this is where you would see all your typical permissions, folder types, your workflow, users, et cetera that are specific to that department that the Department Manager administrates.

John:
To tie this into the last slide where we talk about solution based configuration versus application based configuration, on the left with the Perceptive Manager, you’ll see the application based configuration, everything to do with administering the application on the server, and on the right you will see the solution based configuration, everything that you would expect the manager to be able to do as far as administering their department.

Jeff:
Right.

John:
I think we have a question that we wanna work in?

Moderator:
Yeah, we have a question that ties right in with what you’re discussing: can Department Managers create/modify views?

John:
Yes.

Jeff:
Yup.

John:
And what might be prompting that question is you’ll see views listed on the Perceptive Manager side here, so at the very bottom, and what those are are the default views for tasks I believe and maybe folders as well.

Jeff:
Yeah, I believe you’re right.

John:
On the right, the department can still create their own views for document searches, et cetera. Absolutely.

Okay, so next slide.

Jeff:
Security, again, we’re kinda reiterating a little bit, so what this does is it secures department configuration and information. It just kinda silos everything into its own specific department. It’s user friendly so that department administrators could only see relevant business units in management console. As I said before, if you have someone assigned to administrate HR, they’re not gonna see the payroll department or the AP department or any other department except for what they have access to.

The license management, and this can be a big one ’cause this allows you to allocate licenses across departments, so if you have 1000 total client licenses, you can allocate chunks of those to each department. So what does that help with? Budgeting.

John:
Right. Yeah, if you have a department who has a need for more users and they spend the money to buy the license for addition seats, then you could allocate those seats specifically to those users so they aren’t used by other departments.

Jeff:
Right. And then so in sharing, there’s a lot of times and a lot of needs for across departmental sharing. And even though these departments are siloed, you can actually share workflow, processes, drawers, et cetera, between departments. Now this is something that if you do go with this, you do wanna plan out because it’s very difficult to undo sharing once something’s been shared.

John:
Right, in fact it gives you a prompt to say that once you share something, it can’t be undone. And a note on sharing, so any uniquely named items in the system still have to be uniquely named, so if you have a custom property in one department that says first name, you can’t have a custom property in another department that also says first name, however, if that custom property is shared to the new department that needs it, it can use it and can be assigned to document types.

Moderator:
I might interrupt with one more quick question.

John:
Sure.

Moderator:
Can one and the same Department Manager be assigned to multiple departments?

Jeff:
Yes. Yeah, so if you’re the Department Manager over HR, and we will show kind of an overview, high level of how you’ve assigned Department Managers, but the answer is yes you can assign one Department Manager over multiple departments, which effectively would give you kinda the same security layout, if you will, of the pre 6.0 or 7.1 versions, right?

John:
Yup. And yeah, so you can have multiple managers per department and multiple departments per manager and whatever relationship that you want to set up.

All right, so why would you use departments? Well, it’s definitely not going to be for everybody and every use case. So we wanted to lay out what might prompt you to go down this path. Probably the number one reason is going to be to keep sensitive data as protected as possible. Probably the most important and the most used case is going to be clinical healthcare where patient data is stored versus any other use of the system by that health organization. So we have many clients who are storing patent data as well as accounts payable, human resources, anything that you might store. So using departments, we can now segregate entirely, not just the documents from each other so that users can’t see them, but we can segregate them so that the administrators can’t see these sensitive documents including the Perceptive Manager, previously known as owner, and this has been a pain point for our clients in the past that the IT role, owner account, now Perceptive Manager, has access to all these documents and now you don’t have to give that to them.

Yes, so we have another question we’re gonna work in here?

Moderator:
Yeah, so it definitely pertains to what you’re describing. The question is if our organization handles most of the administration centrally, are there still benefits to using departments? If so, please describe.

John:
Yeah. In fact, I’m gonna talk about a few of those right here. But there definitely is. Even if you have one person who is right now doing everything, which is the case for a lot of Image Now clients, there’s still some benefits. Now you may decide you don’t wanna do it, and that’s fine, but this will give you the power to make that decision.

One of those reasons why you might want to is to reduce the need to micromanage security. Let’s say you have a power user in your accounts payable department, who, and maybe it’s an AP manager or something, and you want to give them the ability to do more, create views, you trust them not to go into the system and wipe everything out, so you would like to give them manager capability over that department, but you don’t wanna give it to everything else ’cause you don’t trust them to not go wipe out data or something somewhere else. This would allow you to quickly, so that you don’t have to manage all their individual management permissions. This would give you the ability to just promote them to a Department Manager and not worry about them affecting other departments.
Another reason is also because it can allow for multiple administrators without the possibility of role conflict, so if you do have this scenario where you have more than one manager, it can prevent people from accidentally trying to work on the same thing at the same time and also sort of narrow down their duties maybe to be more focused, but probably the biggest reason why a single overall administrator would probably want to implement departments is if you have a very large implementation, so let’s say you have, and we’ve seen this 50 different workflow processes, and you’d like to organize those a little better so that every time you log in, you don’t have to filter through everything you see.

Maybe you have 100 views, maybe you have 500 drawers. This would allow you to organize them by department and that just helps you organize your work a little better so that you’re not having to sift through giant lists every time you log in.

Okay. Just some considerations that should you decide to go forward with departments: when you upgrade from version 6.x, what’s going to happen is everything that you have currently is going to be created inside of a default department. The previous owner accounts can be the default Department Manager, but that can be undone by assigning a new Department Manager and removing them. It’s going to contain everything that existed previously, so all of your drawers, doc types, workflows, you can then use the, if you wanted to create a new department, there’s a department transfer utility that works a lot like the existing migrate utility that can be used to transfer entire configuration sets from the default department into the new department. And it’s really … I’ve used it in the past, it’s fairly seamless and it does a lot of dependency checking to make sure that if you’re migrating, routing rules, you’re pulling over all the necessary custom properties and things like that.

Okay, just a couple best practices, going through it, if you’re going to use the department set up extensively, the best practice is to only use the default department for commonly shared items. That would be things like in Mac or file conversion component. You might find that putting any intelligent capture workflows inside of the default department is good as well, if it’s used by multiple departments.

And as Jeff had touched on earlier, it’s really good to, or really important to properly plan and design what your future state is going to look like because really the simple fact that once you’ve shared something between departments, it can’t be undone, that might not be the end of the world because you can still control security based on what you’ve shared, but you don’t wanna do it unnecessarily if you can help it.

Now we’re gonna walk through just a high level way that we would go through implementing department security.

Jeff:
Right, so implementing departments as you’ll see here, we’re in the cross departmental setting, so as the Perceptive Manager, you can create a new department. So you’ll see here, under custom we have departments, and then you can select under new department give it a name, label and description, just click okay, and then you’ve effectively created a new department, it’s really quite simple. And then from there, you can go to the next tab and assign your Department Managers and this is how you would do it whether you have … You’re doing a new implementation or if maybe you’re already using departments to some degree and you wanna give access to a new manager across multiple departments, you just come in here, add them as you would, any user to security.

John:
Yeah, and right off the bat, this will be likely a manager that already existed in 6.x.

Jeff:
Now, if you wanna move exiting pieces of your solution to a new department, you’d just, again, log in as the default Department Manager, and you use that migration utility, the department transfer migration utility that John discussed in a previous slide.

Now, if you’re building a new process, you’re pretty much done, you’re ready for the Department Manager to log in and proceed with building out your workflows, drawers, and doc types.

John:
But in our scenario, we’re gonna continue with a couple more slides walking through what it would be like to migrate from the default department into a new department.

Jeff:
Yeah, so next you wanna select a destination department and what you wanna include in your transfer.

John:
And this is a screenshot here of the department transfer utility that was shown on the previous slide.

Jeff:
Right, and so some of the items that might be included in that transfer are drawers, doc types, whole workflow processes, just about everything you can think of that would go along with the application plans.

John:
Yup, forms.

Jeff:
You name it.

John:
Custom properties.

Jeff:
Yeah.

John:
Anything really as far as configuration.

Jeff:
Now, in any transfer, well, this is a little different than the migration, so you’re gonna pretty much have everything you need here. I will mention in some migrations, there might be some need to rebuild small items, but in most cases with department transfer I think, you’re gonna get this full spectrum of what needs to be transferred over.

John:
Yup.

Jeff:
Next, the Department Manager of the target department must then import the package and share any items such as your custom properties, drawers, to be used by the other departments.

John:
Yeah, and that sharing can lightly wait until you’re really sure that the other department needs it.

Jeff:
Right.

John:
Another department that you aren’t managing requires the ability to route a document based on a custom property, well, that custom property needs to be shared.

Jeff:
Right, and while this is a very high level overview of creating a department and assigning a Department Manager, bear in mind that this can be pretty intensive and you definitely wanna, as we mentioned before, it takes some considerations in the design layout and do this in your test environment first. Make sure everything works after the transfer.

John:
Absolutely. Yeah, okay. I think that’s pretty much our overview of the implementation of departments, we’re ready to take any additional questions that you might have.

Moderator:
Yeah, we have a couple of additional questions. One is “Can you give a power user some permissions but not all? For instance, give them views but not workflow?”

Jeff:
Yes, you can, actually, the permission still worked essentially the same as prior to 7.1, the difference is there’s just separated out per department, so if you’re, in your HR department, and you have a user just like you did before, that you wanna give specific rights to, you can go in and do that.

John:
Yeah, and all the managed permissions that existed previously in 6.x still exist, so you can still assign one user the ability to manage views, departments just make it easier to quickly assign wholesale management permissions.

Moderator:
And then, if a custom property is shared, can a department rename it?

John:
That’s a good question, so anything that is shared to your department, I guess let me restate this; things can only be modified in the department that it originally came from, and in fact, if something’s shared to another department, those departments can’t even see it, so the only time you can see it is if you go to build a configuration around it, and I’ll use the example I have been, like a routing rule. If I am in the HR department and I’ve had a first name shared to me by the accounts payable department, I won’t see first name in the custom property’s list, but if I go to a doc type and I go to the custom properties list, I will see that it’s available to assign to that document type. I’ll also see it if I go to build a routing rule to route based on that first name custom property.

Keith:
All right, looks like that’s all the questions we have for today. I wanna thank Mr. John Marney, Mr. Jeff Jones, excellent presentation. I wanna thank all of you for attending, I hope you found it informative. Hope to see you next time. Thanks.