It's About the Data, Stupid! Real World Mobile Security

It's About the Data, Stupid! Real World Mobile Security

October 02, 2012 2:00 pm

(Save to cal)


An interactive mobile security webinar Tuesday, October 2nd @ 2 P.M. ET with Marie-Michelle Strah, Ph.D., Founder of Phydian Systems and April Sage, Director of Healthcare Vertical and Marketing at Online Tech.

When: October 2, 2012 @ 2 P.M. ET
Who: Marie-Michelle Strah, Ph.D., Founder of Phydian Systems and April Sage, Director of Healthcare Vertical and Marketing at Online Tech.
What: It’s About the Data, Stupid! Real World Mobile Security
Description: Too often mobile security in healthcare is focused on device level security. Organizations become focused on securing and managing a wide array of hardware devices, and in a BYOD (bring your own device) world, that can quickly become burdensome.

BYOD is supposed to liberate organizations from hardware maintenance time and contract costs, but the unanticipated costs of multiple OS, platforms and user training and policies not only add up quickly, they shift the burden of mobile security to the end user. Best practices in mobile security minimize risks associated with BYOD by focusing on securing data, not devices, and focus on how to best leverage taxonomies and metadata to secure ePHI (electronic protected health information).

In this webinar, they discussed how shifting the perspective from Mobile Device Management to Master Data Management makes MDM a key pillar of your HIPAA privacy and security planning. While this webinar is focused on healthcare, HITECH and HIPAA compliance, the best practices in BYOD are applicable to all highly-regulated industries managing sensitive data.




View Slides

April: Hi everyone, and thanks so much for joining us today. For today's Tuesday at 2:00 webinar we're very happy to welcome Dr. Marie-Michelle Strah. Dr. Strah is the founder of Phydian Systems, and she has a wealth of expertise in healthcare enterprise architecture and security.

She's worked extensively in the government sector and brings over 15 years of experience in information technology management, specific to information security and compliance. Today she's going to talk with us about the right place to start when thinking about mobile security. With no further ado, let me welcome Michelle.

Michelle: Thank you, April. It's a pleasure to be here today. As many of you on this webinar may note, there’s quite a bit of news coming out in the past week about a lot of developments in mobile security. We'll be touching on those today during the webinar, because it's very topical.

We do have the opportunity for questions. I am going to be talking about planning and architecting for the real world. I understand we may have a lot of people from various backgrounds, either large organizations, small practices—please let us know via chat and the questions if you want some more content directed to your specific case later on in the webinar.

Thank you again for being here. We're going to talk about some of the goals of enterprise mobility. I think we're all here today because we realize that employees are purchasing and using their own devices at work; what is called a BYOD or “bring your own device.” Actually 95% of employee devices are used at some point in the workplace.

There are a lot of benefits of enterprise mobility, including building productivity, it actually reduces risk for organizations in some cases, but there are a lot of things to take into account such as mobile device encryption, access controls, policy and technical controls, and what a lot of people are asking questions about right now is the maturity of the mobile device management software and technologies that are on the market and the expenses associated with data protection.

Michelle: The thing that we're going to be focused on here, and I'm sure you can see that from the title of the webinar, is it's about the data. It's not necessarily about device-level security and in fact, focusing too much on that can actually lead you astray in your BYOD implementation. We're going to be taking a look at master data management, and looking exactly at what protecting your data entails beyond simply protecting your devices.

BYOD has come to the forefront as part of the consumerization of IT. I have this slide here because it does a very good job of encapsulating why organizations are faced with BYOD. Due to a broad enterprise uptake in consumer technologies that are driven by not only the business but by end-users, we're seeing that consumer devices, consumer applications are having a very disruptive impact on enterprise IT.

For healthcare, obviously, this brings some particular challenges around HITECH compliance, both for data privacy and security. For the organization, whether it's a large multi-state healthcare provider or it's a small doctor's practice or even pharma and biotech, BYOD and some of the challenges and risks can't be underestimated. There's a lot of opportunity involved, but it also puts a lot of pressure on governance and the decentralization of that governance.

We're going to look at some case studies that are actually occurring right now with the VA, that really bring to light some of the challenges. You see on the slide on the right, it really highlights that some of the disruptive technologies that enterprise mobility brings are around social computing and the access to Enterprise 2.0 and social and collaboration platforms as well as shadow IT adoption.

