LBF reporting

aethelwulffe wrote on Tuesday, July 24, 2012:

Otay,
We are doing exported QA reporting to insurance companies (Social Services Stuff) based on data collected in an LBF.
Frankly, it is a lot simpler to create bookmarked queries for these reports (at the moment), as most must be exported as a spreadsheet or some other gowdawful format anyway, rather than creating a php report.

In a php report, you can run multiple queries or dump tables into an array and tweak them around to make them show up on a report, even when they are in a normalized table, like lbf_data. For straight queries using phpMyAdmin, this is a little more difficult.

-note: Following syntax is native to phpMyAdmin, not straight MySQL.

Code: Select all
    SELECT T1.`id` , T1.`date` , T1.`encounter` , T1.`form_name` , T1.`form_id` , T1.`pid` , T2.`field_id` , T2.`field_value` , T3.`policy_number` , T3.`subscriber_DOB` , T3.`subscriber_fname` , T3.`subscriber_lname` , T3.`provider` , T3.`pid`
    FROM `forms` AS T1
    JOIN `lbf_data` AS T2
    JOIN `insurance_data` AS T3
    WHERE T1.`date` > ‘2012-06-01 00:30:00’
    AND T1.`date` < ‘2012-06-30 00:30:00’
    AND T1.`form_name` LIKE ‘FARS/CFARS’
    AND T1.`deleted` =0
    AND T1.`form_id` = T2.`form_id`
    AND T1.`pid` = T3.`pid`
    AND T3.`type` = ‘primary’

OK, we have forms, lbf_data, and insurance data in this query. Fine. Unfortunately, for a layout-based form with 15 data points, you wind out with 15 rows of data in the query, with all the columns from the other two tables repeated each time.
Pray tell, what is a method of joining the tables where you have a single row that represents the joined data from (in this example) table form and table insurance_data, yet collate all matching rows from the LBF table into the same row?

…I am being harassed into dumping the LBF, and using a more manageable custom form with it’s own table, but we now have ~3 years of data, and a long history of manually grinding through the monthly reports…with historical reports demanded periodically. Furthermore, I have been assured that using normalized tables is the rightwise and godly way of doing things. So far I have not found anything to back up this particular philosophy, but I am trying to be a good Borg and learn.

HALP! I’mDrownding!

yehster wrote on Tuesday, July 24, 2012:

Art,
The trick here is to join on LBF_Data multiple times, but using a specific field_id.

Code: Select all SELECT T1.`id` , T1.`date` , T1.`encounter` , T1.`form_name` , T1.`form_id` , T1.`pid` , T2.`field_id` , T2.`field_value` , field1.field_id, field1.field_value,field2.field_id, field2.field_value, T3.`policy_number` , T3.`subscriber_DOB` , T3.`subscriber_fname` , T3.`subscriber_lname` , T3.`provider` , T3.`pid` FROM `forms` AS T1 JOIN `lbf_data` AS T2 JOIN `lbf_data` AS field1  JOIN `lbf_data` AS field2 JOIN `insurance_data` AS T3 WHERE T1.`date` > '2012-06-01 00:30:00' AND T1.`date` < '2012-06-30 00:30:00' AND T1.`form_name` LIKE 'FARS/CFARS' AND T1.`deleted` =0 AND T1.`form_id` = T2.`form_id` AND T1.`pid` = T3.`pid` AND T3.`type` = 'primary' and t2.field_id='fieldName1' and field1.field_id='fieldName2' and field2.field_id='field3name'

yehster wrote on Tuesday, July 24, 2012:

and of course you have to match field1.form_id=t1.form_id and field2.form_id.t1.form_id too.

aethelwulffe wrote on Monday, July 30, 2012:

Ah, good tinkin’ !  I’ll run with that to come up with a generalized “report on lbf” report.

aethelwulffe wrote on Thursday, August 09, 2012:

OK, here is a “I only speak 5 words of MYSQL syntax” Query that does the following:
Looks in table ‘forms’ for date range rows for a LBF form called FARS/CFARS; 
Draws up the Patient insurance data relative to the report being run;
Adds each field in the FARS/CFARS form layout as a join from lbf_data (there are a lot of them) and adds them to a horizontal row from the vertical table.

