Disclaimer: I am involved with HIPAA-COW on the Security, Risk and soon the Technical Security working groups; we release a lot of information to help people.
172 karma · joined October 30, 2009
Personal email: Wayne@knownGood.com
Disclaimer: I am involved with HIPAA-COW on the Security, Risk and soon the Technical Security working groups; we release a lot of information to help people.
Even if they were bought out the code would still be available and someone else could provide the service and continue development. Releasing the code seems like the best guarantee possible.
http://www.tripwire.com/state-of-security/security-awareness...
The problem is that there is a lot of information which can help technical people figure out if something is suspicious but the email clients don't use that info to help non-technical people know if something is safe.
It talks a bit about how one person tracked attacks through multiple countries back to China.
Nonsense. I have never been to college and I am currently responsible for the IT Security of a mid-sized health network. Not only was I hired without a degree but I've been promoted several times.
I also have no technical certifications, at various points in the past I had some but have let them lapse. Having a piece of paper may make things easier, but in the end it comes down to whether or not you can sell yourself to the organization.
One example was a change to the password complexity requirements for our organization (health care); since this was approved by senior leadership I changed the passwords for senior leadership first and did not allow any exceptions to the new policy. This ensured that the people who initiated the policy and are in a position to change the policy are the first ones impacted by it. If something was horribly wrong I would only change the policy or provide an exception if anyone who met the same criteria was also to be given the exception. If the exception is by job title or position I would require that they explicitly put that in the policy; that has never been requested though.
When there is a process to communicate issues and a culture that actually cares, compliance isn't as bad. For example we instituted a stricter change management process about a year ago.
We got people together to figure out what we thought a good balance was between the compliance needs, operational needs and the problems we were attempting to solve. As we were using the new process we gathered information from people then reviewed the entire thing at around six months. Based upon the feedback we made changes to the process, loosening somethings and tightening other parts. We have another meeting to review this in a few weeks since there have been some new proposals for how to streamline the process.
As far as management learning the rules, I tend to not have too much issue with that. If they don't follow the rules and are unwilling to comply their access to all systems will be shut off; the IT security group reports to me. :) Once people know you will go so far as to shut off their access for not cooperating it is amazing how quickly they work with you when an issue arises.
For us there is always a process to get exceptions with any policy; but the person performing the action may not be authorized to give themselves an exception arbitrarily.
I'm in charge of IT security and the designated HIPAA Security Officer for a health network. Some of my favorite conversations will typically begin with someone saying that they will follow the rules when they believe the rules make sense.
With meteor there is no knowing how the pricing will be without asking first; but nkoren's concern is that they won't know a viable business model until after significant work has gone into development. At that point if nkoren doesn't like the pricing they would have to switch to another framework.
I never got the impression that nkoren was against paying for meteor, just against taking a leap of faith on _any_ system which would require significant investment of time before finding out even a general idea of how the pricing works.
But there are a LOT of smaller practices without an EMR or that don't want to go through the work of initial integration.
If I have an urgent item that has to be done RIGHT NOW there may be an exception but in four years of being in this job I've only had a few of those. Those types of events are usually patient safety events where a patient's life is literally on the line and some piece of technology is acting up.
I really like how they have structured the support concerning Forums, UGM and Good Maintenance; for an enterprise software company it is the best approach I've seen.
We have tried to streamline the interface, but they don't want IT telling them what is important to put on the screen. During our last upgrade we had issues because some physicians put so much on the screen that caused a problem with the program; Epic implemented a fix for us, but the physician took something we showed them and ran with it. Then they started telling others who did the same.
The end result was like the image people like to link to whenever this topic comes up; a screen full of check boxes and sliders. They like this because all of the information they want is on one screen and they can quickly go down the screen making selections. When we tried to streamline this they didn't like that there would be multiple screens to load and then they wouldn't have one way to see everything selected without a summary page which was yet another screen.
I work in IT security and user experience is one of the key things we focus on; a system that is confusing or difficult to use will be used in ways we do not expect. Making the most obvious choice the right choice reduces risk, confusion and helps ensure people do the right thing.