Re: [Gnumed-devel] bootstraping v19 without starting from v2

[Karsten Hilbert]

On Tue, Nov 26, 2013 at 11:50:07PM +0000, Jim Busser wrote:

> 1) as far as server sql files, are the
> country-specific files all bootstrapped, regardless of the
> country where GNUmed is being bootstrapped,

yes

> 2) are the country-specific files intended (and properly
> capable) to be run only during an early stage (v1, v2)
> of a bootstrap,

yes

> or are these intended to be able to be run at
> any later time?

no

> 3) are the sql files which live at the first level under
> 'server' all

no

> run as part of creating v1 or v2

yes

> and therefore unintended to be reliably runnable
> at any later time?

yes

> 4) presumably all users (except any-doc) can be safely
> removed, while preserving any-doc mainly for the convenience
> of whoever would more fully set up GNUmed in the praxis

gm-dbo cannot be removed either

> 5) what table entries, if deleted, will risk to cripple GNUmed?
> 
> Safe for deletion should be all of the patient data, which would require to 
> first delete all data which links back to the persons, and then finally 
> deleting the test persons' names and identity records
> 
>       measurements
>       hospitalizations
>       procedures
>       medications
>       allergies
>       occupations
>       documents
>       vaccinations
>       family history
>       notes
>       encounters
>       episodes
>       waiting list items
>       inbox entries
>       invoices
>       billings
>       demographics
>       names
>       identities (except McCoy)

There's a script gm-remove_person.sh which can
help you with this.

> except that it could be desirable to keep some items, like generic 
> vaccinations.

Generic vaccinations can be recreated from the client
as long as vaccinable indications exist.

> What I am wondering is whether there are tables in
> GNUmed (other than users) which cannot be empty or
> else GNUmed will be borked, or will at least refuse to run
> until at least one row is added and populated through backend
> tools. Maybe each of the reference tables (encounter
> types. comm channels etc) will all need, or at least be good
> to have, at least one value before the GUI will be usable.

The encounter types come to mind.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346