SELECT DISTINCT T1.`id` , T1.`date` , T1.`encounter` , T1.`form_name` , T1.`form_id` , T1.`pid` ,
T2.`form_id`,
field1.`field_value` ,
field2.`field_value` ,
field3.`field_value` ,
field4.`field_value` ,
field5.`field_value` ,
field6.`field_value` ,
field7.`field_value` ,
field8.`field_value` ,
field9.`field_value` ,
field10.`field_value` ,
field11.`field_value` ,
field12.`field_value` ,
field13.`field_value` ,
field14.`field_value` ,
field15.`field_value` ,
field16.`field_value` ,
field17.`field_value` ,
field18.`field_value` ,
field19.`field_value` ,
field20.`field_value` ,
field21.`field_value` ,
field22.`field_value` ,
field23.`field_value` ,
field24.`field_value` ,
field25.`field_value` ,
field26.`field_value` ,
field27.`field_value` ,
field28.`field_value` ,
T3.`policy_number` , T3.`subscriber_DOB` , T3.`subscriber_fname` , T3.`subscriber_lname` , T3.`pid`
FROM `forms` AS T1
JOIN `lbf_data` AS T2
JOIN `lbf_data` AS field1
JOIN `lbf_data` AS field2
JOIN `lbf_data` AS field3
JOIN `lbf_data` AS field4
JOIN `lbf_data` AS field5
JOIN `lbf_data` AS field6
JOIN `lbf_data` AS field7
JOIN `lbf_data` AS field8
JOIN `lbf_data` AS field9
JOIN `lbf_data` AS field10
JOIN `lbf_data` AS field11
JOIN `lbf_data` AS field12
JOIN `lbf_data` AS field13
JOIN `lbf_data` AS field14
JOIN `lbf_data` AS field15
JOIN `lbf_data` AS field16
JOIN `lbf_data` AS field17
JOIN `lbf_data` AS field18
JOIN `lbf_data` AS field19
JOIN `lbf_data` AS field20
JOIN `lbf_data` AS field21
JOIN `lbf_data` AS field22
JOIN `lbf_data` AS field23
JOIN `lbf_data` AS field24
JOIN `lbf_data` AS field25
JOIN `lbf_data` AS field26
JOIN `lbf_data` AS field27
JOIN `lbf_data` AS field28
JOIN `insurance_data` AS T3
WHERE T1.`date` > '2012-07-01 00:30:00'
AND T1.`date` < '2012-08-01 00:30:00'
AND T1.`form_name` LIKE 'FARS/CFARS'
AND T1.`deleted` =0
AND T2.`form_id` = T1.`form_id`
AND T1.`pid` = T3.`pid`
AND T3.`type` = 'primary'
AND field1.`form_id` = T2.`form_id`
AND field1.`field_id` = 'farscfars'
AND field2.`form_id` = T2.`form_id`
AND field2.`field_id` = 'ethnicitude'
AND field3.`form_id` = T2.`form_id`
AND field3.`field_id` = 'abusehx'
AND field4.`form_id` = T2.`form_id`
AND field4.`field_id` = 'assessmentpurp'
AND field5.`form_id` = T2.`form_id`
AND field5.`field_id` = 'evaldate'
AND field6.`form_id` = T2.`form_id`
AND field6.`field_id` = 'edumucashun'
AND field7.`form_id` = T2.`form_id`
AND field7.`field_id` = 'cfarnum'
AND field8.`form_id` = T2.`form_id`
AND field8.`field_id` = 'evalname'
AND field9.`form_id` = T2.`form_id`
AND field9.`field_id` = 'provmedi'
AND field10.`form_id` = T2.`form_id`
AND field10.`field_id` = 'countyserv'
AND field11.`form_id` = T2.`form_id`
AND field11.`field_id` = 'xxdep'
AND field12.`form_id` = T2.`form_id`
AND field12.`field_id` = 'xxanx'
AND field13.`form_id` = T2.`form_id`
AND field13.`field_id` = 'xxhyp'
AND field14.`form_id` = T2.`form_id`
AND field14.`field_id` = 'xxtho'
AND field15.`form_id` = T2.`form_id`
AND field15.`field_id` = 'xxcog'
AND field16.`form_id` = T2.`form_id`
AND field16.`field_id` = 'xxmed'
AND field17.`form_id` = T2.`form_id`
AND field17.`field_id` = 'xxtra'
AND field18.`form_id` = T2.`form_id`
AND field18.`field_id` = 'xxpot'
AND field19.`form_id` = T2.`form_id`
AND field19.`field_id` = 'xxint'
AND field20.`form_id` = T2.`form_id`
AND field20.`field_id` = 'xxhome'
AND field21.`form_id` = T2.`form_id`
AND field21.`field_id` = 'xxfam'
AND field22.`form_id` = T2.`form_id`
AND field22.`field_id` = 'xxadl'
AND field23.`form_id` = T2.`form_id`
AND field23.`field_id` = 'xxsoc'
AND field24.`form_id` = T2.`form_id`
AND field24.`field_id` = 'xxwor'
AND field25.`form_id` = T2.`form_id`
AND field25.`field_id` = 'xxcare'
AND field26.`form_id` = T2.`form_id`
AND field26.`field_id` = 'xxdan'
AND field27.`form_id` = T2.`form_id`
AND field27.`field_id` = 'xxdto'
AND field28.`form_id` = T2.`form_id`
AND field28.`field_id` = 'xxsec'