This is that sneaker net that I think we all are a little wary of, when employees are dissatisfied with what IT officially provides them and start using either their own tools, such as Dropbox or others that shall remain nameless, to kind of get around IT.

What we're looking at today is ways to plan, to take advantage of opportunities that enterprise mobility brings, and balancing that with the importance of governance risk and compliance for HITECH app compliance.

April: Michelle, I've talked with a few CIOs who, not knowing how to handle the BYOD issues, have resorted to trying to ban mobile devices from the workplace. In your experience, have you seen any success in trying to keep those rogue mobile devices completely out of the enterprise, or do you feel like that's a lost cause?

Michelle: That's a great question, April. I've seen that happen. Sometimes when we don't know how to deal with something, we're just going to outright ban it. That can temporarily solve the problem and give you time to find a way to incorporate BYOD, but in the long-term what it does is it creates a lot of resistance and unhappiness on the part of the end-users. What it does do is it just postpones the overall problem. It's not effective as a long-term strategy; it's not realistic in terms of consumerization of IT, but it is a sign that we have perhaps some more planning to do.

Quite frankly, as we look at this slide, it's not actually about the device. The example you pointed out, April, which I think is an excellent one, is the symptom is usually we're seeing employees bring a rogue device to work and trying to connect to the network that way. It becomes kind of an easy answer to say, “We're just going to ban them,” but actually the problem really isn't about the device.

We have here kind of a Twitter conversation that I was engaged in this weekend with a colleague who works in enterprise security at HP. As you can see here, I was reacting to a recent article on “Enterprise Mobility & the Art of the Possible.” This article did a very good job of pointing out all the advantages that mobility brings to the enterprise, and certainly had a very optimistic view. It did however point out some of the challenges, and one of them was securing the data and securing the devices.

My colleague here said, “We need to stop worrying about securing devices.” I had to agree. There's a lot of focus on end-point security, and I think some of that, what we concluded, is because it seems like an easy fix. We don't want these devices, we're going to ban them. Or, if we're going to allow them, the organization then says, “We're going to encrypt or secure the devices, and then our problem is solved.”As this conversation here points out, that's not going to solve your problem either. Mobile device security is not just about the devices themselves, although as we'll see later on that is something that is part of your overall security posture. The perspective of information security professionals is that is a very limited view and does not necessarily mitigate all of the risks.

Michelle: We're going to move on and try to look at some of this tension between data and devices. In this slide we're taking a little step back to healthcare. mHealth: It's definitely an enabler. It enables patients to manage their wellness, communicate with their doctors. It allows providers to be more engaged and have better access to real-time data and patient information, as well as provide literally bedside medicine. With a lot of the consumer apps it really takes care of the wellness life cycle, whether it's from fitness to diabetes to chronic disease management, and certainly it can be a significant productivity enabler.

The graphic we have here is from the Gartner Hype Cycle for mobile health. Gartner, as part of their analysis, looks at where some of the excitement and hype comes in around new technologies. Certainly what we're seeing here is mobile has become very visible and is now going through a maturity process where we see that we've come through—if you look at the green arrow there—a trough of disillusionment. I think that's the example you pointed out, April, where we're just disillusioned, “This is a problem, we don't know what to do with it, we're going to ban it,” and now we're moving into more of an enlightenment phase that allows us to look at this more productively.

The challenge is mobile health often is about apps. It's that “there's an app for that” type of mentality. The challenge is not really, in this case, about the devices; it becomes about the applications and the data therein. The questions we're going to ask, are these apps that are being used in mHealth, are they themselves secure? It doesn't matter if your devices are secure if the application itself, whether it's web-based or mobile app, doesn't do a good job of meeting HITECH compliance.

We're moving into a perspective. We're going to look at the enterprise information management life cycle. We're going to be looking at analyzing what content is going to be delivered on mobile devices; the content and data that's going to be allowed and capitalizing on the cloud and then client. The answer is yes, mobile is an enabler, but we've got to do it right.

Some of the risks associated with mobile health – and we have here a recent graphic that just came out – is the risk to patient data if not protected according to the HITECH app privacy and security guidelines, are not only risk to the covered entity and the business associates as far as fines and breach reporting, there's actual risk to patients of data loss.

