Back in mid-2007 I deployed my first instance of Google Apps, replacing a Microsoft Exchange 2003 server. It was a controversial choice back then — Google Apps was still pretty new and it wasn’t yet clear whether Google was going to stick with the platform and build it out. But there were several deciding factors that pushed me to an Apps deployment:
- I was working at a nonprofit, so Google Apps was free for us; worst case I could always fall back to the in-house system
- Our Microsoft Exchange 2003 server was constantly running out of space and was a pain to backup
- We lived under a monstrous waterfall of spam that required a special appliance outside the Exchange box that worked well but was costly
- Our Internet connection was relatively slow and outrageously expensive, so handling all the mail traffic in-house was painful, especially when the in-house web site was what we really wanted to share with the world, not our email system
- Our users wanted to send and receive larger and larger files via email, which only strained all of the above factors further
We made the switch, I uploaded a bunch of mail using Google’s then-primitive migration tools, and I put everyone onto the web-based interface — no Outlook allowed. We did trainings and I spent a lot of time helping users get acclimated to the new way of doing things. This was before drag-and-drop email attachments in Gmail. It was before full compatibility with external calendar invitations. It was before Chrome.
And I was immediately hooked.
Why Go Google?
From an IT perspective, this Google Apps thing was awesome. There were no servers to own, nothing to back up, nothing to manage — aside from creating and deleting accounts. The users had far more space than they’d ever had (7GB at the time) and far more space than I could have ever offered locally at a reasonable price. The system was accessible everywhere, and no matter where you got your mail or looked at your calendar, it functioned the same way. And, as a nonprofit, it was all free! We even started using Google Docs right away, sharing selected spreadsheet data with remote workers and volunteers, allowing for real-time collaboration that at the time was mind-blowingly simple yet powerful.
Since then the Google Apps platform has matured with better features, a more homogenized interface in the apps, better administration tools, more reporting, more granular controls, and great (paid) add-ons for email archiving and spam control. And since then I’ve deployed Google Apps 4 more times, not to mention personal use. My most recent migration was last year, again dropping Microsoft Exchange 2003 and Outlook to go all-cloud all the time.
And then there was this past weekend.
Getting Certified
After managing and evangelizing Google Apps all these years, I stumbled across a certification program for Google Apps nerds like me: the Google Apps Certified Deployment Specialist. So I dug through the Study Guide, re-read a lot of stuff I knew, learned a few new tricks Google has developed in the last couple of years, and paid my testing fee.
The weird part was the testing method. Rather than send you to a local testing center — where you might sit for Microsoft or Citrix or VMware or other vendor exams — this one is done at home or in your office. You can take the test anywhere you have a live Internet connection, a Windows or Mac machine, and a special USB webcam they make you buy. Total cost is about the same as those other exams, but you can schedule it on weekends in evenings and take it at home. They proctor the exam through the webcam and special software.
It worked great. The only thing I was “corrected” on during the exam was the fact that I started to read some of the questions out loud, to puzzle them out audibly. That’s verboten, probably because they fear you’d read the questions out loud so you could either record the questions (and give them away to others wanting to take the exam) or ask someone else nearby to provide an answer. It’s too bad, because I like to “talk out” technical solutions. Oh, well.
61 questions after starting, I had passed the exam, so now I’m certified! It’s the first major cert I’ve picked up since the “good old days” of Windows NT 4 and Lotus Notes and Domino. And it’s fun to have a Google certification, perhaps because it’s so rare. My certificate was numbered “1298”, which suggests there were less than 1,300 people certified when I took the exam. That’s cool — I’m in a group smaller than my high school census (except we’re all certified Google Apps pros!).
Can you use Google Apps in a healthcare environment?
I may need to address this further in a future post, but the short answer is yes. People freak out about HIPAA (as they well should) but the key thing to consider is how you use your email system. Bottom line: If you don’t store or share PHI (protected health information) in your email system, then HIPAA rules don’t apply. And for those that are using email systems (of any kind) to share or transmit patient data, I have a question: Are you out of your mind? Email is a promiscuous platform by design — it’ll “sleep” with anyone and it’s 1 degree away from every email account worldwide — so why would you ever push patient information through it? If it helps, I’ve actually addressed the Apps/HIPAA discussion elsewhere before.
Sidebar: I may also have to write a post someday (really a rant) about email footers with lots of legal language in them — a silly practice that has no force of law behind it. If you want to put in a “please don’t share this” message down there, that’s cool, but stop trying to create unilateral contracts with your footers — that’s not a thing.
All that said, I do think Google needs to rethink their stance on signing HIPAA Business Associate Agreements (they won’t sign them). They either need to start signing or they need to post a definitive position paper on HIPAA issues related to Google Apps. Microsoft has shown a willingness to sign BAAs for Office 365 services, which makes their service more attractive, despite their downtime problems. Google has done a good job addressing the overall security of Google Apps, but they need to go a step further, to assuage the fears of healthcare executives and Boards that don’t understand technology very well.
What’s next?
For now I’m a happy Google Apps administrator, still learning, still sharing tips with users new to the platform. Oh, and I’m a Certified Deployment Specialist, of course! So if you’ve got questions about going Google in your healthcare environment (or any business, really) just let me know. I can answer some questions in the comments or we can take the conversation offline.
Gravity Medium 
Hey John, I did a search in twitter for “Google Apps Deployment Specialist” and I found you! I have been studying to take the exam for a while but I am a little bit nervous and don’t know if I am ready to take it. I believe I am lacking with Domino Server knowledge, and I have no experience programming API’s. Can you give me some advises, tips, or recommendations? (or maybe paid online classes?!) hehe!
I’ll see if I can answer your questions…
Good luck with your studies!
John,
I am not on the certification path, but found your article helpful. We have a physical therapy practice and have google apps mostly to escape Exchange. We have not made much use of docs because the file ownership and sharing. We have staff changes and it does not affect the clinic as the documents are stored in directories with the topical names such as billing, therapist notes, marketing etc. Access to the directories is determined by the users group privileges. That is a therapist can see the therapist notes but not the billing information. When staff changes we can add or delete the user and nothing else changes.
In Google Docs the document ownership is by creator and would cause all kind of control problems in the clinic. Each creator will make different directories and file similar documents in unusual places. A change in staff will require knowledgeable people to open, read and refile each document. etc…
Are there any guidelines or “role models” for a health care clinic such as ours?
Thanks
Excellent questions Robert! I know exactly what you’re talking about when it comes to Google Docs and making sure documents remain accessible to a team after an employee leaves. But there is a solution, built-in to Google Apps and available by using third party management tools.
For example, when an employee leaves, they may have created Google Docs that other folks need or that simply need to be transferred to that employee’s manager or their replacement. In the Google Apps dashboard you can do this in one step. It’s called “Document ownership transfer” and it allows you to name the source user and the destination user. With one click, all the ownership transfers from one account to another, and nothing is deleted. This includes both shared and private documents.
If you did not have an idea of where to send documents for a departing user, you could also create a dummy or “holding” account that gets all transferred documents. As an administrator, you would have access to that account and could search for anything that others need. Then manually change ownership on each document as needed. This is more labor-intensive, but it’s a good fall-back position if you want to preserve documents at all costs.
If you don’t want to use the Google Apps dashboard to handle on-boarding and termination of employees, you can use a tool like FlashPanel. That’s a slick way to handle many of these transition events in a company. Right now FlashPanel is still free, but they’ll start charging for it sometime soon.
All that said, I don’t recommend moving completely over to Drive if you already have shared folders on a local server. There’s a lot to be said for “public” drives or departmental drives stored right there at your location. Speed is one. And the fact is, most people still prefer to use Microsoft Word and Excel and so on.
As for things like therapist notes, I don’t think I’d store those in any online fashion unless they could be stored in your EHR or practice management system (which you may or may not have). I’m leery of storing PHI (Protected Health Information) or really any customer information in cloud services. At least so far. Some folks have no worries about that (and in truth the security of Google Docs / Drive is actually remarkably good), but cloud hosting of PHI is still rare.
One last comment… You may want to consider whether sharing freely-editable therapist notes via a local file server meets HIPAA guidelines. One of the things you’re required to be able to do is produce an audit trail of who accessed which records and who changed what. That’s hard to do with a local file server, and it’s why EHRs are really helpful, despite their extreme cost.
As both a Google Apps Reseller, and CIO of a large medical clinic that has made the leap to using Google apps, not only for email, but as the document storage back-end for patient documents (everything that was paper… not the certified electronic medical records) I have done a lot of research on the Google Apps / HIPAA topic, and feel there is a strong argument to be made in favor of leveraging this infrastructure in the health care space. Our position is that:
1) Because of the way Google is structured, the way the Google File System is engineered, and the strict separation Google maintains between themselves as an infrastructure provider, and their enterprise customers who use the infrastructure, Google does not rise to the level of being considered a Business Associate under HIPAA definitions.
2) Even if one were to concede that Google is a Business Associate under HIPAA, the standard user agreement, combined with the other published documentation surrounding Google Apps enterprise privacy and security policies and practices more than satisfactorily covers all aspects of a “Business Associate agreement or Other arrangement” within the HIPAA context.
The point I disagree on is the statement that Google needs to publish a position on HIPAA compliance, or start signing BAAs with their health care customers, like Microsoft does. First, Google is not a Coved Entity under HIPAA, and no product or service can claim HIPAA compliance. Second, if they were to start signing BAAs with their customers, they would cross the separation boundary of being an infrastructure provider that operates as a conduit through which Covered Entities manage their own protected data and information.
Google’s responsibility ends with publishing their own security and privacy practices, so that customers using the infrastructure can meet the regulatory requirements of whatever industry they operate in. It is up to the Covered Entity to make sure they are in compliance with appropriate regulation. Google provides all kinds of tools to help with that effort.
Thanks for your comments, John. I tend to agree that a HIPAA Business Associate Agreement (BAA) with Google is not technically required, assuming you use their services appropriately and given their architecture. However, their failure to sign BAAs is something that will give most risk-averse organizations pause, to say the least. HIPAA regulatory interpretation is an art rather than a science, and a BAA goes a long way to showing regulators you did your best to protect your information assets. A Google BAA would prove you tried to CYA. 😉
Of course, with the revelations this week that Google and other tech firms have been deeply cooperating with the NSA, I suspect the fears over using cloud services like Google Apps in a healthcare environment will be raised. It’s too bad, really.