Welcome

Lifedrivedoc.com began as a place to talk about the Lifedrive. It soon became apparent that it was much more than that. Since moving on from my Lifedrive, I am engaged in more avenues of technology. That technology has intersected with my professional life - Medicine as well as my social life.

As noted above, the blog is about a lot of things in relation to technology. If you are looking for Lifedrive related material, I am currently dividing the blog so that those searches will be easy for you to find. Most of them will be pre 2007, that should help. Additionally, if you are looking for the links that used to be on the left border. They will be back up in a different format soon. I do enjoy reading about new things to do with the Lifedrive, so you can feel free to let me know about those. I will also post those on the site.

If you are having trouble getting an RSS Feed, click on the feed link below or type this into your reader: http://feeds.feedburner.com/lifedrivedoccom


Enjoy.

Monday, September 05, 2005

Patient Databases

I have seen a few Patient Keeper Databases and I must say that I think that many suffer from a simple case of too much information. They tend to want to do too much and become extremely bloated.

Keep it simple. In my opinion, a patient keeper database for inpatients should consist of a few simple necessities:

1. Patient Name (Last,First).
2. A Unique Key (For repeat patients, it can become confusing if a patient is admitted twice in the same billing period). I like to use a name database now, since this tends to cut down on the amount of redundant information that one has to keep entering.
3. DOB.
4. Medical Record Number. (Preferably not SS number).
5. Emergency Contact or POA etc.
6. Optional Insurance Carrier.
7. Usually in a separate database for linking, the CPT codes).
8. I haven't figured out a way to simplify date entries, since CPT codes should
be billed on a daily basis.
9. A memo section, which pretty much could include a lot.
10. An alert function.

A few databases that I have used for the above are as follows:

1. HandBase. I stopped using this when they began selling separate ODBC products. Something that I think should have been included in the original software. Additionally, the GUI appears too "cartoony" and takes up too much space on the screen. It is also dreadfully slow when more than about 30 patients are in place.

2. Smartlisttogo (SLTG). I am currently using this and still love it. However, I have outgrown it and have found its main weakness is in database links. One can get lost in nested links in SmartList. And I have found out that I am not the only one getting confused. The program sometimes gets confused and links to the wrong database during programming. Additionally, some of the query options are nonstandard and become difficult to follow as you expand your database. But there is a lot to be said for a program that I have used for 4 years now. I have nothing against it, just a need for more. It is quite robust. I have had 200 patients in the database and there was little delay. On a lifedrive it flies.

As for ODBC and ActiveSync. A word to the wise on both HandBase and Smartlist.
IF YOU VALUE YOUR DATA, DON'T USE IT !!!!! Back up your data often on both products and use other alternatives to print it out or to exchange information. If you are a diehard and feel that you can't live without ActiveSync, then please back up your original.

I have chosen to send my data to the MemoPad, transmit it to my laptop via I-R and then print it out. I also use a Bluetooth and/or an 802.11g option with printboy for handbase (in the past) and there is a direct print option, which prints beautifully with the built in print feature on the Smartlist program.

3. Mobisystems Database. Well, I've graduated. I plan to experiment with this database for a while. I have written a PatientKeeper App, but I am still writing it. It is a lot more complicated to write it with Database (MBSDB) but it appears to be worth it. The forms are very compelling. Again, I don't like ActiveSync, and keep in mind that I am using the buggy LifeDrive, so I am already fighting the resets as I write the app. I am using the beta version of the program right now, but it is looking as though I will purchase the full Desktop version next week some time. It is quite powerful and I am enjoying it. I am keeping very much aware that the more relational databases that I link this thing with, I am in danger of encountering more errors. But after all, isn't that what programming is all about? Trial and error.

The one thing that I will miss, switching to Mobisystems is the active changes in fields that can be done with Smartlist. I haven't fully tested it out yet, but I think that modifications to the database causes resets to all of the fields. A major problem if I decide to add a field or two on the fly as I did in the first two years of using SLTG. Again, I am hoping to put up some these files for use by everyone. I love feedback as well, so that would be nice as well.

If I could get some feedback on this activity, it would be nice.

LIFEDRIVE DOC.

1 comment:

Anonymous said...

Nice entry to the space.
Keep up the good work.
Look forward to hearing
about your exploits.

Would certainly come in handy
where I work.

Thanks Again.

Dr. Ran Chaudry.