PROBLEM(s):
1.  This query just looks wrong.  Too many repeated operations.  Got to be a better way.
2.  Without using the DISTINCT function, I get endless seeming duplicate rows, presumably every possible permutation, or perhaps infinite (thank goodness for the LIMIT function when testing).
3.  The Killer:  How to do an IF or while statement  in MYSQL for when you have optional fields?  The normalized table does not use NULL or default rows!  For instance field21 and field25 look for a field_id of xxfam and xxcare respectively, and that will not exist in all forms.   I can find some kinda unrelated examples, but I would like to hear a suggestion that take into consideration the query sequence to ensure there is a value to bounce an IF off of, not to mention and optimization of the query method itself…before I add a few hundred more lines to this query.

  Folks speak regularly about keeping the processing at the database level, so I sure would not mind learning how to do this properly. 

aethelwulffe wrote on Thursday, August 09, 2012:

PS:
There is a flag value in the above form that indicates the two optional rows will be there, but for a more general LBF report tool, I think an IF loop (however the hell it’s done) that checks for SELECT COUNT or whatever would be the way to go.

mcaloon wrote on Thursday, August 09, 2012:

aethelwulffe,
  you most likely want to write a procedure where you can apply logic and looping capabilities.
Mac

aethelwulffe wrote on Thursday, August 09, 2012:

Mac,
I take is you mean procedure as “add a mysql function”?
-Art.

BTW…heh…seems like if I want to identify the insco in the above script, I’m gonna have to figure out how to diddly with the multiple primary (old) insurances with different effective dates….ARRRRGHHHH!

mcaloon wrote on Friday, August 10, 2012:

Art,
    Yes, a function is the term. I am going take a closer look at the query in a little more detail. Is there any way to get a hold of some of your test data? Specifically, a set of associated records from each of the three tables. Just remove any PHI if necessary.

Mac

mcaloon wrote on Friday, August 10, 2012:

Art,
    So to address your concern about “optional fields” you want to use ANSI compliant SQL syntax and use the LEFT OUTER JOIN on those “optional fields”. What this does is tell the SQL interpreter/compiler to take all the rows from your left table in the query and only the rows that exist from right table in your query. The resulting set will contain all your rows where all the JOIN statements result in data and for those rows where field21 and field25 contain matching rows, that data will also show up. I am assuming this is what you are looking to accomplish.

So you can see below that I am “selectively selecting” field21 and field25  when they exist. Also note that the query is a little shorter because the join syntax replaces a portion of your prior where clause.

Using distinct is one way to remove replicated rows. Using GROUP BY is the other. You want to GROUP BY all the columns that are being replicated.

Mac

