[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re: constraints in gmClinicalRecord (FYI) and gmEMRBr
From: |
Carlos Moro |
Subject: |
Re: [Gnumed-devel] re: constraints in gmClinicalRecord (FYI) and gmEMRBrowser, gmPatientExporter |
Date: |
Thu, 21 Oct 2004 23:27:21 +0200 |
User-agent: |
Mozilla Thunderbird 0.7.3 (X11/20040905) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi ,
sjtan wrote:
| The items returned by fetch_filtered_items() form the basis of
| which encounters, episodes, or health_issues can be seen, sort of a
| bottom up build.
Correct. Here's the conceptual bug... We're currently filtering the
items in the emr (building the higher structural levels from them)
rather than, hierarchically filtering the emr skeleton. I mean, if
currently we filter by dates 2004-01-15 until 2004-02-15 and health
issue id 2, all items (an OR of items) into both categories are
considered and then encounter->episode->health issue is built....
wether or not items into date range belong to health issue 2.
Fixing at it now, what do you think about this approach?:
~ -According to cClinicalRecord:
~ def get_health_issues(self, id_list = None):
~ def get_episodes(self, id_list=None, issues = None):
~ get_encounters(self, since=None, until=None, id_list=None,
episodes=None, issues=None)
~ -Filter hierarchically from top to botton, applying available
criterias for each element:
~ healh_issue -> episodes -> encounters
~ ...and at the lowest level and last step, obtain items that
belong to displayed encounter.
~ In the example above, only encounters in that date range would be
shown. And, always, only items for resulting filtered encounters will
be finally displayed.
Best regards,
Carlos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBeCm55BCD+/pQ4WIRAi6YAJ0alPPnJ4CcITyBnY8FhWHzOz2YwACgjwfI
BSMAQDGtiAKRyg91zvIOWkc=
=Du0U
-----END PGP SIGNATURE-----