[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: Keeping gnumed focussed toward 0.1
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Re: Keeping gnumed focussed toward 0.1 |
Date: |
Thu, 17 Feb 2005 21:01:26 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> 1) if (user and) patient are defined automatically, would patient
> occupy the value for gmDemographicRecord.cIdentity, such that using
> it to denote the referral doctor or therapist (the "referee" as
> defined in the referral table) creates a conflict?
I'd assume they'd be two different instances of cIdentity.
> 2) in the manual, are we envisioning the Administrator as a person
> with network management (sysop-type) skills *maybe* able to modify
> their own forms,
Yes. When I started the "Administrator Guide" I was thinking
of the DBA/sysop/IT person type admin. They may or may not be
able to define forms -- but based on lacking medical rather
than technical knowledge.
> or will we consider Administrator to be an "office
> manager" who would add and configure users, reset passwords, adjust
> GnuMed privileges and liaise with the installation's IT support but
> have *limited* computer skills outside what the gnumed GUI provides?
Those would be called "GnuMed Managers". They would certainly
be the ones defining forms. At least that is what I intended.
They somewhat overlap with "power users" (that is, not all
power users will be gnumed managers but all managers will be
power users). The User Manual Part "Advanced Topics" is for
them.
> I thought of #2 to clarify how forms would be relevant. If for
> Administrator we are to assume moderate sysop skills, then the wiki
> Forms topic should be linked to the Manual?
There need to be two topics, one discusses the technical
details, concepts, tables etc - this belongs into the dev
guide. The other gives a description on *how* to add/modify a
form. This belongs into User Manual.Advanced Topics. They may
or may not be a place for a paragraph on how to re-install
standard form templates etc which would then belong into the
Admin Guide.
> Whereas the "manager"
> level person may just need to know to refer questions to their IT
> support who would need to create or modify forms (provided these
> people are, or can get, comfortable with Latex). It is a question
> worth answering for more general planning and organizing of the
> manual.
I would hope to get power users to handle form definition.
Thereby leveraging the user base.
> 3) I noticed in the schema
> - form_defs, form_fields, form_type
> - form_instances (and the "holders" form_data, form_fields)
form_fields is not a holder
> - form_job_queue
> - paper_sizes
> - referral
> - clin_medication
>
> I gather these and the new approach to forms remain aligned, or is
> any schema tweaking required?
The tweaking would amount to a complete rewrite if I correctly
understand what Ian is proposing.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346