This can take the form of healthcare fraud and medical identity theft, and using apps that are not proven or tested can actually lead to inaccurate patient identification. The numbers surrounding this are surprising. It's in the millions that these are costing not only providers and organizations that are covered by HITECH, but actually the individual patients themselves. I think this is part of a larger infographic that shows the actual cost to a patient to recover from medical identity theft is over $28,000.

Managing our information properly is not only the right thing to do because the law tells us, but those of us involved in healthcare are here because we want to help people. Keeping these things in mind are part of how we look at what data we're accessing, both at the field level of data as well as the applications.

Michelle: Mobile can increase risk, as we see in the graphic on the right. It can also reduce risk. Allowing providers and patients to access data on mobile devices does increase accuracy. It increases not only completion rates of EHRs, but it allows providers real-time access to data both from inputs and output. It increases information sharing, which is only good in healthcare, and can reduce the risk of misidentification and bad data quality.

However, what we're going to see later is often times the practice size affects the risk profile. One thing that's a challenge for small practices, either providers that are solo practitioners or in small groups, is they generally don't have an IT department on staff. The lack of dedicated IT support definitely increases the risk profile adversely, because a lot of what is done in planning for mobile health is just skipped over and handed to the individual to manage. That can be extremely risky. The key to mitigating and minimizing these risks are in proper planning, identifying the business cases, and then looking at master data management and enterprise information management.

As we see, this infographic recently came out, this data point, 54% of the 464 HIPAA breaches—and I'm sorry, there's an error in that; I'll fix it later in the slides that go out. That's from September 2009 to July 2012, involved loss or theft of unencrypted mobile devices. Over half of the HIPAA breaches involved mobile devices. There's certainly a behavioral component for end-users that is part of what we need to do for compliance, but unfortunately that's not going to solve the whole problem.

April: You know, you can see from data points that we get from the Wall of Shame and the Ponemon Institute that it's very easy to focus on the devices because they are pointed to as the source of all the trouble. As hard as it is for organizations that do have compliance and IT departments to get their minds wrapped around where to start, I can imagine that this has got to feel pretty impossible for those smaller practices that you mentioned, Michelle, that don't have a dedicated IT department. How on earth would they have enough hours in the day to contain all of these devices?

Michelle: That is a challenge, and certainly I think a lot of providers would say that not only are they perhaps unintentionally becoming their own IT providers, certainly the administrative version that a lot of these technologies bring is also an unintended consequence. It is a challenge in healthcare transformation, but we're going to look at some of the best practices to minimize not only the burden but to minimize the risk.

The first question when people come to me with these types of questions and say, “I'm considering BYOD,” or, “We've got people bringing devices—what do we do with it?” My first question I always ask is, “Why are you considering bring your own device?” There's either two things I see. One is, “We are scared of this so we're just going to ban it,” or conversely, “We're going to jump on the bandwagon. Everybody's doing BYOD, so we're going to do it too.” I often ask, “Is this the right thing for you?”

A lot of times it's a question of scale whether it's the right thing for an organization to allow personal devices. Some of that requires, as we see at the top of the slide, looking at your business cases for IT infrastructure management. We're going to go a little bit more deeply into this in the next few slides.

The first question you should be asking is, “Is this appropriate for my organization?” If so, then we'll determine the policy and technical controls. Ironically, I have advised clients at times that it's not the right answer for you. Sometimes it's better to have organizationally issued devices both from a business case and cost standpoint.

However, if it is the right answer then definitely building a governance risk and compliance framework is absolutely essential. These include the best practices, as we see at the top, and these are what are required for HITECH compliance. It's a best practice and it's also a have-to, is security risk analysis, a privacy threshold assessment and a privacy impact assessment.

Those are the first two steps in building a BYOD policy, if that is what we've determined is the best thing for your organization. These are basically spelled out according to the NIST guidelines, which is what the HITECH Act requires or relies on, and the security risk analysis and assessment addresses the physical, technical and administrative safeguards that are present in your organization. This goes not only for electronic personal health information but also good old-fashioned paper records and PHI.

Michelle: From there we also look at the data that's included where we can assess, by doing the privacy threshold and privacy impact assessment, what data is actually covered under the HITECH Act. This includes an analysis of the data architecture and the 18 direct HIPAA identifiers to determine what needs to be protected and what is able to be shared.

