Dead-End With .dbf: Seeking Advice On Conversion to SQL

[drjgs200]

Introduction:
For the last 10 years our hospital-based physician group has been using Excel to record, store, and analyze our physician-patient encounter data. Since the
Excel data has been stored on an intranet share-drive, accessible only to the physicians in our group, the data has not been password protected nor
encrypted. Neither our compliance nor IT departments have ever raised any concerns regarding HIPAA complaince - at least as it relates to our Excel data.

It was in this context that I decided to upgrade our 'database' by creating an Alpha Five desktop application. The A5 dbf files would be stored on a
share-drive analogous to the share-drive that housed our Excel data. Therefore the A5 dbf files would be at least as secure as our Excel files had been. In fact, with the added A5 password protection and encryption (such as it is), the dbf files would be even more secure. In addition, one of our hospital IT managers told me that HIPPA rules were independent on any particular technology - i.e., as long as I had adequate password protection, the dbf files would be acceptable in this case.

The Meat:
Unfortunately, now that my A5 application is nearly completed and ready to be installed, another member of our IT department is now raising a red HIPPA flag about the dbf issue. I am now told that HIPPA rules have some very specific technological requirements. In particular, dbf files are apparently not acceptable. I am told that the database must be an sql database. So, at this point I would like some expert advice. What would be the least painful way to re-cast my application? Keep in mind that this was my first A5 project and that I still consider myself an A5 novice. Some ideas that have occurred to me are:

1. Start from scratch with a web application based on a sql datatbase? Even though my current app is comprised of only a single, 2-table set (one-to-many), it has about 20 forms. Therefore, re-casting would not be trivial. Also, I currently know next-to-nothing about developing a web app.

2. Keep my current desktop forms and layouts, but somehow incorporate 'direct sql' to populate an sql database. For this reason, I have watched all the following videos: http://wiki.alphasoftware.com/Learni...ith+SQL+Tables. Though I understand the general principles presented, I am having difficulty understanding how I can incorporate these xbasic/sql commands into my current application.

3. Pay someone to do one of the above.


Any thoughts? Any advice?

Thanks,

Jim

[Tom Cone Jr]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Jim, while I understand that "he who has the gold makes the rules", you might want to inquire a bit further. While standard DBF formatted data can be read (or even written) by many tools, once the data is encrypted that's no longer the case. There may be other valid reasons for shifting to a different format, but I'd be surprised to learn that the HIPAA Rules themselves mandate SQL formatted data.

[drjgs200]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Tom, other than the HIPAA concern, I have no compelling reason to change at this point. However, though I am hesitant to draw more attention to this issue, I will inquire further. The more I look into the HIPPA regulations, the more it appears to be a 'can of worms'. If I get push-back on the dbf issue and am forced to migrate to sql, do you have any further thoughts on the best way to do it? Thanks.

Jim

[Peter.Greulich]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Jim, by the numbers:

1. I realize you may have very complex forms, but a single 2 table set and 20 forms is pretty small. If you really need to go to sql, see if you can use active-link tables. The one down-side is that others have complained that active-link in sets is unacceptably slow. The workaround would be to base your active-links on sql views.

2. -

3. If you want to hire someone, check out: http://www.alphadevnet.com/index.a5w

[Finian Lennon]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

I second Toms' comments. As I recall the HIPAA rules are/were defined in a quite general way and I don't recall any specific data storage or encryption technology being mandated. Beyond that, many of the regulations specifically applied to "open networks" which most in-house LANs are not. So I think you could be HIPAA-compliant using dbfs.

OTOH, the way of the present/future for medical practice management applications is to have an Electronic Health Record component that would qualify for the Medicare incentive program. In that program, storage and encryption technologies and standards are very specifically mandated and only a system based on a client/server database engine would be able to qualify.

[drjgs200]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Thanks for your reply, Peter. In fact, I have tried to use active-link tables with my app. As others have indicated, though, their response was painfully slow. As you said... unacceptably slow - even with just the 2-table set.

But, even if the slowness of active-link sets was not a problem, I don't see how active-link tables would help me with my dbf probllem. Active-link tables ARE dbf tables, are they not? Are they not dbf tables that are populated 'on the fly' according to the contents of the back-end sql tables? As I understand the HIPAA concern, these dbf tables represent the security risk.

The workaround would be to base your active-links on sql views.

Finally, this comment intrigues me. I don't know what it means though. I don't think I have heard of 'basing active-links on sql views'. Can you explain this a bit further... maybe post a reference link. Thanks, Peter.

Jim

[drjgs200]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Finian, your comment is very interesting. You implied that CMS (the medicare people) may have strict technology specifications only with respect to the 'Meaningful Use' initiative. I find this interesting because the IT guy who told me that my database needed to be an SQL database is the guy responsible for bringing our hospital into compliance with 'Meaningful Use'. I am not concerned about meeting criteria for 'Meaningful Use' (we already achieved that). In other words, he may have his IT wires crossed. You may have identified a ray of hope for my dbf files. Now I am emboldened to investigate further :)

