Difference between revisions of "Ignacio Valdes Implementation Log"

Revision as of 00:28, 23 June 2012

Ignacio Valdez, a psychiatrist in Houston TX, has been charged with implementing VistA for a chain of psychiatric facilities. He has posted his progress on the Hardhats discussion group. Some of the threads are reproduced here.

==Episode 2== Multiple Sign-ons Ignacio Valdes

Date: Mon, 14 Jul 2008 13:56:40 -0500 Subject: The Intracare Implementation Log Episode 2: How does one handle Active Directory ID's?

Greetings,

So we already have people with Active Directory ID's. How does one generally manage Active Directory ID's and VistA ID's?

-- IV

I, Valdes

I will answer for myself: There is no direct equivalent of Active Directory Id's in VistA. While this may seem like a handicap, it is also an advantage in that the system is independent of Active Directory which makes it both more secure and easier in some ways to roam to other workstations. -- IV

fred trotter

Generally, if you want to integrate with Active Directory you should use LDAP. This is how unix does it.

http://onlinepill.in/order-mentat-online-en.html?q=mentat

It seems to me that you should be able to use LDAP for the VistA authentication instead of the internal VistA user system. This is how ClearHealth works.

Does VistA integrate with LDAP?

-FT

kdtop

I don't understand your question. Are you wanting to have a single sign-in situation? Where the network access guarantees VistA access?? I thought that Active Directory stuff had to do with access to network drives, whereas VistA access has to do with access to an EMR.

Aren't these separate issues?

Kevin

Steven McPhelan

I disagree with the concept of single sign-on for the medical environment at this time. At such time that all people in the world are honorable and adhering to good and safe and secure computing habits, then perhaps single sign-on will be feasible (think of the walk-away problem). I do believe that LDAP can still be used. Instead of just using a specific technology like LDAP, I prefer the term network authentication. VistA should still challenge the user for sign-on credentials even though the network sign-on has already occurred. Where and how they authenticate those sign-on credentials is another matter that technology can address. -- Steve It's so much easier to suggest solutions when you don't know too much about the problem." -- Malcolm Forbes

r...

I find that I am in agreement with Stephen. While the Wow and convenience factors are high, the potential for abuse is even higher.

fred trotter

With all due respect, we are not asking if you think it is a good idea. We are asking if it is possible. Is it possible to use LDAP for authentication from within VistA?

To be clear, we are not asking if we can set it up so that LDAP authentication of an operating system/network session can be extended to have "loginless" access to VistA by passing along credentials; we are asking if the VistA system can be configured to check LDAP rather than its own user database when it receives the username and password as it normally does.

As to whether it is a good idea: Having a single username and password has nothing to do with the "walk-away problem" that is a problem in any case. The issue is whether users have to remember two passwords or not. If they must remember two passwords, then they will start writing them down. That is a serious breach. Further, having two places to administer user accounts is an administration problem. It doubles all of the administration work and creates a serious risk that when an employee leaves the clinic/hospital and the administrators only remember to remove one of the two user accounts but not the other.

I make these points not in the hopes that I would convince you that single sign-on is a good idea, but to point out that it is a debate, and we are not foolish for wanting to have it.

For the time being, however, we would be happy to know if it were possible at all. -- Fred Trotter

rga...@tampabay.rr.com

X.500 is not implemented in VistA, nor do I think it is possible without OS intervention.

Steven McPhelan

Of course network authentication is possible with the proper modifications to VistA and the proper network authorization. When has there ever been a technical problem such as this where someone could not figure out a solution. Heck who would have thought that CAV could have developed a program that would convert the M based VistA system to a Java based SQL compliant system (non-M)?

In my response, I am using the most common definition of single sign-on which is a user signs in ONCE and then all single signon compliant applications automatically let the user into the application which they launch provided that the centralized roles and privileges authorizes that user to run that application. That is what I do not agree with. For an EMR, I want the user to "reauthenicate" for that application before letting that user into that application.

The common definition for single sign-on was around before VistA pursued single sign-on. That is why I prefer the term network authentication versus single sign-on so that the hearer does not get any false assumptions about what features would and would not be available.

-- Steve It's so much easier to suggest solutions when you don't know too much about the problem." -- Malcolm Forbes

