There are good reasons to store HealthFrame data where we currently store it (its the standard windows-defined place to store application data).
Allowing users to change this location - while not very hard - is not easy (must be very careful about when it changes how to COPY existing data - and deal wtih possible conflicts).
Our current belief is that there is no good reason to support this.
BACKUPS and EXPORTS are another matter. And here - we plan for HealthFrame v3 (this is the only major feature left before we're ready for release) - we plan a new mechanism called "Synchonization" - which is planned to allow setting up automated backups of PHRs (backups or exports) anyplace you'd like (including eventually to NETWORK locations) (our internal tracking bug report for this is http://bugzilla/show_bug.cgi?id=114).
We THINK this will address the most important criticism we've seen leveled against how we store data - that it must be EASIER to automate backups - and get the backup data stored where users want it.