Database Documentation

[pri2si17-1997]

Hello @aethelwulffe @teryhill @tmccormi

This issue is regarding proper documentation of database and its tables. We can have simultaneous update in table structure if needed and add it here.

[pri2si17-1997]

All the above is irrelevant in any case

Means?

I will discuss with Ujjwal about these tables.

And what about users table. I posted on forum, but I haven't received any feedback. I will not drop salt* column until I implement that myself.

[aethelwulffe]

It is irrelevant since those tables are being thrown out (presumably) along with the old calendar system.

I answered on the user table bits pretty clearly (forum, chat), stating that you were looking fine there...with the exception of the worries about the salt storage fields (current, history) which I deferred to someone that knows what they are doing :)

The background_services and batchcom related stuff I will have to figure out myself.

provider_name seems like it would be a field that supplies the provider's name like "Dr. Priyanshu Sinha" that the patient is scheduled with. email_sender will likely be the replyto for constructing an email smtp, and therefore structured as an email. I would have to verify this in the code. It could just be a log of a user, it could also be the clinic's name that will be added to an email subject line. Gotta look at the code.

The document categories and category sequences are the categories and order of the patient document trees. config and config_sequence are tables we have already gone over higher up this thread.

We have also gone over the facility table a bit, but I will make sure you have that one down pat.