Jim

[Ted Giles]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Jim, I have done a lot in the UK with highly secure data. Both SQL and DBF.
The issues I faced were the problems of access to data and the legal admissibility of elecronic data in court.
I realise that the UK and US are dufferent in terms of laws and processes, but the overriding principle is probably that non authorised users cannot get at the data, that it is secure, it can be replicated in its original form, and that it is accurate.
No matter what the database medium, this has to be achieved. SQL is no more secure than any other medium.
The SQL system was a ESCR (Electronic Social Care Records) system which handled very sensitive adoption type data, and three DBF apps - COPD, Psychometric Evaluation and Social Care Protection of Vulnerable Adults.
With password protection and defined processes for security and backup together with a description of the security you intend to impliment (encryption) - you will need to write these in order to satisfy your IT guys.
FWIW, one of the UK advisors on security had a look at the Alpha encryption and found no easy/dedicated casual attempt, to break it.
Only one issue. There have been a few hiccoughs with encrypted data not working correctly as the password was suddenly unrecognised. Best search for encryption before you make a decision.

[G Gabriel]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Go to cms.gov
You will find the answers to your questions. Also, there is a link there where you could submit a proposed IT system and they will let you know if it is acceptable or not.

[drjgs200]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Thanks Ted and Mr Gabriel. I have just spent the last couple hours researching the links provided by Mr Giles. Ted, from what I read, you are correct - the HIPAA guidelines are largely technologically neutral. The take home lesson appears to be that I must take reasonable measures to protect the integrity and privacy of the patient data. I must also develop a written policy on the how's and why's of those measures. These measures will obviously include password protection, encryption, and a digital audit trail.

Ted, regarding the encryption glitch that you mentioned above..... I have read some of the threads on this. They definitely gave me the heeby-geebies. Until this issue is better understood and 'fixed' I will have to stay away from encrypting tables. Do you know if there have been any issues with encrypting individual fields? For example, I could use 'encrypt_string()' and decrypt_string() on just the fields that identify the patient (name and med record #). What do you think?

Thanks,

Jim

[G Gabriel]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Incidentally, you could password-protect your Excel files in more ways than one, but it seems that you moved beyond Excel.

[Mike Wilson]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Jim,
Sorry I didn't see this thread yesterday. I am a physician also. The critical 3 elements for HIPAA compliance relate to access, access and access. If your data is on a LAN, the LAN should be password enabled, I would presume. Also, the LAN manager software should have the capabilitites for folder read/write access restrictions. Placing the patient data into a folder that has user access rights restricted behind the LAN password is actually sufficient to comply with HIPAA regulations. Add to that the password protection you place into your application. The rules in HIPAA are designed to be complied with at a level of credible access restriction and audit trail enabled. The requirements are not at a level requiring the data be within a framework that is hack-proof. I don't believe your IT person is giving you the real scoop, but delivering an opinion likely tainted with bias and agenda.

[Ted Giles]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Jim, I wouldn't go the route of encryption. That isn't the issue. Unauthorised access is and as Mike points out, this is the critical area of interest.
A robust password system where the user is forced to create a new password every 28 days is good, also when a new user is added, the business rules are followed to ensure bona fides.
If your operation uses Active Directory and has a solid firewall that can be evidenced, that should suffice.

At the end of the day, the processes are only as good as you make them and can apply them. I sure that have some standards and procedures - UK but should give you a lead - if you want me to look 'em out.
Enforcing them is a load of fun. I have blocked Director Level access when they didn't follow or abused the rules. (Automating is saves you from the company stocks in the car park. )

[drjgs200]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

Thanks Mike and Ted. Your comments are very sensible and reassuring. You have prevented my descent into despair. :) Next week I will get back with my hospital IT guy who initially indicated that dbf files would suffice. I will let him take care of the LAN access issues. So, in addition to the LAN access issue, do I need a robust digital audit trail? I understand that A5 has a built in basic audit trail. Would this audit trail suffice?

Jim

[Ted Giles]

Re: Dead-End With .dbf: Seeking Advice On Conversion to SQL

The Audit Trail would probably do Jim.
Once the Alpha Security is applied and users need to sign in, the name of the user is placed in the Audit Trail together with the before and after content of the record.
Don't forget to implement a cycle of backups - not just one - do them daily for 7 days so you have 7 separate backups, weekly for 4 weeks and then monthly. The IT guy will or should know about this.
You might also want to consider a Print Server as well. This is where the nightly backup is used as a database to simply provide reporting, and it's a max of 24 hours out of date.
Some real-time reporting can clog your system if there is a load of data.