SELECT DISTINCT T1.`id` , T1.`date` , T1.`encounter` , T1.`form_name`
, T1.`form_id` , T1.`pid` ,
T2.`form_id`,
field1.`field_value` ,
field2.`field_value` ,
field3.`field_value` ,
field4.`field_value` ,
field5.`field_value` ,
field6.`field_value` ,
field7.`field_value` ,
field8.`field_value` ,
field9.`field_value` ,
field10.`field_value` ,
field11.`field_value` ,
field12.`field_value` ,
field13.`field_value` ,
field14.`field_value` ,
field15.`field_value` ,
field16.`field_value` ,
field17.`field_value` ,
field18.`field_value` ,
field19.`field_value` ,
field20.`field_value` ,
field21.`field_value` ,
field22.`field_value` ,
field23.`field_value` ,
field24.`field_value` ,
field25.`field_value` ,
field26.`field_value` ,
field27.`field_value` ,
field28.`field_value` ,
T3.`policy_number` , T3.`subscriber_DOB` , T3.`subscriber_fname` ,
T3.`subscriber_lname` , T3.`pid`
FROM `forms` AS T1
JOIN `lbf_data` AS T2 on T2.`form_id` = T1.`form_id`
JOIN `lbf_data` AS field1 ON field1.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field2 ON field2.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field3 ON field3.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field4 ON field4.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field5 ON field5.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field6 ON field6.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field7 ON field7.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field8 ON field8.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field9 ON field9.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field10 ON field10.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field11 ON field11.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field12 ON field12.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field13 ON field13.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field14 ON field14.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field15 ON field15.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field16 ON field16.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field17 ON field17.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field18 ON field18.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field19 ON field19.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field20 ON field20.`form_id` = T2.`form_id`
LEFT OUTER JOIN `lbf_data` AS field21 ON field21.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field22 ON field22.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field23 ON field23.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field24 ON field24.`form_id` = T2.`form_id`
LEFT OUTER JOIN `lbf_data` AS field25 ON field25.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field26 ON field26.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field27 ON field27.`form_id` = T2.`form_id`
JOIN `lbf_data` AS field28 ON field28.`form_id` = T2.`form_id`
JOIN `insurance_data` AS T3 ON T3.`pid` = T1.`pid` 
WHERE T1.`date` > '2012-07-01 00:30:00'
AND T1.`date` < '2012-08-01 00:30:00'
AND T1.`form_name` LIKE 'FARS/CFARS'
AND T1.`deleted` = 0
AND T3.`type` = 'primary'
AND field1.`field_id` = 'farscfars'
AND field2.`field_id` = 'ethnicitude'
AND field3.`field_id` = 'abusehx'
AND field4.`field_id` = 'assessmentpurp'
AND field5.`field_id` = 'evaldate'
AND field6.`field_id` = 'edumucashun'
AND field7.`field_id` = 'cfarnum'
AND field8.`field_id` = 'evalname'
AND field9.`field_id` = 'provmedi'
AND field10.`field_id` = 'countyserv'
AND field11.`field_id` = 'xxdep'
AND field12.`field_id` = 'xxanx'
AND field13.`field_id` = 'xxhyp'
AND field14.`field_id` = 'xxtho'
AND field15.`field_id` = 'xxcog'
AND field16.`field_id` = 'xxmed'
AND field17.`field_id` = 'xxtra'
AND field18.`field_id` = 'xxpot'
AND field19.`field_id` = 'xxint'
AND field20.`field_id` = 'xxhome'
AND field21.`field_id` = 'xxfam'
AND field22.`field_id` = 'xxadl'
AND field23.`field_id` = 'xxsoc'
AND field24.`field_id` = 'xxwor'
AND field25.`field_id` = 'xxcare'
AND field26.`field_id` = 'xxdan'
AND field27.`field_id` = 'xxdto'
AND field28.`field_id` = 'xxsec'

aethelwulffe wrote on Friday, August 24, 2012:

Thank you so much Mac.

I had created two working queries (one with the two extra fields) which was a mess to use naturally.
Concrete examples such as this teach me SOOO much more easily than the formulaic stuff in the MySQL manual, or even short tutorial examples…which never seem to be quite what I am looking for.
  I’m gonna dig at your version until I feel I have learned everything there is to learn from it…and naturally, i am gonna run the sucker.

