|
|
| 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.
| |
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.