It's surprising how many organizations don't really have an understanding of what is covered by ePHI. What I've seen is they'll go way too far in limiting and restricting data, assuming that everything is covered under HIPAA, or they'll go quite the other way and assume that some data is not covered under HIPAA.

The only way to figure out where your data architecture fits within this is to do these assessments. Looking at the stakeholder needs and use cases is critical because blanket policies that apply across an organization do not work. Different sets of users have not only from a user experience but also based on their roles and the function within the organization, may have different needs as far as mobile data access.

Once those three steps have been completed, then determining the policy and technical controls that are necessary. By doing this, some of the lessons learned that I've discussed are we don't want to jump into BYOD but we don't necessarily want to eliminate it either. From an enterprise level – and I'm using the term enterprise here to mean organizational – it doesn't necessarily mean an enterprise of 50,000 end-users. It could be five. Looking at these from an organizational perspective is critical as part of the planning process.

April: Michelle, I'm just curious if you have a sense of where this pressure to jump into BYOD is coming from? Is it coming from worries about patient engagement incentives from meaningful youth, is it coming because it’s the latest greatest technology, is it coming because of the fear associated with the breaches caused by mobile devices, or a combination?

Michelle: I see a lot of the noise around BYOD that is really being driven by end-users. Part of that is part of the movement towards the consumerization of IT. If you remember back in the day when organizations actually had enterprise license accounts where they would issue the device and there was no choice. You were handed a Blackberry and told, “That's it, that's all you can get.” You couldn't download anything from the App Store, it was very much controlled in a top-down hierarchical fashion and a lot of dissatisfaction came from that.

End-users didn't want three devices. It's cumbersome; it takes too much room in your purse or your pockets. It becomes confusing. They want one device. It's really end-user driven, and was really a reaction to the very limited options that were available before and people saying, “I'm using this awesome tablet device, be it an Android, Windows, iPad, you name, it, and I love it. How come I can't use this at work?” The buzz is driven by the end-users, and consumers and organizations are having to adapt to it.

April: Interesting. Thanks for that.

Michelle: If you remember in the last slide, I noted your first thing is going to be to assess is BYOD right for us? If you determine that it's right, what are the total costs of ownership associated with BYOD? The cost aspect can be something that actually impacts decisions to allow BYOD. I've seen organizations be shocked at some of the costs associated with managing BYOD.

Some organizations have moved to BYOD as a cost savings measure. As you see here I've pointed out, is it actually cheaper or are you simply shifting the cost of perhaps the organization owning the devices and the account with the cellular provider and managing that telecom work and issuing a device? Are you shifting it from that to having to then have mobile device management software and policies, and training, and staff to build out your app store?

Depending on the scale of the organization—and so this is where this business case and assessment needs to be done for the individual organization—it's up in the air. It really depends. If BYOD becomes actually more expensive than just issuing iPads or Windows 8 tablets to your organization, it may not be the right answer.

Michelle: I have here a sample business case model of what is actually assessed, in this case, by looking at the strategic context. The questions asked are: What is your strategic environment, strategic fit, why are you considering doing this, and what is your intended outcome? If it's to save money, and that's something I hear a lot, then the rest of the analysis would actually look at some of that cost benefit to see if this is actually going to save the organization money. If some of the intended outcomes are provider satisfaction, we also then in phase two look at those by looking at preliminary options, looking at viable options from that, and then looking at justifications for this.

Some of the things that we look at in an analysis for BYOD are some of the licenses and account management for your telecom that are associated. Response of design: If you're going to be allowing mobile devices and personal mobile devices, how do you know that the applications that are going to be used are responsive, are they going to be used across a variety of heterogeneous devices?

Are these applications going to be managed by the organization or are you going to allow use of apps downloaded from an app store, like in iTunes or something? If those apps are going to be used, have they been tested from a usability standpoint? Are they going to be integrated into your larger master data management principles? Those are the types of questions we really get in the weeds with.

As far as enforcement goes, do you have IT governance policies in place and standards? Many organizations don't. That's okay, we would then have to build that up. Do your policies already allow for mobile, and then what training is going to be employed? Who is going to be doing the training, how is it going to be delivered, and then working to realign your enterprise architecture to allow for BYOD.

For larger organizations, this can become quite a challenge because their enterprise architecture is obviously much more robust and complex than a smaller doctor's practice. Incorporating BYOD becomes a much bigger challenge because there are so many more contingencies and dependencies.

