|
|
| Line 2: |
Line 2: |
|
| |
|
| ==Episode 2== [[Episode2|Multiple Sign-ons]] | | ==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://en.wikipedia.org/wiki/Active_Directory#Integrating_Unix_into_A...
| |
|
| |
| 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.
| |
