Glad to help!

Thank you for the info guys. It is much appreciated!

Wow, Greg.  Great response.  To recap, yes, the RBS is all HIPAA compliant as well as CCHIT compliant.  When it comes to security and encryption, only certain things need to be stored in an encrypted or secure format.  Obviously security is one of these.  But another would be information such as certain medical records (i.e. the patient has some type of disease or is taking certain medications).  These types of things need to be stored in a manner that makes it difficult for someone to go into the database and just read this information.  But that doesn't necessarily mean that it must be encrypted.  In some examples, we will take collections and serialize them into a VarBinary field which is not readable in any way if someone were to hack into the database, yet it is not technically encrypted.  Make sense?  You want your application to be secure as well as fast.  So if you over encrypt...slowness will occur.  So think out of the box and be sure not to go too crazy with trying to encrypt too many fields.

I'm not a HIPAA expert, but from what I know, the RBS security will go a long ways in helping you get there. As I understand it, from a HIPAA stand point, what you really need to do is provide means to control access to private information of patients/clients etc. Only personnel that need access to this information should have access and those persons need to be accountable for how they use it. The data is typically stored in a database(s) of some type and accessed by an application(s). Thus you need to control access to the database(s) and to the application(s).



This fall under the HIPAA Security Rule (as I understand it), which relates to securing personal health information that is stored electronically. The language of the rules states that you have to use "reasonable and appropriate" measures to ensure the security of the data. Thus, if a trusted person is admin of the db and there are locks on the doors, with policies in place to control who has access, this might be enough to ensure that the data is secure. If the admin is a contractor or the servers aren't as secure, you might need to go the encryption route to ensure that no one who isn't authorized to view the data can get to it directly on the database.



Controlling access to the application can be handled beautifully by the SF's Role Based Security (RBS). There are two things you need to do:



1. Authenticate the user, so you know who is accessing the application.

2. Control access to data within the application via permissions assigned to known users



Using Windows authentication provides a means to handle the first item. Using the user's Windows login can ensure that you know who the user is via the domain login they use. Assuming the organization has good policies in place related to user accounts, this is great. The user only needs one user name/password, life is good. The RBS also provides everything needed for authentication, including forced password changes, strong password enforcement, password expiration, scheduled expiration (for contractors or if you know some is leaving) and disabling of users. This might needed if the organization doesn't use a domain or if they aren't strict enough related to users logging into their computers.



No matter how the user is authenticated however, the application needs some way to map that user to a set of permissions that will control access to the data. This means that even if you use Windows authentication, you will need to setup the user in your application, so you can assign permissions to them. This is handled very nicely by the RBS. Permissions are created that the application uses (SecurityKey property for forms and BOs). You can setup security from form level to field level. See the SF documentation for more info.



Another thing that is provided in RBS is auditing, which isn't quite complete yet, but the code to do the auditing is there and I believe you can control it via code as needed. This allows you to audit access to data (who/when/how). Do search here in the forum on auditing to get started there.



Of course, these software tools are designed to help the organization implement the policies that actually implement the HIPAA rules, so you need to understand the dental office's policies to fully understand how to support them in your application.



I'm sure the SF guys will have more information too! Hope that helps!

I am looking into working with a client who wishes to create an application that would be used in a dental office. This application would of course contain patient and dental information. So what I am trying to find out about are software requirements needed to make sure my app would be HIPAA compliant. Since StrataFrame is designed by those who make medical software I figured this would be a great place to ask.



Would just utilizing the encryption methods within StrataFrame and encrypting the data in the backend be sufficient?

When an authorized end-user uses the app, would I need to have my own security system for logins in place? Or can the end-user utilize their Windows login name to ease the pain of maintaining users and roles separately within the application?



Thanks for any help on this.

-Matt