Michelle: Finally, the question of scalability comes in. Is this scalable? Is your organization transforming and growing? Is it okay to say, “We can let these five people bring in an iPad,” that's a right now answer, but if you’re expecting that 500 people in the next month are going to want to do the same thing is that still going to be a realistic solution? Starting off with this business case analysis that looks at the total cost of ownership is critical to determine whether this is the right path for your organization.

Some of the human factors we look at and mentioned as part of your stakeholder analysis is very important, not only because training and policies often are targeting individual behaviors. Here I'll just throw out a joke. I know I can't see you all laugh on the other side of the webinar, but every time I bring up this anecdote people snicker.

You've all seen the doctor who leaves the iPad in the back seat of the Lexus at a restaurant. The iPad is unencrypted with no password and the car is unlocked. That's how mobile devices are stolen. Really, 54 percent, as I noted, of data breaches, occur exactly that way. That's a behavioral problem. That's something that the individual needs to be trained on personal security measures that go quite far beyond the hospital or IT. That's a problem of, “I keep forgetting to lock my car.” Because of that, we can't neglect the human factors.

The ideal is that employees, contractors and partners are receiving the data that they need to know, and that management of the data is done by information security IT and legal. This would be the ideal situation. However, what we see in the next slide is that the reality is that oftentimes employees are managing their own devices and data.

We often ignore contractors and partners; people who come in for a short period of time. They want to have everything on the device that they use at three different clients, and may not meet your organization's needs, and no one ever talks to information security or legal. This very fractured reality is why BYOD can often be a mess.

April: The other data point shows us that the business associates don't have the greatest track record of protecting PHI either, so I suppose bringing the BYOD with the BAs is probably not a very good mix all the time.

Michelle: That's actually a great point. Organizations that are covered under the HITECH Act, who are covered entities, it's challenge enough managing the employees and those who are actually part of the current entity from an employment standpoint. With business associates—this can be any form of contractors or partners—the requirements are exactly the same as far as the HITECH Act goes. There's no alibi for being a temporary partner or a contractor, but organizations often neglect that. It's the reality, but it's definitely a challenge.

Michelle: The best way to approach this kind of challenge is to look at adopting a governance and risk-based model to BYOD. The old way we looked at security was end-point and perimeter based security—we can build a firewall, we can secure a device, and we're good. In today's day and age, and especially with BYOD, there is no end-point and there is no perimeter. It's very fluid and can change on a daily basis, being as people are going outside of the network, even to deliver care; moving from a hospital to a satellite clinic, or if there's home-based care, all of a sudden we can't put data within that firewall.

Users generally own the data, and unfortunately no one is ending up owning the risk. Security teams may not necessarily have control over this, but your IT teams who actually own the databases, servers and applications are challenged. Rather than try to corral what looks very chaotic, we're going to try to approach it differently using governance and risk-based model.

Governance as far as both from an organizational and an IT perspective, this term is used in both lanes and are both critical. We're going to look at managing and mitigating risk, and these two elements, well guess what? They will make you compliant with HITECH meaningful use and all of the lovely aspects of the 42 CFR. This is not just the right thing to do, it's actually the way to get yourself into compliance with BYOD.

I'm just going to summarize. We had mentioned earlier, and this is at the bottom of this slide, that the security risk analysis for the privacy threshold assessment and your privacy impact assessment as well as managing the stakeholder use of data, including your policy and technical controls, should be part of the overall governance risk and compliance strategy. Starting from this standpoint will ensure success. Try to do it backwards by starting at the device level is just going to add to the chaos.

Michelle: I have an example here, and this is of a high-level reference architecture for mobile health that has been recommended for use in larger organizations. As we can see, this is a very complex reference architecture where we're looking at incorporating mobile devices. It’s not as easy as just, “Hey, can I get my email on my Blackberry/iPad/Android/Windows Phone?”

The organization needs to look at the identity and access management. One of the things we look at in the technical and administrative controls in the security risk analysis. Are there appropriate safeguards for identity and access management? This includes not only role-based permissions as well as user accounts, but managing how we are authenticating those users and how to incorporate the business associates or temporary workers. Also looking at, as we see in the blue fields in the bottom, records management and data standards, are critical to this.

