[Gnumed-devel] backup purposes (was Report)

[James Busser]

On 13-Sep-08, at 8:48 AM, Sebastian Hilbert wrote:
> On Samstag 13 September 2008, Rogerio Luz wrote:
> > I would like to generate reports as "Clinical Summaries of EMR" for
> > patients (back up purposes) and "Consultation Summary" to hand to  
> > each
> > patient in each visit.
> > Thanks :)
> >
> > Rogerio
> This looks like a case for the ASK a question section in Launchpad.
> My knowledge on this is limeted as well.
> What is your exact use case and what info do you want in the report ?

Rogerio,

I will leave the report aspect to the original thread.

The backups are best generated according to one of four methods or  
variations or parts... a minimum of two are recommended (in fact,  
less than two is likely foolish for a production system).

For a production system, whether or not you can afford "downtime",  
you must generate and preserve offsite backups. Offsite means if that  
if some or all of your computer equipment is stolen from one  
location, or if all of your equipment is damaged from one location,  
you will still be able to recover from some *other* location a recent- 
enough copy of all of your files (data) that anything that was  
missing would be able to be pardoned in the circumstances.

For offsite backup, this should be (at minimum) a "dump" of the  
entire current vX of the database which is in production, and this  
should be kept at minimum on CDs or DVDs or other writable media  
(could be a portable hard drive) in what I *suggest* should ideally  
be locked and fireproof. The locked part is avoidable if the database  
dumps would be encrypted before hand (which I suggest that they  
should be). The other encryption option would be to write them inside  
an encrypted container before writing onto a CD/DVD or else writing  
them into an encrypted volume on a portable hard drive. Network  
backup would be an alternative option and, in fact, we had a thread  
on gnumed-devel helpfully contributed-to by Tim (search "Amazon")  
about Amazon's S3 data storage buckets which I al already trying by  
use of $20 the connection client JungleDisk.

The above should be counted as two offsite backup procedures and I  
would recommend both, because you could have a critical technology or  
physical problem of either (plus a business insolvency or issue with  
one) and I think this redundancy is needed.

One of the above could have its place taken by a replication server  
which would act as one of the backups and which could be offsite. In  
the event of a sudden problem, as far as I know you would only need  
to adjust some configuration and the replication server could take  
over as temporary primary server while the real primary is fixed. But  
it then remains critical to re-map your other offsite backup  
procedure from this temporary server. This can be counted as the  
third of the four options. ***

Finally, we have some need to have in place a contingency or downtime  
procedure for when things go wrong. Some groups make sure that before  
the end of each day, they have a paper printout (or printed-to-pdf)  
version of the appointments for at least 3 days ahead. I would add a  
scripted ability to create an EMR summary for each of them, to create  
text or PDFs, one per patient, named by the convention
        DateAndTimeOfAppointment_LastNameFirstName
and saved into a directory on a machine which is not the EMR server.

In my mind there are two forms of the EMR to output. One would serve  
as a snapshot of patients, suitable to send to any consultant (whose  
copy, if they may want less, could have the excess deleted). Think:  
Demographics, Active Problems, Inactive Problems (Past History),  
Medications, Allergies, Test results (for each lab test ever done,  
the most recent value) and Document Results (at least for the most  
recent imaging done, the most recent report, maybe also the most  
recent 3 consultants' reports, including *all* consultant reports (if  
more than 3) from within the most recent 3 months. The rationale  
being that you may not have seen the patient in the interval since  
having last received the oldest of those reports and it may be for  
the purpose of reviewing / discussing any recommendations contained  
therein that you are schedule to see the patient.  Therefore you  
would want this available if there was "downtime". I would also  
include Additional Clinicians involved in care and the only other  
detail not specified is the extent of clinical narrative to include  
in the export. This paragraph overlaps with the blueprint for the  
"patient overview widget" however they are not the same.

The second form of the EMR to output would be the patient's entire  
history in a form that could be provided to a new doctor, who may  
inherit the care of this patient into an entirely incompatible EMR.  
At minimum this doctor should be able to import a document that  
contains the 5 or 30 or 100 or 200 pages of cumulated patient  
information, ideally in some kind of usable order. If a patient were  
going to be looked after by a doctor who also used GNUmed I would  
wonder if a dump of a single patient is feasible. Keys would have to  
be regenerated so I am not sure if such single-patient dumps could be  
imported, at least not directly. Perhaps such patients could be  
constituted in v_imported and then brought across laterally into an  
existing GNUmed.

=======================================

*** In the absence of a working replication server that can be  
switched over, the fact of owning dumps only gives you the ability to  
recover after a delay. This could be one or many days depending on  
having a suitable machines to take the place of the one(s) which are  
down. At minimum if you had some other machine in the office /  
practice that was already set up with a current Debian testing, then  
I expect within one or two hours you -- or your IT support -- could  
reconfigure postgres and deploy a resurrected Gnumed server on that  
*one* machine. Depending on your network and the capacity of the  
machine it may be easy or hard to get other machines in the praxis to  
connect to it. If it was me, I would already have this back-up  
machine "ready to go" with Postgres already suitably configured.

I do not know whether there is any additional complex procedure to  
revive GNUmed server on a new machine, provided the Postgres got  
suitably configured. Shall we add to the Blueprints the need to  
develop and document the restore-from-dump procedure?