Here is my next puzzler:  Not against a different table orientation, but a similar issue:

SELECT DISTINCT T1.`code` , T1.`modifier` , T1.`date` , T1.`counselor_id` ,T2.`pid`,T2.`lname`,T2.`fname`,T2.`theprogram`,T2.`thecounselor`
FROM `billing` AS T1
JOIN `patient_data` AS T2
WHERE ((T1.`code` IN ('H2010','H0031','H2000')AND T1.`modifier` IN ('HO','HN'))OR(T1.`code`='000000'))
AND T1.`date` > '2009-07-01 00:30:00'
AND T2.`theprogram` IN('ARS','FES')
ORDER BY T2.`pid`,T1.`date`

The above query is just one experimental version of many I have tried.  The basic idea is that I am looking for billing items where some HCPC codes with certain modifiers OR an in-house code of 000000 (no, I didn’t come up with that one) is present.  I want to add patient specific data from the patient_data table to the results (name etc…) but I also want to only bring up billing lines where the associated patient has an assigned treatment program of ARS or FES.  Naturally, I get rows with the above query, but the amplifying patient data is all wrong.  Much easier for me to match up joins with tables that only have direct row correlations.  I figure that a sub-query (which I have not tried yet) might be the approach vs. a join.  But I dunno. I’m still trying to get my head around mysql operator precedence!

mcaloon wrote on Friday, August 24, 2012:

Art,
    Could you elaborate on “I get rows with the above query, but the amplifying patient data is all wrong.” It would be helpful to know what the “all wrong” means. Wondering whether some of your columns might need to use TRIM() to get rid of white space, that’s a speculative guess.

Mac

aethelwulffe wrote on Friday, August 24, 2012:

Yeah, seems like 0200 hour posts are a little “off” in their descriptive ability.
To the point, the query I posted is not a runner anyway, just an example of the items I am trying to pair into rows and a narrative that says what I am TRYING to achieve…Obviously, I have tried a dozen or so approaches and all have failed miserably, so I figured “just state what you trying to do, and don’t embarrass yourself by showing how you tried to do it”

I think that White space is probably the least of my issues.  I need Gray Matter.

When I run the above report.  I will get what might be the correct number of result rows (not verified, but seems reasonable).
I will get hundreds of rows that seem to be nonsense, with only one or two patients names because there is no criteria for the join itself, and the query just picks up the first match or something for the added patient data…

H2010 	HO 	2011-12-10 11:02:14 	57 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-10 11:13:36 	57 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-10 11:23:34 	57 	559 	Jackson 	Michael 	FES 	18
H0031 	HO 	2011-12-12 08:37:03 	57 	559 	Jackson 	Michael 	FES 	18
H0031 	HO 	2011-12-12 08:47:03 	77 	559 	Jackson 	Michael	FES 	18
H2010 	HO 	2011-12-12 09:10:32 	26 	559 	Jackson 	Michael 	FES 	18
000000 	  	2011-12-13 16:44:13 	NULL 	559 	Jackson 	Michael	FES 	18
H0031 	HN 	2011-12-14 16:17:28 	NULL 	559 	Jackson 	Michael 	FES 	18
H0031 	HN 	2011-12-14 16:17:47 	NULL 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-15 12:44:22 	31 	559 	Jackson 	Michael 	FES 	18
000000 	  	2011-12-15 20:28:31 	88 	559 	Jackson 	Michael 	FES 	18
000000 	  	2011-12-15 21:26:09 	88 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-17 10:12:48 	8 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-19 20:12:39 	40 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-19 20:16:38 	40 	559 	Jackson 	Michael 	FES 	18
000000 	  	2011-12-21 11:48:32 	88 	559 	Jackson 	Michael 	FES 	18
000000 	  	2011-12-21 15:05:19 	77 	559 	Jackson 	Michael 	FES 	18
H0031 	HO 	2011-12-22 15:47:25 	NULL 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-25 13:24:02 	53 	559 	Jackson 	Michael 	FES 	18
000000 	  	2011-12-27 09:20:02 	97 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-27 14:05:38 	31 	559 	Jackson 	Michael 	FES 	18
H0031 	HO 	2011-12-27 16:38:40 	57 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-27 16:43:02 	57 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-27 16:47:23 	57 	559 	Jackson 	Michael 	FES 	18
H2010 	HO 	2011-12-27 16:52:01 	57 	559 	Jackson 	Michael 	FES 	18
000000 	  	2011-12-30 12:34:13 	NULL 	559 	Jackson 	Michael 	FES 	18