At the top of this graphic we see that this is where we would look at the devices. On the left side we're looking at patient use of devices and on the right side is clinicians. At that point we've already done the work in analyzing the services, identity and access management, the communications protocols, and the data and records, and where we're actually storing that data, whether it's on premise or in cloud storage.

Oftentimes one of the challenges is organizations will start up at the top of this graphic. The answer is actually starting at the bottom and building your data framework from the ground up. Some of this requires analysis, as I said, not only doing the data assessment and privacy impact assessment of the safe harbor as well as the HIPAA direct identifiers, but also determining as part of your business case what is actually going to be delivered on your mobile devices. Answering that question as we see in the gray area right above, identity and access management, actually simplifies the decision around mobile and BYOD.

By determining what it is exactly you want your users to access will actually a lot of times make the decision for you or actually build the parameters around the decisions. As we see here, there are several examples of health applications. These could be decision support, knowledge base, care pathways, service directories, billing and cost management applications, as well as service management.

Michelle: When we're looking at the application level, something like knowledge bases—and I've seen several that have come out that can be very helpful for providers—some of those may not actually be covered under HIPAA and the HITECH Act, especially if it's content delivery and looking at providing information. In that case, it may not be a risk to the organization to allow someone to access those type of knowledge bases and content in a BYOD setting. In other cases where those knowledge bases are incorporated into decision-making or differential diagnoses for EHRs, we've moved into a whole other realm where all of a sudden we're looking at HIPAA-covered data.

These are the type of questions that we have to ask first. What do we want to access on the mobile device? That may be email, it may be provider-patient correspondence. There's containers for the application, but will also help determine what mobile device management software is best, as well as the risk profile for the devices. This high-level architecture does a very good job of outlining what is actually at stake in looking at BYOD.

April: That's a great perspective. I imagine that when you look at it from that architecture level, it allows people to save energy that they might have spent trying to protect data that maybe they don't have to encrypt or worry about as much, and also point out the gaps where they haven't thought about the PHI that might be in a certain work flow that they need to get their arms around.

Michelle: Exactly. Sometimes organizations are resistant to doing the planning and assessments upfront because it seems so much easier to just say, “I can go out and buy this MDM software. It'll solve my problem. It's faster, cheaper,” when actually because you're not solving the correct problem, you're going to end up with more long-term cost. The theme of today's webinar is, as we see on the right, is it's about the data and yes, the device, but it's not just about the device.

One example—I just put this up here for those who are perhaps using SQL Server. If you're looking at SQL Server for a lot of your business intelligence solutions, and many organizations use this, it contains a master data services module within SQL Server. This graphic comes from their 2008 R2 version, but also in SQL Server 2012.

When we're looking at how we're managing data or a master data hub across the organization, we need to secure the data at the database level as well. It doesn't really matter if the data you're serving up is on the mobile devices; it does matter whether it's secure or not, but if the data on the back-end is not secure you've kind of missed the point. Also, by managing data at the database level as we see here with this example of the master data services, we can build in role-based permissions and transaction tracking, versioning and data validation directly at the database level.

By doing so and having the right data models we can ensure that only from a role-based standpoint, which is required by the HITECH Act, that there will be no risk to people receiving data beyond the need-to-know. Right away we've taken some of the burden and risk away from trying to manage everything at the device level to saying, “We know that, whether they're accessing data on the desktop or on a mobile device, that people are receiving data on a need-to-know basis that is appropriate for their role.” It spreads out the risk, but it also makes it easier to manage because we've determined what data will actually be consumed and served.

Michelle: For those of you who have been following what the VA has been doing with their BYOD mobile device management protocols, this has just been hitting the news the past couple days and mHIMSS has been tracking it if you want to look at those news items.

The VA has been, for quite a few years now, looking at incorporating iPads and looking at deploying about 10,000. It has been a very slow process. Extremely slow, in fact, and some of that has been in securing the iPads themselves so that they meet FISMA and HITECH compliance, but also determining what is appropriate to be served up as content.

Aside from that, there's kind of a lag in mobile apps. Some of the software, the mobile app version, doesn't have the performance or all of the functionality the desktop version does. Evaluating whether it's worth using a mobile version of a software package, it can be time-consuming but it also makes this process very difficult.

The VA also, as you all know, is an extremely large organization, so deploying 10,000 devices has been a challenge. What they've done is moved towards a BYOD profile to allow individuals at the business unit level, and this will be determined by their business units, to bring their own devices in a limited fashion. This will include the deployment of mobile device management software. However, the VA did not jump to that.

