Re: [Gnumed-devel] may help

[catmat]

Carlos Moro wrote:

> Hi Catman,
>
> Karsten solved it past week... a checkout and db redo should work...
> A pair or questions..  I've been looking at test area and seen your 
> java files for web client. Congratulations!, it's a verry good work. I 
> also program every day in java and struts... Is there any doc or could 
> you please tell me about the web client (requeriments, functional 
> objectives...)?  Regarding business code, it seems most of it should 
> be ported to Java... Do you know if it would be possible to use 
> /distribute python code so java clients could work with if? (i'm also 
> trying currently in an eclipse rich client based 'client' and it would 
> be great to use with gnumed)?
>
> Best regards,
> carlos
The objectives were assumptions about basic functionality of a  clinical 
entry app, which can be seen in Richard's requirements doc.
One ui objective was to display as much summary information in a 
standard  order  i.e.
Patient details, past history, medications, allergies, immunizations,  
habits,     followed by  a list of  encounters, with what the presenting 
complaint and what issues were covered in the encounter.
This is in the right hand of the entry area. 
In clinical entry,  often history , findings , actions, might get 
iteratively covered as a patient  reveals separate problems.
Karsten's  schema allows an encounter to be a container for an unordered 
list of clinical root items.  The clinical entry
is done by selecting  a health issue ( or default health issue),   
naming the episode of care, and  selecting the
SOAP type of the root item. If it is (O)bjective , a vital signs entry 
area comes up, and if it is (P) medications entry comes up;
for some reason, I tend to think vaccinations are given all as one job, 
so the vaccinations are already sitting there below
the list of clinical root items.   To enter another entry item,   either 
select *link* to make the next clinical item attach
to the current health issue , or *new issue* to start another issue. 
Once a new issue is started, no more clinical items can
be attached to the previous health issue.
In practice, this is a disadvantage, because one could forget to attach 
a P clinical item, and be unable to add medications
under a previous health issue.  Also, the functionality for  
re-prescribing old  medications  has not been done;
the traditional way is just to have checkboxes or other select mechanism 
against the current medication list,  but
this would not link to episode/health issues in the encounter.

With respect to business logic in python, I didn't think of that. There 
is already a moderately constrained SQL schema written by Karsten,
and I was expecting that any invalid data will turn up as  constraint 
violation error, and achieving the right validation
amounts to getting the constraint violation to go away, without changing 
the backend schema.

By the way it's cat*MAT* , a person who is a mat for a cat, not cat*man*.