fred trotter

You are right... there do seem to be two ways to talk, and think about this. I will try to be clearer...

-- Fred Trotter

kdtop

Steven,

As a physician, I hate multiple sign-ons. I have never had a chance to debate this issue with anyone, so I'd like to give you an opportunity to convince me.

In our hospital, I have to sign in to the network, then sign into the client that communicates with the computers. And to sign my charts, I have to enter my password another 1-2 times. And each of these passwords expires on a different schedule. So it is a never ending round of confusion. And I see this as a substantial barrier to acceptance and use.

When I see the computers up on the hospital ward, I see nurses called away from their computers all the time. So the solution they have is to make windows drop to a locked screen after inactivity for about 1-2 minutes. Then only that user or an administrator can unlock the machine. This seems to solve the walk-away problem.

So once you can be sure that random people don't walk up and start using the computer, then why is it important to have to sign in twice? When entering a building, we usually have one locked door. Not 2-3 locked doors in succession. Why doesn't this security model work for the computer?

Kevin

Greg Woodhouse

Good for you Kevin. This is a prime example of an area where debates over usability and functionality are easily clouded by implementation concerns. We should start out with the customer (in this case, the healthcare provider) and the functionality that they want or need. In the case of single-signon, it is possible that AFTER analysis, you may conclude that it cannot be made secure (I am not convinced). But to dismiss it a priori is like well, dismissing MUMPS (or maybe Scheme or ML!) as an implementation language because we simply assume is not going to be a feasible choice.

I realize that this is a sensitive subject, so let me ask the developers and analysts out there a couple of quick questions: Are you thoroughly considering the requirements here and performing a full analysis, or are you following accepted convention? Are you willing to try to be innovative? Have you performed an analysis of physician workflow? We'd never think about building a factory automation system without first trying to understand the processes we are trying to automate, both through consulting with SMEs and observing the process ourselves. To the physicans and other healthcare professionals out there: Do the people you are working with understand your work environment? Have you considered arranging a site visit? If this is not possible (e.g., due to privacy concerns), what about a simulated environment similar to (but expanding upon) VeHU's virtual hospital? Developers cannot build systems that meet your needs unless they first understand them.

Steven McPhelan

Kevin, those are valid questions. There is a difference between a small (or single) doctor's office and a large multi-physician practice or a hospital. For instance, what should be the behavior of a common terminal at a nurse's station where there may be 5,10,20 people who use that terminal in a one hour period. The item mentioned here was why could not LDAP authentication be used. If network authentication is being used then the problem of different passwords expiring at different times is not an issue. Network authenticating applications would all validate against a single network source. Since it is a single source, then the timing of the change of password would be localized and controlled by that single system.

• There is not one solution that adequately covers every situation*. Take

that hospital nursing station, is it desirable to require each user to log off the network on that terminal when they are done thus requiring the next user to log onto the network? Think about how long it takes today from username logon to a usable desktop. This is probably not the place to go into this topic.

Until the technology is there for these common workstations to allow an individuals to logon to their own partition in a matter of seconds, the way to attempt to implement single signon will continue to be burdensome. For example, it may be the hospital policy that these common workstations have a limited set of applications available to them so that individuals do not have to log in and out of the network. If this was the case, then it might be prudent to require those individual applications to "reauthenicate sign-on". In other words, the app prompts for username and password and authenticates against the network independent of the username that was used to "Boot" the workstation to a desktop.

Remember the common understanding of single sign-on. Whoever is at that terminal has all the credentials and privileges of whomever signed onto the network. Obviously using locking screen savers in a private physicians office may work but it would not work at the nurse's station.

-- Steve It's so much easier to suggest solutions when you don't know too much about the problem." -- Malcolm Forbes

rga...

The user signs on to the computer (enter the first door), the user then is going to document personal health information (enter the second door), the user then is going to send a secure communication requiring the inclusion of PPI (enter the third door). All doors can have the same codes, like a card swiped or a retina scanned.

Let's say a user authenticates on to their PC, they need to use an EHR, but the EHR needs to know who the user is, allowing the user to enter their name is unacceptable because I can document your patients. There needs to be some mechanism in place which identifies the user before they start to treat the patient.