There's a very lengthy process where they looked at their data architecture and determined that the systems network and applications aren't going to be supported by the VA, and they obviously have a very large IT infrastructure to be able to do that. They have come out publicly with some of the policies that are going to be included. These are very good as practices that I would recommend to any organization.

At minimum, they're going to prohibit jailbroken devices. If your 14-year-old has found a way to get around your device limitations so you can play Angry Birds in all its various manifestations, it may not actually be allowed. The individual will have to be aware that their personal device may be wiped by the VA if compromised. There's going to be rules of behavior required if storing VA data on the device—some of that goes to the, “Don't leave your device in an unlocked car”—and that your personal device can be brought under VA control if needed.

This addresses some of the behavioral issues we've looked at that I mentioned earlier as BYOD. Certainly a lot of individuals may or may not want to comply with that. Bringing a personal device to work and using it in a mixed fashion can be a good idea, but if your organization is doing it appropriately, the individual has to understand that there's definitely privacy risks on their end. You're not getting unlimited use, you're basically sharing your device with your covered entity employer, so there's going to be limitations. For the individual, this may not actually be the right answer.


There are behavioral rules, as well as one thing that is to be the third bullet point there, rules of behavior required if storing VA data. It leaves a lot of questions I personally have as to encryption of that data and how that's going to be managed for data at rest, data in motion. Nonetheless, we're certainly moving towards in their case being able to speed up deployment of BYOD by removing it from central management.


Michelle: We're getting near the end here, so what this summary slide looks at is we're trying to move from a reactive posture, which says, “Oh my goodness, BYOD is showing up and I don't know what to do,” to where some organizations have moved saying, “Now I'm going to focus on the device and try to secure those,” to say, “Actually, you've got to look from a data-centric standpoint. Start there and go backwards.”

Where MDM is thrown around as an acronym quite a bit, it normally means mobile or master device management software. It also means master data management, and hopefully what we've looked at here in this webinar says, we've got to start with the data, look at our master data management approaches, have an enterprise information management strategy, and then include the devices in that.

Finally, by doing this, by adopting that enterprise information management, this is kind of your cheat sheet for the three minimum technical requirements of encryption of data in motion and two-factor authentication that are needed to comply with the HITECH Act regardless of whether the ePHI is on a mobile device or a desktop device, this is your same minimum technical requirements.

Once we've looked, our EIM strategies should include the policies that will address both behavior and management, looking at the wireless network and security of that within your network, looking at data segmentation, both logical and physical, of on-premise cloud environments as well as a judicious use of meta-data. Looking at customer support issues in heterogeneous devices, and don’t forget infection control, and the measures to utilize that with mobile devices, having appropriate medical security incident response teams and procedures.

My caveat that I'm going to leave you with today is vendor evaluation. There's the myth of the HIPAA housekeeping seal of approval. There isn't one. When dealing with vendors who will promise you the moon, like with anything, caveat emptor.

Your vendors should covered under business associate agreements. If they are not, then walk away. Certainly it's a complex environment, there's no easy answer. As an architect, I know frustratingly for folks, my answer is always, “It depends,” but taking the right approach will certainly mitigate risks for all.

Michelle: We've come to the conclusion of our content portion. If there's any questions, I know April has been tracking those. We'll be happy to go over those now in the remaining 10 minutes. If not, you don't have time or your questions are a little more elaborate, we will show our contact information again. I'd be very happy to follow up with you after the presentation. April, any questions?

April: Yes, thanks so much, Michelle. That was a great overview. One question that came up is do you have a recommendation for the best place to start for the smaller practice? I know you spoke about that this is a really big challenge if they don't have an IT department, so where do you think they should begin on this journey?

Michelle: There are actually a couple of places. One—This is a lot to swallow. We've really condensed it down for this webinar. I can't imagine a provider who is focused on delivering excellent patient care actually having the bandwidth to digest this. However, one of the best ways to start is OMC has created a game specifically for providers that allows you to do a little in-house assessment, learn more about privacy and security. It's available on their website. I also have a link to it on my website. It's a way to get your toes wet and figure out what do I know, what do I not know? It does a good job of helping you see what it is you need.

