the 2 developers karsten and carlos did a spell of extreme programming cooperation, and came up with quite a straightforward
ORM layer e.g.
create patient :
p = patient_module.new_patient()
p.set_names() , p.set_address(), p.set_birthdate(), p.save_payload()
retrieve patient by id:
p = Patient( id) # instantiate existing patient
do some work on the patient
c= p.get_clinical_record()
c.add_health_issue( ..'asthma' ,,)
c.add_health_issue(..'IHD'....)
health_issue = c.get_health_issue(name='asthma')
epi = health_issue.add_episode( ( today, 'mild exac') )
encounter = c.get_active_encounter()
subj = c.create_narrative( 'request script; using puffers < 4/24 today', epi, encounter)
obj = c.create_narrative( 'o/e pefr 75% pre , 95% post; good air entry bilat, audible wheeze clearing', epi, encounter)
ass = c.create_narrative ('mild exac asthma, oral steroid as worse than usual' , epi, encounter )
plan = c.create_narrative ( 'oral pred 50mg for 3 days; script usual reliever puffer, salbutamol ; followup tomorrow', epi, encounter )
The main conceptual difficulties is the difference between episode of a health issue and encounter ; encounter is just time and
place and persons , and can be associated with multiple episodes each dealing with a separate health issue.
also, episodes of a health_issue may run across several encounters. If there is a soap entry the next day for the example above,
it would probably bee in the same episode of asthma.
in terms of coding , python is a lot easier to read than a lot of other languages, and their ORM layer hides the complexity
of the sql schema just a little ( the sql schema really isn't that complex ).
the gui code may look a little complex sometimes, but if you think they are trying to achieve reuse , then it's easier to
understand why they use configurable soap containers, inheritance heirarchy for widgets , etc...
also , in their version of ORM , creating an object is saving the payload of the first version of the object, and updating or changing
information , then obj.save_payload() is used.
historically, they developed also with a concept of importers, and exporters, which are like the Facade pattern or Composite services
layer, and just handle some of the ORM manipulation as above.
On Wed Dec 28 23:32 , Richard Hosking sent:
This would be easier I presume that trying to do it all in SQL. However,
one of the criticisms has been that the middleware is too complicated.
R
[EMAIL PROTECTED] wrote:
>
>
> ? a smart python data object with a dumb sql skeleton
>
> *On Wed Dec 28 12:40 , Richard Hosking sent:
>
> *
>
> The gurus seem to be of the opinion that it is better to have
> smart data
> objects and dumb code to manipulate them.
>
> R
>
> Tim Churches wrote:
>
> >
> >>gnumed was originally concieved as "smart-server, dumb-client"
> >>model, with backend triggers doing all kinds of high-level
> stuff, like
> >>interactions checking.
> >>
> >>
> >
> >I am now convinced that this is arse-about, putting the back-end cart
> >before the horse, as it were. Better to put all the smarts in one
> layer,
> >the middleware, and use database back-ends in a dumb fashion, and
> >thin-client Web interfaces (so the interface smarts are very closely
> >integrated with the business logic in teh same set of classes in the
> >middleware layer, which all runs on the server).
> >
> >
> >
> >
> >
> >
> _______________________________________________
> Gpcg_talk mailing list
> [email protected]
> [email protected]','','','')>
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Gpcg_talk mailing list
>[email protected]
>http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
>
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
