The article implies that IT doesnât understand and imposes these things without regard to the work or the business and this is incorrect. We impose these things because we are required to by the many laws that we must follow. We are audited weekly (that is not an exaggeration) by either another medical vendor or a regulating body. We must show all requirements, testing and development changes, along with how those changes apply to ALL current laws, including CAPP, CLIA, FDA and HIPPA regulations. We also have to follow these insane laws in even our development environments that do not hold patient data. For work I have over 40 passwords, just for work, and they cycle from 15 days to 90 days.
Seems to me we need a better system that provides some security with out being intrusive.
What about having key card sensor or an RFID chip reader on each computer? Most hospitals require key cards to access employee entrances and certain doors and elevators/elevator floors. Just have a reader where they put their card they already have on a lanyard - bing - we know who logged in and where. Logging in for the Doctor or nurse becomes more or less effortless. No more pass codes. Lost key cards just get locked out and replaced.
Oh gawdâŚHIPAA.
Letâs solve a problem with capitalism by making the people who are trying to save lives jump through a stupid amount of hoops.
And donât get me started on the SSN thing. Everybody should get ONE FREAKING ID! We have so many man hours wasted just because of that one tiny little decision, and Iâve gotten in front of more than one PHI violation and one case where somebody was going to get sent to a program that their âghostâ qualified for but wouldâve killed them.
There was mention in the post of regulatory compliance being a factor.
This small part stuck out for me because it seems like the real tip of the iceberg.
I donât blame IT departments which are often staffed with people trying to maintain existing software that they didnât write, and I think thatâs an important distinction. IT departments are often trying the best they can to keep things going and I canât begin to imagine the complexities they faceâboth legal and humanâwith hospital software.
The problem I find is with developers who write software with no customer input. I donât know how true this is in hospitals but âYou only think you need to do thatâ is an attitude Iâve encountered again and again in software companies. Most of the people I deal with in IT departments say, âLet me see if I can help you do that.â
I realize no system is going to fit every user, or even every institution, but it would be nice if software companies surveyed a large range of potential customers before offering a product instead of creating something general and responding to complaints with, âWe donât need to change the system, you need to change your procedures.â
Nice to see nothing has changed from back when I was a nurse. . .
I am an IT worker who is currently changing fields and going to school for healthcare. The shell-shock during my clinical training caused by the horrifically poor ergonomics and interfaces used at the Hospitals and Nursing Homes Iâve been in was very surprising.
The computers have all the flaws mentioned here, the layouts, the restrictions that are routinely ignored. Iâve come to believe that no regulation is better than regulations that are ignored routinely. The amount of hoops that nurses jump through to get things done is absurd. Healthcare is in need of a complete bottom up redesign.
If youâre working in Healthcare, regulatory compliance is a HUGE factor (as is substandard tech, information saturation, and many more). The article just didnât point out what those in the biz know.
This is almost certainly a huge factor, but saying âsoftware developersâ is an oversimplification of where this communication breaks down. I develop software solely for the non-profit that I work for. Everyone who uses the things I build I know by name and face, and work in the same building. Iâve held their babies and eaten of their wedding cakes. I still have a hell of a time getting people to tell me what it is they do all day, and how software could help them.
Weâve only recently begun seriously investing in a central admin/operations team to foster communication between the departments. This team also collaborates with me, and makes sure that meetings with the staff occur. Itâs a huge logistical undertaking to get people with their boots on the ground to give meaningful input and feedback into the development cycle. You have two different groups, both hugely invested in, and blinded by, their own systems of lingo, sets of expectations, and piles of unexamined assumptions. It take a team of translators / task masters with authority over both parties to make this happen, as neither group can allocate this time and energy without severe arm-twisting, and a constant reminder that if they donât collaborate, all is for naught.
And this is all assuming that none of the hospital staff would rather see computerization fail completely because they hate it outright, or that the software company has anything other than a base profit motiveâŚ
Thank youâI really should have acknowledged that itâs a lot more complex than I made it out to be and that there are a lot of factors to consider, that not all software developers are unwilling to listen to customersâin fact I suspect most are. It would be hard to stay in business otherwise.
Fair enough. I take it as a given, so a sentence about compliance leaves me nodding in agreement. I wonder how much depth the original study covers it in. (Something to read when I have time.)
Word!
Getting people to share pain is pretty much mandatory for effective operations (Iâm doing a brief stint at American Family and see a different version of that in the IS silos here).
Good luck with that, itâs a bear and a half to get going, but thereâs a ton of payoff, especially on the unmeasurable side!
Are they aware of this? Sounds pretty creepy, sneaking into nurseries and freezers.
A big part of the problem is compartmentalization of knowledge. Quite often the people actually using the software and the people who develop it arenât in communication. Determining which software to purchase is usually a function of management. It is done without those who will end up actually using it being able to try it out. Even custom developed software usually fails to have the requirements determination and post-development testing done by actual users.
I experienced this personally at UMDNJ a few years ago when they switched over to an online records keeping system with a poor user interface. I told my doctor how designing such an interface would make a good project for a CS student. He told me that neither he nor anyone he knew was given the opportunity to provide actual input to the developers.
we just got a new point of sale and inventory system where i work. weâve all had to adopt some new practices â no problem, really â but there are some bits which make literally no sense, and worse there are hard to reproduce bugs ( sometimes even causing requiring reboots, and the like. )
in every case, the developer response has been: it works as intended.
itâs so frustrating.
i donât know exactly what the mindset is. it feels like the developers are saying: we know tech, therefore we are smart. you just use the systems, therefore you are dumb.
it also seems (some) developers donât allow for the fact users may lack the correct words necessary to describe an experience. and so the userâs experience gets ignored.
The olâ âItâs not a bug, itâs a feature.â bit. Classic.
Iâve talked to developers who say designing user interfaces is their least favorite part of any job and something they almost always throw together at the last minute.
In fairness to them maybe the problem is the companies they work for donât consider usability all that important.
After using it for such a long time I boggle at why smartbadge+PIN is not widely adopted. You should have your badge on you at all times right? Just insert and put in the PIN/Password and this way it does not need to change every 90 days or what not or be crazy complex as a hacker is going to need the physical badge and know the PIN as well.
Unless the software vendors are really lazy at coding to accept the technology.
I agree with you there. As a developer myself I try to learn as much about the target users as possible. I like to talk to them and watch over their shoulders as they work. However, more than one employer has forbidden developers to interact with the target users.