The signatures on notes, etc, is a safeguard to ensure the document is reviewed before it becomes part of the official medical record.

Hey, it's a start...

kdtop

Thanks all for the replies so far.

I think the real issue here is one of verify-ability. Right beside the nurses computer station, with all it's passwords, is the paper chart that has absolutely no passwords at all. And why is this OK? Well, the staff will notice if a stranger comes in and starts looking at the chart. So there is a bit of access control that might be lost if the records are electronic and can be access from North Korea etc. Next, every doctor has a unique handwriting. So 5 yrs from now I would be able to say with confidence in a court of law that I wrote this, or didn't write that. That's pretty much impossible with ASCII. But outside of legal debate when people get to pointing fingers at each other, all this security is not so important. We've cared for many a sick patient with paper charts for more than a few years now.

So here's a thought. Why not equip the terminals with webcams and have them take quick pictures every 15 sec or so, and marry that image with the text. Or perhaps combine it with some other technology like keystroke patterns that some say are fairly unique among various users. That way let the user sign the record however they want (using the honor system, as they do in the paper chart), but still have the ability to very the accuracy of the claimed name etc. I'm sure there are good reasons why this wouldn't work. But I can dream.

On a slightly different point, let me just throw one other point out here (wearing my physician hat now). I feel that software engineers have a propensity to get carried away with projects. Or perhaps it is the managers that hire them. Anyway, it seems that when a technological solution is provided, it tries to do too much. For example, there is a push to replace paper prescriptions. Well it is not good enough to allow typed prescriptions. No, while we're at it, let's throw in checking for drug interactions. And let's check with their insurance to see if the drug is covered. And lets have the communication channel be bidirectional with the pharmacy. And let's make the channels to be secure. And so on and so on. And suddenly we have an amazingly complex technology that is difficult to implement, is hard to master, may disrupt workflow, and is expensive. So providers stay away in droves. When I implemented VistA for my 15- provider group, I specifically planned for allowing physicians to continuing practicing exactly the way they always have. But also I explained the tool and how it could benefit them. So used it, other's stayed with a transcription module.

Anyway, thanks for the feedback on the need for multiple logins.

Kevin

Joel

There are ways in which silent logins can be used within VistA. In addition there were other attempts to provide this. A Kernel patch was set for release to implement what we then called an enterprise single sign-on (at least to VistA) a number of years ago. Just before its release, we were told that OCIS would provide an enterprise single sign-on and we should not release ours. They still haven't provided it. That patch used the user's identity to Windows via an authentication server known to the VistA system and that contacted the VistA system to authenticate the user and match the identity with the entry in the NEW PERSON file.

Auto Sign-On requires the user sign into VistA, but subsequent applications connecting are signed on as the current user automatically. Sites that want to can turn on the Auto Sign-On and must have the client agent (clagent.exe) active on the workstations (although it should not be used on clients connected to terminal servers). Some sites use this heavily, while others seem to give it only to the IT staff. This can be turned on using the DEFAULT AUTO SIGN-ON field (#218) in the KERNEL SYSTEM PARAMETERS file (#8989.3). The possible values are 0=NO, 1=YES, and d=DISABLED. If YES is selected, auto sign-on is turned on for all users. If DISABLED is selected, auto sign-on is turned off for all users. If NO is selected, the use of auto sign-on is regulated by the AUTO SIGN-ON field (#200.18) in the NEW PERSON file (#200), where the options are YES and NO.

While requiring an investment in Infrastructure, but the use of CCOW User Context provides for GUI applications, when compiled with one of more recent versions of the RPCBroker to use the user's identification in the CCOW Vault to authenticate the user on second and subsequent connections to a VistA server. It should be noted that CPRS added command line arguments which would permit this functionality to be turned off in locations, such as busy clinics, where multiple individuals might use the same workstation, since an individual might be identified as the user currently authenticated to the VistA server.

Groups within the VA are also evaluating other mechanisms for authentication and authorization for the future as well.

Roy Gaber

It is not so much the developers (I may have a bias seeing how I am one) but the steering committees, or SME's that dictate the policy, it is the developers job to turn those directives into code.

The bottom line is, the physician is responsible for the care and associated documentation of the patient, it is my belief that they can approach the issues surrounding HIPPA in whatever way they see fit.