The next step is obviously the requirements for HITECH compliance are the same whether you're a large or small organization. Without a dedicated IT department or info-sec team to do the security risk assessments, PIA, PTA and all of that, probably the best way is to actually outsource that work.

It's something that you can't ignore. It is likely way too much for a small organization to try to do on their own. Perhaps outsourcing and working with consultants to do that for you is probably a better use of time. Still gets you your compliance, but without overburdening the practice.

April: Michelle, can you talk a little bit about the details on what that audit report or risk assessment would look like? What would you expect to walk away with?

Michelle: What an organization is going to see from that is a security risk assessment is going to look at the physical, technical, and administrative safeguards around both PHI and ePHI. It's basically going to give you a gap analysis of where are your holes? Where are areas of vulnerabilities, where are areas that are vulnerable either to threats, hacking, but also loss and theft as well as what we see as the inadvertent issues. Such as, can patients overhear data being shared about other patients? Your security risk assessment doesn't look just simply at your ePHI or your IT systems, but also your PHI.

It also looks at, for example, are your IT systems secure in the sense of, do we have two-factor authentication? Are your IT staff, if you are using these outsourced vendors or consultants that I recommended, are they following HIPAA guidelines? It looks at training, it looks at the risks associated. It gives a very comprehensive look at where the risks are and then can help provide a mitigation plan for those as well as bringing the organization into compliance in the long term. It's extremely thorough and is one of the required elements for compliance.

April: One more question we're going to sneak in here before we close out the webinar. Is it possible to be HIPAA compliant without performing that risk assessment?

Michelle: There's a difference between security and compliance. You could be compliant, but you wouldn't know because you wouldn't have done the assessment. Basically, and this is actually spelled out in the HITECH Act, these three elements—these weren't just made up. In order to prove compliance, having the appropriate documentation and safeguards is critical. They would be part of your compliance posture.

April: Super. Thanks so much. We're going to be respectful of your time here, and I want to just share your contact info, Michelle, with everyone. If you have follow-up questions, please feel free to send them to, and we will also be posting the recording of this webinar within a few days and we'll send that out to everyone who has registered.

If you are coming to any of the following upcoming events, we'd love to see you there. I know that Dr. Strah will be at the mHealth Summit in Washington, DC in early December, and look for us at HIMSS 2013. For those of you going to Des Moines, if you're in the Midwestern chapter, Online Tech will be there. We'd love to chat with you a little bit.

Thanks so much, Michelle, we really appreciated your time and expertise today and we look forward to talking with you more soon.

Michelle: Thank you, April, it was a pleasure. Looking forward to hearing from you all.

April: Talk to you all soon. Bye-bye.

marie-michelle strahMarie-Michelle Strah, Ph.D., Founder of Phydian Systems LLC
Marie-Michelle Strah, Ph.D., is a healthcare enterprise architect in the Washington D.C. area specializing in strategy, information architecture, information security and data architecture for federal and commercial clients. She is the founder of Phydian Systems LLC and an adjunct professor of Healthcare Information Technology at Catholic University of America.

She brings more than 15 years of experience in enterprise architecture, healthcare, information technology management, and research and development internationally, with specific depth of expertise in information security and compliance, organizational transformation, patient-centered medical home strategies and healthcare administration. She has worked in clinical (hospital and ambulatory), social services, large systems integrators and entrepreneurial settings and has led adoption of innovative Health 2.0, cloud, behavioral health, mobile and supply chain solutions for DoD, VA and HHS as well as hospitals, pharmaceutical and biotechnology clients.

Her projects include program management, enterprise architecture, system migration, data architecture and migration, security architecture and medical security incident response and solutions architecture across all HIT/HIS with particular attention to Microsoft SharePoint and Microsoft Dynamics xRM platforms.

Please visit her on Twitter or at her blog.

april sageApril Sage, CPHIMS, Director Healthcare Vertical, Online Tech

April Sage has been involved in the IT industry for over two decades, initially founding a technology vocational program. In 2000, April founded a bioinformatics company that supported biotech, pharma, and bioinformatic companies in the development of research portals, drug discovery search engines, and other software systems.

Since then, April has been involved in the development and implementation of online business plans and integrated marketing strategies across insurance, legal, entertainment, and retail industries until her current position as Director Healthcare Vertical of Online Tech.


Webinars    |    Online

Get started now. Exceptional service awaits.