gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Idea... cloning patients to facilitate GNUmed demo


From: Jim Busser
Subject: Re: [Gnumed-devel] Idea... cloning patients to facilitate GNUmed demo
Date: Fri, 10 Jul 2009 08:31:41 -0700

If and when this would be attempted, would the Person > Merge command already identify the tables that need to be touched? It would seem to me that the existing "Merge" feature may already be replacing the patient identifier in all records related in the merge and presumably causing the deprecated versions to move into the audit tables.

In the meantime, I am supposing that what I talked about is best achieved either by deleting all patients other than the one I wish to create (and export) -- or else starting with a fresh db and
- creating just the one patient
- dump the db, save as "One"
- within GNUmed, modify "one" into "two"
- dump the db, save as "Two" etc

that way, I can generate 3 versions of the dump, each with the data of a single patient.

Presumably the dumped data of a single demo patient would also be useful to inform mini-projects. Should such a demo patient better first have data entered in all tables, without which untouched (empty) tables may be omitted from the data dump?

On 9-Jul-09, at 9:38 AM, Karsten Hilbert wrote:

On Thu, Jul 09, 2009 at 09:14:01AM -0700, Jim Busser wrote:

Exists there a method for the entirety of a single patient's record (but only that *single* patient's record) to be "dumped" from the database?

We don't have code to do that. It would be desirable. It is
tedious to do, however.

Would that be useful to add to options in EMR > Export. ?

Sure !

Relatedly, is there a method of then reimporting that patient?

Given the above had been implemented this would be a tad
easier.

Presumably (hopefully) postgres would throw an exception on account of
duplication of the patient unique ID

it would

unless the import method would
assign a new patient ID, and preserve this across the related records
being imported across the other tables.

It would have to, yes.

If it is work to create an import method to support the above,

It would be quite a bit of work. A nice mini-project.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]