Ignacio Valdes Implementation Log/Episode2 - Revision history

DavidWhitten: DavidWhitten moved page Episode2 to Ignacio Valdes Implementation Log/Episode2

2020-11-13T04:29:51Z

DavidWhitten moved page Episode2 to Ignacio Valdes Implementation Log/Episode2

← Older revision	Revision as of 04:29, 13 November 2020
(No difference)

NeilArmstrong: Added a glossary link to Debate~

2013-02-22T16:13:23Z

Added a glossary link to Debate~

NeilArmstrong: Added a glossary link to Authorization~

2012-08-04T08:47:55Z

Added a glossary link to Authorization~

← Older revision		Revision as of 08:47, 4 August 2012
Line 112:		Line 112:

	Of course network authentication is possible with the proper modifications		Of course network authentication is possible with the proper modifications
	to VistA and the proper network authorization. When has there ever been a		to VistA and the proper network [[authorization~\|Authorization]]. When has there ever been a
	technical problem such as this where someone could not figure out 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		solution. Heck who would have thought that CAV could have developed a
Line 348:		Line 348:

	Groups within the VA are also evaluating other mechanisms for		Groups within the VA are also evaluating other mechanisms for
	authentication and authorization for the future as well.		authentication and [[authorization~\|Authorization]] for the future as well.

	Roy Gaber		Roy Gaber

NeilArmstrong: Added glossary link to Record~

2012-03-21T19:13:12Z

Added glossary link to Record~

NeilArmstrong: Added glossary link to Application~

2012-02-22T15:01:15Z

Added glossary link to Application~

DavidWhitten: /* The Intracare Implementation Log (Back to Episode 1) (Back to Log Homepage) (On to Episode 3) */

2009-05-08T19:51:15Z

The Intracare Implementation Log (Back to Episode 1) (Back to Log Homepage) (On to Episode 3)

← Older revision		Revision as of 19:51, 8 May 2009
Line 1:		Line 1:
	==The Intracare Implementation Log [[Episode 1\|(Back to Episode 1)]] [[Intracare Implementation Log\|(Back to Log Homepage)]] [[Episode3\|(On to Episode 3)]]==		==The Intracare Implementation Log [[Episode 1\|(Back to Episode 1)]] [[Intracare Implementation Log\|(Back to Log Homepage)]] [[Episode3\|(On to Episode 3)]]==
			[[Category:Intracare Implementation Log]]

	==Multiple sign-ons==		==Multiple sign-ons==
	Ignacio Valdes		Ignacio Valdes

Ssw0213: Navigation Links

2009-05-07T16:21:59Z

Navigation Links

← Older revision		Revision as of 16:21, 7 May 2009
Line 1:		Line 1:
	==The Intracare Implementation Log [[Intracare Implementation Log\|(Back to Log Homepage)]]==		==The Intracare Implementation Log [[Episode 1\|(Back to Episode 1)]] [[Intracare Implementation Log\|(Back to Log Homepage)]] [[Episode3\|(On to Episode 3)]]==
	==Multiple sign-ons==		==Multiple sign-ons==
	Ignacio Valdes		Ignacio Valdes
Line 358:		Line 358:
	issues surrounding HIPPA in whatever way they see fit.		issues surrounding HIPPA in whatever way they see fit.

	[[Intracare Implementation Log\|~~Back to~~ Log Homepage]]		[[Episode 1\|Episode 1]] [[Intracare Implementation Log\|Log Homepage]] [[Episode3\|Episode 3]]

Ssw0213 at 17:21, 5 May 2009

2009-05-05T17:21:47Z

← Older revision		Revision as of 17:21, 5 May 2009
Line 1:		Line 1:
	==~~Multiple sign-ons==~~ [[Intracare Implementation Log\|Back to Log Homepage]]		==The Intracare Implementation Log [[Intracare Implementation Log\|(Back to Log Homepage)]]==
			==Multiple sign-ons==
	Ignacio Valdes		Ignacio Valdes

Ssw0213 at 16:54, 5 May 2009

2009-05-05T16:54:56Z

← Older revision		Revision as of 16:54, 5 May 2009
Line 1:		Line 1:
	==Multiple sign-ons==		==Multiple sign-ons== [[Intracare Implementation Log\|Back to Log Homepage]]
	Ignacio Valdes		Ignacio Valdes

Line 356:		Line 356:
	documentation of the patient, it is my belief that they can approach the		documentation of the patient, it is my belief that they can approach the
	issues surrounding HIPPA in whatever way they see fit.		issues surrounding HIPPA in whatever way they see fit.

			[[Intracare Implementation Log\|Back to Log Homepage]]

Ssw0213 at 21:30, 9 April 2009

2009-04-09T21:30:16Z

← Older revision		Revision as of 21:30, 9 April 2009
Line 1:		Line 1:
	==Multiple sign-~~ins~~==		==Multiple sign-ons==
	Ignacio Valdes		Ignacio Valdes

