I’m a doctor in Victoria, Australia, beginning collaborations with the IT department in our hospital. I want to know more about the experience of software engineers / sysadmins / specialists working with doctors, and what pitfalls I can try to avoid.
This is a great question. I work at a software development firm called Light-it and we've had a few healthcare projects. This are some of the insights:<p>- Security is highly sensible, all the data is very confidential and can't be lost, so it's important for the IT department to understand that.<p>- Both, doctors and IT people, tend to use jargon and technical speaking. Both should try being as simple and clear as you can so that there aren't missunderstandings.<p>- If you're building a system for doctors, the IT team must keep in mind doctors are very busy people so the system should be really smooth, usable and accessible (you'd want to have a good UX designer at the team).<p>- IT team should be familiarized with the Medstack (HIPAA compliant hosting).<p>- If whatever platform you're building manages patients information, it's very important to cover all edge cases to guarantee the information safe and the platform 100% reliable.<p>Hope this is useful!
I did a security review of a hospital's mainframe that was also used by student doctors.<p>The one thing that kept standing out, because it came up so often, was a <i>very</i> solid belief that the patient records that the students could access were anonymized so there was "no way" a student could connect a record with a specific patient. Pretty much everyone involved had absolute unwavering belief in this. They often expressed this in the form of obvious doubt in my ability to do anything that would make the expenses of the gig worthwhile, and pre-blaming the privacy commissioner for any failures to find anything.<p>My report got a particularly wild response, as I provided several different scripts searching out and combining various student-accessible databases and returning very clear personal identifiable information. Some of the methods were trivial. Eg: I tied one set of patient records to a story from the news and demonstrated there were quite a few other patients with that same exposure potential. They were so focused on what you could tie together internally that they neglected to consider Googling for news stories that might result in a new patient at this particular hospital. And that very simple method made it super easy to find specific patient's info, and tie it together to a rather detailed history of that particular person's visits from that point, connected to other visits (some completely unrelated) before and after the incident I found in the news.<p>There's nothing wrong with a doctor being that confident about their own skills. I'd be terrified of a doctor who wasn't. But that doesn't transfer very well to the IT side of things. I don't know if they thought the audit was focusing on them, or that they might get in some sort of trouble (even though none of it would be their fault) but it was clear until I presented the results that they absolutely resented their environment being tested by a third party at all. It wasn't about them, but they were trying to be gatekeepers until eventually I could convince them I wasn't there to ruin their day.<p>In the end, they were fascinated by the results, and seemed to enjoy finding out how much data mining gold was right there to be had.<p>It's the first and only time one of my reports had to be heavily redacted before it was provided to the stakeholders. I think everyone (including myself) learned quite a bit from that gig.
One big thing is security. Not opening spam email, plugging in random USB drives, leaving the computer logged in, etc can go a long way. A regional hospital system has a lot of these issues.