[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/1.3.22.1i |
> 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
isinstance(cVaccination)
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
harder.
> I think these objects could be useful for other modules (in future
> code), so
> they could be located in client/vos...
client/business/
I see no need for client/business/vos/.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346