Ignacio Valdes Implementation Log

2012-06-23T00:28:57Z

Puwok2008PTZxg:

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== [[Episode2|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.

VistApedia - User contributions [en]

Ignacio Valdes Implementation Log