[Top][All Lists]

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

Re: [Gnumed-devel] About EMR items Value Objects

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] About EMR items Value Objects
Date: Sat, 27 Mar 2004 09:52:05 +0100
User-agent: Mutt/

> I'm working in gmPatientExporter. It will provide human readable ASCII export 
> of patient record. It's data (eg. EMR) can be constraint by various 
> criterions, as in  gmClinicalRecord get_text_dump method.
Keep up the good work.

> I'd like to comment this design idea: In order to abstract and isolate any 
> kind of clinical items (vaccinations, allergies...), to be able to manage and 
> work with them, gmClinicalRecord would create (in a method with a logiic 
> similar to get_text_dump), according with data, different gmItemVO objects. 
This is, IMHO, the way forward. I'm pretty sure we've been
considering this before. There's snippets of vaccination items
in my tree (uncommitted). Also, Syan's gmClinicalPart() was an
attempt in a quite similar direction. Christof Meigen also
suggested this quite a while ago. IMHO it'd be a lot cleaner/better
for the "record" classes to return "value objects" instead of
lists most of the time.

Two thoughts:

There's no need to name them gm*VO. The very fact of

    vacc = gmVaccination.cVaccination()

and thus vacc being
makes it a value object, namely an instance.

I would just call them gm* or c*.

> Once we got them, we can easily work with them, eg. in text dumping their 
> information. The design would be somehing like this:
>       gmItemVO: parent class with  members and methods common for every item 
> type
>               id
pk -> primary key

Note that this is ambigous as one of those objects can span
several tables.

>       gmPatientExport would call gmClinicalRecord to obtain a list of items 
> and 
> iterate calling item.get_text_dump(), printing/exporting to file...
This still is but a better text *dump*. Eventually, for the
*exporter* I was thinking of a more formatted output, grouped
by clinical sanity (see that earlier mail). Yes, that's

>       I think these objects could be useful for other modules (in future 
> code), so 
> they could be located in client/vos...

I see no need for client/business/vos/.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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