gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] re: constraints in gmClinicalRecord (FYI) and gmEMRBr


From: sjtan
Subject: Re: [Gnumed-devel] re: constraints in gmClinicalRecord (FYI) and gmEMRBrowser, gmPatientExporter
Date: Fri, 22 Oct 2004 23:40:45 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

Carlos Moro wrote:

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

sounds good; sorry , I'm not very good at prospective debugging  ; )








reply via email to

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