← Older revision		Revision as of 16:13, 22 February 2013
Line 96:		Line 96:

	I make these points not in the hopes that I would convince you that		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,		single sign-on is a good idea, but to point out that it is a [[debate~\|Debate]],
	and we are not foolish for wanting to have it.		and we are not foolish for wanting to have it.

Line 149:		Line 149:

	As a physician, I hate multiple sign-ons. I have never had a chance		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		to [[debate~\|Debate]] this issue with anyone, so I'd like to give you an
	opportunity to convince me.		opportunity to convince me.

Line 175:		Line 175:
	Greg Woodhouse		Greg Woodhouse

	Good for you Kevin. This is a prime example of an area where ~~debates~~ over		Good for you Kevin. This is a prime example of an area where [[debate~\|Debate]]s over
	usability and functionality are easily clouded by implementation concerns.		usability and functionality are easily clouded by implementation concerns.
	We should start out with the customer (in this case, the healthcare		We should start out with the customer (in this case, the healthcare
Line 272:		Line 272:
	would be able to say with confidence in a court of law that I wrote		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		this, or didn't write that. That's pretty much impossible with
	ASCII. But outside of legal debate when people get to pointing		ASCII. But outside of legal [[debate~\|Debate]] when people get to pointing
	fingers at each other, all this security is not so important. We've		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		cared for many a sick patient with paper charts for more than a few

← Older revision		Revision as of 19:13, 21 March 2012
Line 254:		Line 254:

	The signatures on notes, etc, is a safeguard to ensure the document is		The signatures on notes, etc, is a safeguard to ensure the document is
	reviewed before it becomes part of the official medical record.		reviewed before it becomes part of the official medical [[record~\|Record]].

	Hey, it's a start...		Hey, it's a start...
Line 268:		Line 268:
	Well, the staff will notice if a stranger comes in and starts looking		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		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.		if the [[record~\|Record]]s are electronic and can be access from North Korea etc.
	Next, every doctor has a unique handwriting. So 5 yrs from now I		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		would be able to say with confidence in a court of law that I wrote
Line 281:		Line 281:
	with the text. Or perhaps combine it with some other technology like		with the text. Or perhaps combine it with some other technology like
	keystroke patterns that some say are fairly unique among various		keystroke patterns that some say are fairly unique among various
	users. That way let the user sign the record however they want (using		users. That way let the user sign the [[record~\|Record]] however they want (using
	the honor system, as they do in the paper chart), but still have the		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		ability to very the accuracy of the claimed name etc. I'm sure there

← Older revision		Revision as of 15:01, 22 February 2012
Line 120:		Line 120:
	In my response, I am using the most common definition of single sign-on		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		which is a user signs in ONCE and then all single signon compliant
	~~applications~~ automatically let the user into the application which they		[[application~\|Application]]s automatically let the user into the [[application~\|Application]] which they
	launch provided that the centralized roles and privileges authorizes that		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		user to run that [[application~\|Application]]. That is what I do not agree with. For an
	EMR, I want the user to "reauthenicate" for that application before letting		EMR, I want the user to "reauthenicate" for that [[application~\|Application]] before letting
	that user into that application.		that user into that [[application~\|Application]].

	The common definition for single sign-on was around before VistA pursued		The common definition for single sign-on was around before VistA pursued
Line 207:		Line 207:
	be used. If network authentication is being used then the problem of		be used. If network authentication is being used then the problem of
	different passwords expiring at different times is not an issue. Network		different passwords expiring at different times is not an issue. Network
	authenticating ~~applications~~ would all validate against a single network		authenticating [[application~\|Application]]s would all validate against a single network
	source. Since it is a single source, then the timing of the change of		source. Since it is a single source, then the timing of the change of
	password would be localized and controlled by that single system.		password would be localized and controlled by that single system.
Line 222:		Line 222:
	to attempt to implement single signon will continue to be burdensome. For		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		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		limited set of [[application~\|Application]]s 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		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		be prudent to require those individual [[application~\|Application]]s to "reauthenicate
	sign-on". In other words, the app prompts for username and password and		sign-on". In other words, the app prompts for username and password and
	authenticates against the network independent of the username that was used		authenticates against the network independent of the username that was used
Line 323:		Line 323:

	Auto Sign-On requires the user sign into VistA, but subsequent		Auto Sign-On requires the user sign into VistA, but subsequent
	~~applications~~ connecting are signed on as the current user		[[application~\|Application]]s connecting are signed on as the current user
	automatically. Sites that want to can turn on the Auto Sign-On and		automatically. Sites that want to can turn on the Auto Sign-On and
	must have the client agent (clagent.exe) active on the workstations		must have the client agent (clagent.exe) active on the workstations
Line 338:		Line 338:

	While requiring an investment in Infrastructure, but the use of CCOW		While requiring an investment in Infrastructure, but the use of CCOW
	User Context provides for GUI ~~applications~~, when compiled with one of		User Context provides for GUI [[application~\|Application]]s, when compiled with one of
	more recent versions of the RPCBroker to use the user's identification		more recent versions of the RPCBroker to use the user's identification
	in the CCOW Vault to authenticate the user on second and subsequent		in the CCOW Vault to authenticate the user on second and subsequent