Naturally this is because I am not joining the tables ON any particular value.  The issue is that it returns values with only a goofy date-time stamp different for many of them, that do not seem to correspond to a billing table row.
This query, a little more like something that could work, compares the ‘pid’ value in each table for the join, yet results in no rows returned:

 SELECT DISTINCT T1.`pid` , T1.`code` , T1.`modifier` , T1.`date` , T1.`counselor_id` , T2.`pid` , T2.`lname` , T2.`fname` , T2.`theprogram` , T2.`thecounselor`
FROM `billing` AS T1
JOIN `patient_data` AS T2 ON ( T1.`pid` = T2.`pid` )
WHERE (
(
T1.`code`
IN (
'H2010', 'H0031', 'H2000'
)
AND T1.`modifier`
IN (
'HO', 'HN'
)
)
OR (
T1.`code` = '000000'
)
)
AND T1.`date` > '2009-07-01 00:30:00'
AND T2.`theprogram`
IN (
'ARS', 'FES'
)
ORDER BY T2.`pid` , T1.`date`
LIMIT 0 , 30 

I have tried many arrangements, tried sub-queries etc… but I haven’t figured out what my major logic gap is.

aethelwulffe wrote on Friday, August 24, 2012:

OK Mac,
On the LBF table queries…
I got your query tested, and it only returned fields with the elements in the LEFT OUTER JOIN…meaning two results for the month.  They were easy to recognize as the correct ones at least!  Tried it as a Right Outer join…still the same results.  Is there an issue with running queries through PHPMyAdmin?

aethelwulffe wrote on Friday, August 24, 2012:

…Or do I need to look more into the Group By clause to use with your query structure?

aethelwulffe wrote on Friday, August 24, 2012:

…For which the documentation and Tutorials on Aggregate functions don’t really show me how they might help to return rows where the joined row fields are missing values….meaning there is no matching row.
How to do an IF statement where it joins the row if one exists, and defaults in a null value or blank string if it doesn’t…or is this just a case of the limits of SQL where you need to process the data in php?

mcaloon wrote on Saturday, August 25, 2012:

Art,
     phpAdmin shouldn’t be a problem that I’ve seen. You mention that you’ve been try different approaches and I can see your output results from the query. For me, what would be helpful is a small sample, just a few pertinent rows, of the cleansed (no PHI) input data that you’re using. This would include a few rows from billing and patient data tables in the query. This way we can review the code and evaluate the incoming data to see where you might be running into a problem.

Mac

aethelwulffe wrote on Monday, August 27, 2012:

Mac,
I have an sql file for the billing table (a mere 10000 rows or so) and a few hundred patients in a CSV file with field names.  The patient_data table has been butchered down to the relevant fields and only first name for PHI (so no last names in the query tests).   Hopefully that is easy enough to deal with, and if not, lemme know and I will make a stand-alone 2-table create DB query for you to use.
….And Thank you Thank you Thank You!

aethelwulffe wrote on Monday, August 27, 2012:

…oops!  http://starfrontiers.org/oemr/patient_data.zip

mcaloon wrote on Tuesday, August 28, 2012:

Art,
    I loaded the data up and ran the query you posted at the bottom of post #13 above. I removed the limit and got 184 rows listed below

counselor_id	pid	lname	fname	theprogram	theprogram2		thecounselor
108	25		Devlin	ARS			108
108	25		Devlin	ARS		thecounselor	108
108	25		Devlin	ARS			108
108	25		Devlin	ARS			108
NULL	25		Devlin	ARS			108
NULL	25		Devlin	ARS			108
NULL	25		Devlin	ARS			108
94	25		Devlin	ARS			108
108	25		Devlin	ARS			108
10	26		Samuel	ARS	Psychiatric	Transitional_Youth_Program	12
26	36		Bradley	ARS			53