INSERT INTO `facility` (`id`, `name`, `street`, `city`, `state`, 
`postal_code`, `country_code`, `federal_ein`, `service_location`, 
`billing_location`, `accepts_assignment`, `pos_code`, `attn`, 
`facility_npi`, `tax_id_type`, `color`, `primary_business_entity`) VALUES
('1','Our Clinical OFFICE','112 wherever SQUARE SUITE 
200','Ourtown','VA','330303030','USA','123456789','1','0','1','11','Billing','1942300298','EI','#FFCC99','1')

Aside from the obvious stuff:

• federal_ein is a tax identifier for the business.
• service_location means it is a type of facility that shows up in the
• encounter form as a Service Location.
• billing_location means it shows up in the form_encounter in the
• dropdown for Billing Facility. Both functions are vital.
• accepts_assignment is a flag that controls how payments are processed.
• pos_code is a vital code that is pulled from the Service Facility in
• an encounter that indicates what type of place of service it is, such as
• Office, Inpatient Hospital, Home, Mental Health Facility etc...
• attn is a field for a value like "Claims Department" or John the Billing
• Desk Guy".
• facility_npi defines a Group National Provider Identifier, or a kind of
• UUID.
• tax_id_type indicates if it is a Employer ID Number or a personal tax
• number.\
• color is a filed used in the old calendar system (and probably new
• system) to mark what the physical location of a appointment is so the
• user can visually sort them.
• primary_business_entity identifies if this "facility" is a listing for
• the actual business running everything

Primary Business Entity provides electronic and invoice systems with the tax ID data, and a few other things. Billing Facility provides Group NPI numbers. Service Facility provides the place-of-service code (office etc...). One facility may be all three of the above.

[pri2si17-1997]

Ok @aethelwulffe Thanks.. :slightly_smiling_face: Now I will implement those tables.

Here are two more tables :

1. amendments

id int(11) auto-increment primary key, amendment_date date not null, amendment_by varchar(50) not null, amendment_status int(1) not null, patientID foreign key references patient_data.id, amendment_desc text null, created_by int(11) foreign key references users.id, modified_by int(11) foreign key references users.id, created_time timestamp not null, modified_time timestamp not null

2. amendments_history

id int(11) not null primary key auto-increment, amendmentID foreign key references amendments.id, amendment_status int(1) not null, amendment_note text null, created_by foreign key references users.id, created_time timestamp not null

I will update with more table structures soon... :slightly_smiling_face:

[aethelwulffe]

Note on Amendments. You are still under the impression that using the id from the patient_data table is a valid use. The id there is a row number, but should not be used due to a number of reasons. The proper key to use to link to the patient_data table and any other tables that link to it is the pid field. Yes, it is possible to use the id field, but there are a huge number of scenarios where this would be problematic.

[pri2si17-1997]

@aethelwulffe Yes, I will change that. I have made pid unique, and now I can reference that.

[pri2si17-1997]

Hello @aethelwulffe

Now I am done with all forms. I have few doubts :

• I am not able to process care plan, functional and cognitive status and observations. So I am not able to find which field will store what value?

• Also in procedure order, I don't know what last two fields are, namely procedure and diagnosis codes. I followed Kevin's suggestion and tried nhanes.librehealth.io , but these forms are not enabled after installing them from globals.

• In almost every form, there are four common fields as provider, groupname, authorized, activity. Provider seems to be user. Authorized is also part of user. I don't know about groupname and activity. So please help me here. I think groupname has something to do with groups table. But not sure.

• Also some forms contain field encounter and some not. So should I include this field in every form. As they are linked with encounters only. Or I shall drop from all tables containing it, as we have one table forms which contain the patient and encounter information. So what you say?

• In form form_vitals, there is one field external_id. What is this field all about?

• In which table work/school Notes are saved?

• Tell me if any of the form_* tables are not used and need to be dropped.

• Also, please give me some details of form_encounter table's fields leaving the obvious field.

[aethelwulffe]

_I am not able to process care plan, functional and cognitive status and observations. So I am not able to find which field will store what value?_  Care plan is a ZEND module thingie, and does not work.  I will have to look into the cognitive status and observations forms, as neither one of them are actually clinically useful here in our mental health clinic, so I have never used them.

_Also in procedure order, I don't know what last two fields are, namely procedure and diagnosis codes. I followed Kevin's suggestion and tried nhanes.librehealth.io , but these forms are not enabled after installing them from globals._  Procedure code is typically a CPT4, HCPCS, or ICD-10 PCS code.  These are five character codes that identify an intervention...meaning "something was done".  For a procedure order, these will be something like "93531" which is a  Combined right & retrograde left heart catheter.

These should also have the ability to handle another associated field, or should allow delimiters to add a modifier. A procedure with several modifiers is possible. In a single field, it is typical to annotate them like "99021:25:VR:50" (not a real set of modifiers..just an example). The diagnosis code is the justifying diagnosis for requesting (ordering) a procedure. diagnosis codes are commonly ICD10-CM codes. An example would be F41.9, which is Anxiety Disorder, unspecified.

_In almost every form, there are four common fields as provider, groupname, authorized, activity.
Provider seems to be user. Authorized is also part of user. I don't know about groupname and activity. So please help me here. I think groupname has something to do with groups table. But not sure._

Groupname is crap, and does nothing. The form structure seems to think it is important. Arguments for retaining and using the "groups" feature have gone around and around, but it is basically a bunch of unused variables that created dependencies that break things, but are not implemented in a meaningful way for access control, organization, reporting or anything. Authorized means "a clinician (physician, etc...) has verified this form as part of the client's records. Activity is a delete flag, meaning a 0 is supposed to be deleted. Implementation of this is inconsistent. Provider is initially set to the user, but when an encounter has a fee sheet filled out (billing table items are associated with that encounter number) then the feesheet sets the Provider fields to equal the "Rendering Provider" choice in the fee sheet. Fields named "user" such as in the form_encounter should retain the user ID of the last person to edit them.

_Also some forms contain field encounter and some not. So should I include this field in every form. As they are linked with encounters only. Or I shall drop from all tables containing it, as we have one table forms which contain the patient and encounter information. So what you say?_

When you look (select) a patient, the forms table is queried. This looks for all form_encounter rows linked from the forms table for that PID. When you select an item from the "Encounter History", you are selecting a row of data from the forms table, which gives you the form_encounter listing to display that "top level" form (which is where you get the date of service in the drop-down menu). When viewing that encounter, the forms table is again referenced for all other forms that are linked to that encounter number. It is possible to not need the encounter number in the form, but there are some reasons it is best to retain that vs just depending on the link list. I will try to bring up an example of that, but frankly, reporting and the like is easier when you have bi-directional links.

_In form form_vitals, there is one field external_id. What is this field all about?_  that would be to hold an ID number from some other system, such as another EHR, an assigned ID that exists on a proprietary medical device or the like.

_In which table work/school Notes are saved?_ Got me.  I would look at the form directory for a file called save.php or table.sql

_Tell me if any of the form* tables are not used and need to be dropped._  That would be a matter of preference for the user, but the question of what forms to include as "canon" for the application is a totally different discussion.  I will give you a review as I can.

_Also, please give me some details of form_encounter table's fields leaving the obvious field._  I believe I went over this with the facilities table discussion some already.  I will provide a full list after my 4:00 meeting starting just about now...

[pri2si17-1997]

@aethelwulffe

Can you please tell me about form_encounter table? There are some fields which are not in facility table. If you are free then please elaborate this. Also, the x12_sender_id in facilities table is not linked with x12_partners table? I looked at x12_partner from Administration->Practice and we are entering sender id as input, so I think that it is not related with that. But you know what actually is?

[aethelwulffe]

INSERT INTO form_encounter ( id, //row id date, //Date of Service...not create date reason,//freeform text like "Patient reports piece of crayon up nose" facility, //the SERVICE FACILITY NAME that has the place of service code (11 for office etc..) facility_id, //the id of the above. The name is preserved due to edit/row index possibilities in the facilities table. pid, //The patient this belongs to. encounter, //The encounter number which is the primary linking key onset_date, //The date that the patient reports current issue is linked to. Defaults to NOW() sensitivity, // A flag that restricts access (normal vs High sensitivity) for VIP's or anyone who requests it. billing_note, // an accounting note that applies to just this encounter (but not the patient level, or the line-item level...those also exist. pc_catid, //The Encounter Category, which is actually from the (old) calendar categories for appointment type. last_level_billed, //flag that tells you if billed to Primary, Secondary, Tertiary insurance etc... This should be an incremental flag as payments get processed. last_level_closed, //related to the above last_stmt_date, //related to the above stmt_count,//how many statement have been sent out (created anyway provider_id,//id row from the users table. In the below data, I have a hack that uses the NPI number as the ID in the user table when someone has such a National Provider Identifier. supervisor_id, //same as above. Both are set in the fee sheet. invoice_refno, //More billing stuff. Easy to track down how it is used. referral_source,//Should be an ID from the users table, but not always an actual "user". Can be from an address book entry. billing_facility//facilities table billing entity. ) VALUES ('1','20151231172134','Patient presents with crayon up nose','GASTROENTEROLOGY LTD','1','1','1','0000-00-00 00:00:00','normal','NULL','1','0','0','NULL','0','1689841637','0','','','1'); //The above can show you a working insert with minimal required values.

[aethelwulffe]

INSERT INTO `x12_partners` (`id`, `name`, `id_number`,`x12_version`,`x12_isa01`,`x12_isa02`,`x12_isa03`,`x12_isa04`,`x12_isa05`,`x12_sender_id`,`x12_isa07`,`x12_receiver_id`,`x12_isa14`,`x12_isa15`,`x12_gs02`,`x12_gs03`) VALUES
('1','CLAIMSCH','500024931','005010X098A1','00','          ','01','CYCTRANS  ','ZZ','T024931        ','ZZ','CLAIMSCH       ','0','P','T024931','ECGCLAIMS');

There is no x12 sender id in facilities. It is in the insurance_companies table.

INSERT INTO `facility` (`id`, `name`, `street`, `city`, `state`, `postal_code`, `country_code`, `federal_ein`, `service_location`, `billing_location`, `accepts_assignment`, `pos_code`, `attn`, `facility_npi`, `tax_id_type`, `color`, `primary_business_entity`) VALUES
('1','Gastro-CHES OFFICE','112 Some Street SUITE 200','CHESAPEAKE','VA','233201706','USA','201628793','1','1','1','11','Billing','1942300298','EI','#FFCC99','1'),
('2','Gastro-VB OFFICE','5701 Some STREET SUITE 100','VIRGINIA BEACH','VA','234621788','USA','','1','0','1','11','Billing','1942300298','EI','#FFCC99','0'),
('3','GAT - OFFICE ENDOSCOPY','112 Some Street SUITE 200','CHESAPEAKE','VA','233201706','USA','','1','0','1','24','Billing','1942300298','EI','#FFCC99','0'),
('4','Gastro-CHES OFFICE','112 Some Street SUITE 200','CHESAPEAKE','VA','233201706','USA','201628793','1','0','1','24','Billing','1942300298','EI','#FFCC99','0'),
('5','GAT - OFFICE ENDOSCOPY','112 Some Street SUITE 200','CHESAPEAKE','VA','233201706','USA','','1','0','1','11','Billing','1942300298','EI','#FFCC99','0'),
('6','GAT - VA BEACH OFFICE ENDOSCOPY','5701 Some STREET SUITE 100','VIRGINIA BEACH','VA','234621788','USA','','1','0','1','11','Billing','1942300298','EI','#FFCC99','0');

Here is where the sender id gets linked:

INSERT INTO `insurance_companies` (`id`, `name`, `attn`,`cms_id`,`freeb_type`,`x12_receiver_id`, `x12_default_partner_id`) VALUES
('1','SOUTHERN BENEFIT ADMINIST','Claims','4320','0','1','1'),
('2','VA PREMIER MEDICAID','Claims','4320','0','1','1'),
('3','UHC/MEDICARE SOLUTIONS','Claims','2438','2','1','1'),
('4','UNITEDHEALTHCARE','Claims','3429','0','1','1'),
('5','UNITEDHEALTHCARE','Claims','3429','0','1','1'),
('6','UNITEDHEALTHCARE COMM PN','Claims','3429','0','1','1'),
('7','CIGNA','Claims','6405','0','1','1');

Note that freeb_type field name has changed to something like ins_co_type....to lazy to look.

[pri2si17-1997]

Ok @aethelwulffe I got it. But there is x12_sender_id field in table. I have the table structure and I am sending you the screenshot. Please check it.

[aethelwulffe]

I am grepping for usages...but the blame on that x12_sender_id field is very old...and blame is almost impossible to track in the database.sql file. Looking at running instances (also with databases with a long history) this field is NULL in all rows. grep results: NO USAGES FOUND. This field is poo, has always been poo, and should be treated as such.

[pri2si17-1997]

Ok... got it... :smile:

[pri2si17-1997]

Hello @aethelwulffe

I have completed forms and updated documentation and table structure. Here is the link of my work :

https://github.com/pri2si17-1997/LibreEHR/tree/GSoC_LibreEHR/LaravelIntegration

Some points to notice :

1. I have dropped 3 tables namely form_care_plan, form_functional_cognitive_status and form_observations. because I was not sure about them.

2. I added encounter, userId, pid and provider to each forms to have link with form-encounters, users and patient_datas table respectively.

3. I need to ask few things :

• In form_track_anything_results there are two fields namely comment and notes which contain NULL as data. So they can be dropped. Similarly comment in form_track_anything.

• client_no is same as pid in form_treatment_plan. So I dropped client_no.

• In form_misc_billing_options I don't know about box_15_date_equal. date_initial_treatment is NULL so I dropped it. mediacl_resubmission_code is ICD9 (mentioned in comment.) So should we keep it or drop? as we are removing ICD9 tables.

You please look at it and table structure, and let me know if anything I'm missing.

[aethelwulffe]

Track anything: Check for usage cases for the comment and notes. Look for a feature that may use these. If there is nothing that can write to those fields, then yes, drop them. A field can be null, but that doesn't mean that a value cannot be there! Often the logic check is _if (fieldname!==NULL), You have to make sure that form DOES NOT USE SOMETHING AT ALL before dropping it. The care plan, functional cognitive status and form_observations are all ZEND module forms as far as I know. If this is true, we should discuss the dumping of them (As they obviously don't work right now, and would need to be made part of a whole optional module or mod, and not base code). There may be other opinions on this. form_treatment_plan should be looked at to see how that client_no works, and the pid field substituted as is needed. Personally, I think that the form itself is not up to snuff, nor labeled/named appropriately, as a treatment plan is a very broad term... DON'T DROP ANYTHING in the misc_billing_options form table. The field that SAYS ICD-9 just needs to be updated to say ICD-10... Just because a field is NULL, it does not mean that the field cannot be filled in. ALL OF THOSE FIELDS ARE VITAL.

[pri2si17-1997]

Ok @aethelwulffe . I will update misc_billing_options table. But still I don't know what box_15_date_equal is? And have you checked the all table structure (that TableStructure.pdf file)?

[teryhill]

That field is/was used in the misc Hcfa form. For 02/12. If is removed or should be.

Sent from my iPhone

On Jun 25, 2017, at 2:24 PM, Priyanshu Sinha notifications@github.com wrote:

Ok @aethelwulffe . I will update misc_billing_options table. But still I don't know what box_15_date_equal is? And have you checked the all table structure (that TableStructure.pdf file)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[aethelwulffe]

There you go! Kill that field. Best to just check interface/forms/misc_billing_options form and go from there...but Terry knows this stuff pretty good. Terry, thanks, but I think you are supposed to be incommunicado until Wednesday at earliest. Ja?

[pri2si17-1997]

Ok @aethelwulffe .

[pri2si17-1997]

Hello @aethelwulffe , Should I send PR for this?

[aethelwulffe]

If you have code ready to go, and you don't think it will break stuff, bring it on. Yes, I like PR's a lot.

[pri2si17-1997]

Yes.. I think it is ready as major tables are refactored and more to be included. It will not break any stuff.. it is entirely a separate implementation. I am sending it, please do review it.

[aethelwulffe]

Standing by...

[pri2si17-1997]

Done..

[pri2si17-1997]

Hello @aethelwulffe

Can there be many x12 provider for one insurance company?

[aethelwulffe]

I guess you are referring to x12Partners. These are billing clearinghouses that handle the billing claims you send, and forward each claim in a batch to the correct insurance company. The problem is, you can't always use just one clearinghouse, because that clearinghouse may not handle all the insurance companies you deal with. Normally, this is just set in the insurance_companies table; insurance company "x" is always billed through clearinghouse (x12 partner) "y". Sometimes this changes, and the partner has to be changed...and very rarely, you temporarily change x12 partners for an insurance company...but a many-to-many relationship here is not actually helpful, and could create mass confusion as to who sent what to where...

[aethelwulffe]

short answer, no...not really.

[pri2si17-1997]

ok.. got my answer.. just one thing, if a new provider is registered with company, then it will update x12_receiver_id. right?

[aethelwulffe]

OK, let's make sure we are talking in correct terminology: x12_Partner...not provider. The term provider means "Medical Services Provider" e.g. Doctor, Nurse etc... x12 partner is a billing clearinghouse that helps manage claims so that you don't have to send each claim individually to each insurance company for payment.

Order of operations: Create an x12 Partner. Create an insurance company. Select the "default" x12 partner to use with that insurance company.

So, the insurance company UI merely makes a list of the rows in the x12_Partners table to choose from. If you change the information in that x12 partner listing, then the behavior of any insurance_companies rows linked to it will also change. SO: When a billing person is in the billing manager, and is about to send out claims, the following happens:

• According to the criteria selected in the billing manager, a list of patient encounters (form_encounter), and the associated patient_data and billing table items are included.
• For each row returned, there is a JOIN to get the patient's insurance_data table information.
• For each of those rows returned, there is a JOIN to get the insurance_companies information.
• For each of those rows returned, there is a JOIN to find out what x12_partners should be associated with that claim.

It is actually a lot more complex that that, but at this point, the human billing person can then select the claim rows returned. They generally need to make sure all the selected claims can all go to one x12 partner. @teryhill We should enable selection of rows by x12 partner as a work-around to the problem of the billing manager unable to search/find unbilled claims by x12 partner criteria.

P.S. BTW, the Billing Manager allows you to override what x12 partner a particular claim will be sent to (rather what x12 partner will be associated with an x12 837 billing batch file that will be created). This does not change the default x12 partner id in the insurance_companies row. Dunno if that helps you complete the picture or not.

[aethelwulffe]

Changing the "default x12 Partner" in the insurance company UI is what updates the x12_partners row linked in the insurance_companies table. ...Still struggling to make sure I am being clear.

[pri2si17-1997]

Yes..

There are two columns in insurance_companies namely x12_receiver_id and x12_default_partner_id, and changing default x12 partner in UI, updates both the field. So according to me it should update only x12_default_partner_id. This is what I'm asking.

[pri2si17-1997]

Hello @aethelwulffe

Some more questions :

1. In table lists :

• subtype
• returndate
• classification
• extrainfo
• diagnosis
• user : This is probably user who is registering this. But we have one more field referredby and that's why I am confused.
• groupname : This is probably from groups table, like in all form_* related tables.
• reinjury_id
• injury_part
• injury_type
• injury_grade
• external_allergyid
• erx_source
• erx_uploaded
• external_id : I think this is same as external_id in form_vitals.

2. In table prescriptions :

• filled_by_id
• pharmacy_id
• drug_id : Default is 0. But I think it has something to do with drugs table.
• rxnorm_drugcode
• filled_date : This should be when form is filled. But that can be date field also. Not clear. :|
• datetime
• user : This is user who is registering this prescription.
• site
• prescriptionguid
• erx_source
• erx_upload
• drug_info_erx
• external_id : Same as above.
• end_date
• indication
• pin

3. Earlier in this thread I asked about amc_misc_data and you told me that this is useless, and we should use report_results and report_itemized. So can you please tell how to proceed here?

4. Explain me Fee Sheet. Its related tables are ar_activity and ar_session. So please explain UI in terms of table. I do inserted data and tried to map the relation, but still I am not very sure, that's why I am asking.

Please explain me above things. And also comment on present structure which I created. It will give me an idea that what things are going wrong like plural table names and some spelling mistakes. I will take care of that while creating new migrations and also will correct them in previous structure.

[aethelwulffe]

_

There are two columns in insurance_companies namely x12_receiver_id and x12_default_partner_id, and changing default x12 partner in UI, updates both the field. So according to me it should update only x12_default_partner_id. This is what I'm asking.

_ x12_receiver_id...Oh gee what a mess. I will explain the idiocy of all this more if you like, but it is really thick:

DROP TABLE IF EXISTS `insurance_companies`;
CREATE TABLE `insurance_companies` (
  `id` int(11) NOT NULL default '0' COMMENT 'primary key and foreign ID',
  `name` varchar(255) default NULL COMMENT 'Common name for insco',
  `attn` varchar(255) default NULL COMMENT 'example: Billing Department',
  `cms_id` varchar(15) default NULL COMMENT 'insco identifier supplied by x12_default_partner published list.  NOT a UUID like an NPI or tax number.  Refer to Clearinghouse Payer List for value.  Named cms_id by a not very clever person.  Is a stupid misleading name.  Has nothing to do with CMS.',
  `ins_type_code` tinyint(2) default NULL COMMENT 'integer that identifies the payer type.  Values come from the x12 standards',
  `x12_receiver_id` varchar(25) default NULL COMMENT 'alternate row linked from x12Partners table.  Not currently used or configurable.  Should be called alt_x12_receiver_id.  This value is normally set === to x12_default_partner_id, and should be dropped along with alt_cms_id unless it is proven to be utilized somewhere in the code.',
  `x12_default_partner_id` int(11) default NULL COMMENT 'The real clearinghouse partner key, and is related to cms_id',
  `alt_cms_id` varchar(15) NOT NULL DEFAULT '' COMMENT 'Is the insco identifier as supplied by the x12_receiver_id, which is actually the alternate clearinghouse, and is not currently used in any way to my knowledge.',
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB;

[pri2si17-1997]

:smile: No no... I got my answer. Thanks a lot... :slightly_smiling_face:

[pri2si17-1997]

Hello @aethelwulffe

One more thing, when we record Disclosures for patient, that is getting saved in extended_log table. My question is, what is Recipient Name? Does it has any relation with users table, or it is linking to any patient, contact, or user?

[tmccormi]

And might be useful to rename all occurrences of x12 partner to clearinghouse which is what the doctors actually call it, x12 is an Uber geek technical term

Tony McCormick

On Jun 29, 2017 2:19 PM, "Priyanshu Sinha" notifications@github.com wrote:

Hello @aethelwulffe https://github.com/aethelwulffe

One more thing, when we record Disclosures for patient, that is getting saved in extended_log table. My question is, what is Recipient Name? Does it has any relation with users table, or it is linking to any patient, contact, or user?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LibreHealthIO/LibreEHR/issues/552#issuecomment-312111490, or mute the thread https://github.com/notifications/unsubscribe-auth/AARci_pm3VD_4djyQTVVxKY7KcP8TQ_Pks5sJBTDgaJpZM4NlobB .

-- Please be aware that e-mail communication can be intercepted in transmission or misdirected. Please consider communicating any sensitive information by telephone. The information contained in this message may be privileged and confidential. If you are NOT the intended recipient, please notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and destroy this message.

[pri2si17-1997]

Ok @tmccormi .

[aethelwulffe]

EDI Partner or Clearinghouse is fine for the labels (from one mindset) what is even more needed though is clear indications of when a field affects the outgoing billing claim file. Insulating people from the "geek speak" is sometimes wise, but in this case, there is a serious problem. Someone filling in those values will need to translate those "common terms" into what they are getting from the clearinghouse or insurance company EDI implementation guide. In that, the names will consist of first a loop number (example: Loop 2400) an element (Example: NM1) and an element index (example: 08) and then, sometimes, a field description like "Submitter ID". When you get a billing error report, it very often simply says something like "invalid value for LOOP2400AB element NM103". This is NOT a place where fuzzy names actually help the user. You have to be competent to a high degree to configure billing properly. As it is, there is significant challenge to figure out what some of the warm and fuzzy names (most of which are not all that warm and fuzzy) actually are in real terms, even when you are STEEPED in high-level knowledge. I literally have to refer to the billing file generation code to figure stuff out sometimes. However fuzzy the labels of things are in the interface, I feel that the field names for things that go to EDI stuff should be drawn from the x12 837P standard. At very least, there should be help text in the UI, and comments in the table that reference how/where they show up in the standard.

[pri2si17-1997]

Hello @aethelwulffe

Here are some doubts :

1. What is batch communication tool and how it works?
2. When we add tag in patient, it gets saved in database in table tf_patients_tags, but the issue is, on GUI it shows No Tags Found. Also in table tf_patient_tags, there are two fields created_by and updated_by. They are of datetime type, but it must be user id referencing to users.

Here is the screenshot of what I am saying.

For first point.

For second point.

3. Please explain me icd10_* related tables.

4. For history data of patient, data is getting saved in history_data. For Risk Factors there is a field called usertext11, which stores its value. Firstly, it should have some reasonable name like risk_factors, because it will be easy to understand. Also such usertext*, userdata* and userarea* related fields should be made a separate table and linked with it. What you say?

5. Also please explain me questions asked in above comment. https://github.com/LibreHealthIO/LibreEHR/issues/552#issuecomment-312084053

Please tell me above things, whenever you get time. :slightly_smiling_face:

[pri2si17-1997]

Hello @aethelwulffe

Please reply above queries..

[aethelwulffe]

1. batchcom is not something I have ever gotten to work. Hopefully Terry's new messaging PR will make this obsolete.
2. The Tags system is from Tony's team, and it is also a feature I have no experience with (it is pretty new, and I have had no application for it. Perhaps his team ( @kchapple ) can provide some insight.
3. The icd10 tables are lists of diagnosis codes that are imported from external resources. These are imported by going to Administration->Other->'External Data Loads' .
4. As previously discussed, anything with names like "generic" or "user" in the layout-configurable tables should be dropped after investigating to see if some idiot has used them in a hard-coded query. I would not bother retaining them. It will take a significant refactor to have the layout engine look to a new table for any user-configured values for demographics-related tables. This is needed, but is probably not in the scope at the moment.
5. Looking to see what you mean for number 5.

[aethelwulffe]

Lists table...you pretty much have correct. The "group" stuff is useless, though it is required by a lot of code. the "referred by" field is something that references a contact that is a patient referral (as in "referred to us by"). Referral tracking is actually more important in medical stuff than you might first assume.

Prescriptions table is best to leave alone unless we have a very good handle on the eRX system, as well as the way this table interacts with the issues table and the medications stuff. The "date filled" item is like a "patient picked up their pills from the pharmacy on this date" thing...basically a delivery date and not the date of ordering etc... It is a tracking item, and likely something that the NewCrop eRX (electronic prescribing) system touches, and probably something that was added custom for that feature.

amc_misc_data (and there are a couple of other related tables) is part of a reporting tool that is out of date. We do not use the "AMC" type of report anymore. The report_itemized and other table is to be preserved, as it is still very useful for other things. I will be updating all these reporting modules in the next month.

Fee sheet really only has one direct table. That is the billing table. claims, ar_activity, ar_session, and a great number of other tables are indirectly related. Those relationships are quite complex.

[pri2si17-1997]

ok @aethelwulffe .

I discussed ICD10 related tables with @teryhill on chat, and he guided me.

Prescriptions table is best to leave alone unless we have a very good handle on the eRX system, as well as the way this table interacts with the issues table and the medications stuff

Probably you mean, not to touch it now.

Fee sheet really only has one direct table. That is the billing table. claims, ar_activity, ar_session, and a great number of other tables are indirectly related. Those relationships are quite complex

can you please elaborate it a bit more? With some examples. It will be a great help.

[aethelwulffe]

May 31 comment above https://github.com/LibreHealthIO/LibreEHR/issues/552#issuecomment-305087473 I will get you matching examples of the billing table entries.

[pri2si17-1997]

Yups. I have looked at that, and probably I am clear with billing table leaving some fields, but how the entries are then stored in its related table is not clear.

[pri2si17-1997]

Hello @aethelwulffe

Few more questions :

1. What are gacl* related tables. It seems to control access, but how? You please brief me how to use it, so that I can figure out how data is stored.

2. audit_details and audit_master table. I grepped for it and found under zend-module.

3. drugs related tables.

There are few more tables apart from this, and I'll ask you once I have created schema of all other tables . Please check it.

[tmccormi]

GACL or gacl is a short cut form for phpGACL. This is an acronym meaning Generic Access Control Lists. It allows fine grained control over the EMR. As an example, the physician can be permitted to view sensitive patient information, while the receptionist is unable to view this sensitive patient information.

@pri2si17-1997 please read the GACL documentation available on /Documentation/README-phpgacl.md

[tmccormi]

"drugs" is part of the drug Inventory management system. It can be turned on in Globals.

[pri2si17-1997]

Ok @tmccormi thanks.. :slightly_smiling_face: . I will look into it.

[pri2si17-1997]

Hello @aethelwulffe Can you please explain me codes and code_types table with example if possible? Also are codes related to drugs?