RON: Why don't we go in and why don't you kind of dive in and tell us about securing the data, some of the elements and some of the things that we need to address and consider when securing the data from an architectural perspective?
CHRIS: Absolutely. So really from a security perspective, there are some key pieces of securing the information that even if one layer of the onion (which is different from onion architecture), if you want to think of it as kind of a multi-layered process of security, even if one layer is breached, the actual ePHI data isn't going to be breached. And this is really fundamentally critical, again, to make sure that this information is secure. So the most fundamental thing is that the data, when it's going across the internet or over API calls, transferring between systems, et cetera, that it needs to be encrypted when it's going across the wire. And that's pretty standard today. You're probably not going to find hardly any communications that aren't encrypted. But you need to make sure that you're working with a provider who's doing that as a baseline. And then whenever the data is stored, typically in some form of persistence layer like a HIPAA-compliant database, it actually needs to be encrypted at rest as well.
And there are many platforms. A great example is Azure SQL that literally just have a setting where the data can be encrypted at rest, which is awesome. So literally your providers who are working with different hosting configurations, they can use these data persistence layers as a configuration setting, and you can just think very low cost, they can enable this encryption at rest. So you have encryption when things are going across the wire, and you have encryption at rest. The other thing is, overall, whenever data is accessed, we need to restrict who has access to what data. And so fundamentally this is something that we can do with multifactor authentication and roles-based authentication. And so basically what we want to do is essentially enable multifactor authentication so that whenever a user is logging in to a key role...and you can apply multifactor authentication for all kinds of different roles, but maybe for a key administrative role, there may be multiple layers of authentication that the user has to go through.
And we can look at things like the fingerprint of their machine or the device that they're using to access this data. So this could be a cell phone or a computer, and we can see the IP address and the device information whenever the request is made to access the data. So we can then complete multifactor authentication, which would be maybe sending them a text and making sure that they received it on the registered device for that user, and then it could also be requesting that they enter one of the three security phrases, and depending on how secure the data is, maybe there would be yet another step for them to authenticate. And these would all be things that would prevent someone who externally could have gotten access to one of these layers from penetrating through the administrative logins. But then once they get into the system, we also want to make sure that their roles authorize them to access only the data that they should have access to.
So we want to restrict the roles and restrict what access people have based on their roles, so that if something did happen, we can minimize the damage. And so these are really important concepts just as a general rule of thumb. The other things that we can do are set up intrusion detection so that if there is a breach or a potential breach of one layer of security, then we can enable more robust security overall and patching of the system. And then similarly, there's a concept where we can actually conduct white hat security breaches that are intentional, but that don't actually get into the ePHI data. So we can simulate what a hacker or a organization that's trying to access this data [will do]. Typically it's going to be some form of hacking, what would they do, and then get a detailed report on how to resolve that and reconcile it.
RON: One of the things I've heard a lot about are the benefits of tokenization. Is that something that you can explain?
CHRIS: Tokenization, you're right, it's really popular, because it's so powerful, and it's being used not just in HIPAA with PHI data, but also very commonly in the payment card industry, PCI DSS space, so data security standards that they have to meet. And it's really interesting, but the concept in general is, the data that is PHI in this case, or the data that needs to be secured is directly sent to a vault, and the vault takes that data. And typically, a vault is going to be much more high volume of secure data, and therefore the economies of scale are going to go to work for the vault that we're sending this data to.
So it's literally a electronic vault, if you want to think of it that way. It's typically going to be through a group like Azure HIPAA compliance or third party groups that are providing vaults where we can send information. And they know that we're sending them secure data, so we have authentication credentials, we have unique account information, and then they say, okay, you are who you say you are, we're going to take this secure data, it doesn't get stored anywhere in our system, it goes straight to this vault, and then the vault provider gives us a unique identifier back, and so the information is then permanently stored.
You can think of this as a Write Once Read Many or WORM type of access, but it's permanently stored, and it's basically put into this vault, and then all that we're storing in our system is this identifier. And it's really, really helpful to, again, set up additional layers of security. So where would this be used? Again, this would be used with some of the PHI data and just making sure that we have another layer of security. So if all the encryption at rest, if all the intrusion detection and the white hat hacking, all of that doesn't work, and someone still gets in, now all they have is this unique identifier, and then they would have to then additionally breach the vault in order to get at that PHI data. So really, really powerful, and you can set up multiple layers of vaulting too.
RON: That makes sense. It's almost kind of like a Dewey Decimal System, you can't get to the book, you only got the number of the book, and you can look it up. So that's kind of what the token is.
CHRIS: That's a great way to explain it. Yeah. So along the way, working on all of the various different projects that we've worked on, we have found that there are some really nice software tools and partners that we are glad to recommend. These do change over time, so instead of putting actual links and references directly into our slide deck, what we wanted to point out is that there are different aspects and different parts of the spectrum that these different software tools and partners will cover, and we do provide resources on our website, and we also will be happy to include, at the time of this webinar, some of those latest tools and resources that we're working with in the links in the description section.
But generally speaking, what you will want to consider is that there probably is a provider, a software tool, a resource that does some of these things that are complex with regards to HIPAA, like we were talking about earlier, Ron, with the forms. One of the other ones that we see a lot is the actual back office and non-digital and non-online compliance with HIPAA, and we've found some great partners that can help with that.
RON: Yeah. That'll do a lot of the business side. So it'll actually have, you can walk into it, and it'll literally have checklists for you who can say, who is your security officer? And you're like, wait, I have to have a security officer? And you click on the information icon, and it pops up and says, "the security officer's responsibility is..." And it tells you exactly what they have to do, and the typical roles in your organization have to do that, and what their responsibility are, and then you can record that. So there are partners and tools that we work with that we can not only develop a HIPAA compliant website or portal, but then we can work with a client to get their entire organization HIPAA compliant and maintain their HIPAA compliance. So if anything happened, they could produce all of the reports and all of the certifications necessary to show their adherence to the compliancy rules.