yujunc wrote on Saturday, July 12, 2014:
Hi,
I am just new to openemr and I tried to add a new table in MySQL in openemr.
However, when I used MySQL Workbench to build up the EER Diagram in openemr, i found that all the tables are disconnected (no relationships among the entities). I was hoping with the ERD I can find out the overview of openemr’s database, but now I am a bit confused.
Thanks,
Eugene
mdsupport wrote on Saturday, July 12, 2014:
Current design does not use constraints / FKs - guessing mySQL legacy reasons.
Try manual links with main keys as pid and/or patient_id and encounter. It’s a tiny db and names help.
sunsetsystems wrote on Sunday, July 13, 2014:
Yes, legacy reasons. In the old days MySQL had no real support for foreign keys and that’s what OpenEMR grew up with.
yujunc wrote on Tuesday, July 15, 2014:
Thank you, your information is really helpful! I am really appreciated your replies!
So, in this case, if I would need to create a tables for new developed features, what is best way you recommend? I am thinking manually connect those tables first and then glue my new tables with them. But there are over 150 tables! And besides I dont know their relationships at all. Do you think there is another to achieve my goal.
Thanks agian!
Eugene
yujunc wrote on Tuesday, July 15, 2014:
Thank you for your reply MD support!
If I understand correctly, you mean the MySQL DB that OpenEMR is using is not RDBMS?
Eugene
blankev wrote on Tuesday, July 15, 2014:
What kind of great new features do you have in mind with no connections with other tables? Sounds more than promising. Would the Zend modules be something to concentrate on? The module(s) way to go, for the Zend, not the Zend itself…
sunsetsystems wrote on Tuesday, July 15, 2014:
It’s relational but the relations are enforced by php code and not mysql schema.
sunsetsystems wrote on Tuesday, July 15, 2014:
This document has some information about the tables and their relations:
http://open-emr.org/wiki/index.php/Database_Structure
Avoid creating tables needlessly. In many cases extending an existing table is preferable.
yujunc wrote on Tuesday, July 15, 2014:
Since the clinic network I am working for needs a module called “Follow-up” for the front desk employee to follow up the situations of the patients after the diagnoses to seek feedbacks. So I am generate a new tab like a dashboard showing all the patients status and feedback status for the front desk staff.
yujunc wrote on Tuesday, July 15, 2014:
OK, I got it. Thank you Rod.
If it doesn’t bother you, would you please briefly how to enforce the relations by php in openemr? I am not very familiar with it. Thank you so much!
yujunc wrote on Tuesday, July 15, 2014:
OK, I got it. Thank you Rod.
If it doesn’t bother you, would you please briefly how to enforce the relations by php in openemr? I am not very familiar with it. Thank you so much!
fsgl wrote on Tuesday, July 15, 2014:
If you are able to describe in detail what you wish to achieve with the followup module, we can probably offer suggestions so you won’t have to create new tables.
It’s easier to use what’s on the shelf than it’s to go into the work shop to create something brand new.
A simple modification of the Demographics layout might do the trick.
A suggestion for the future, state your goal in simple terms without defining beforehand how technically it is to be achieved.
Doing it this way will:
yujunc wrote on Tuesday, July 15, 2014:
Attached is the design of result and database for “followup” module.
Here is more about its use case:
This module is mainly created for our volunteers on front desk to follow up the feedbacks from our patients.By using this module, our volunteer will be able to know when and which patient should be contacted for feedbacks and keep tracking the patients. Each follow up issue is a record and it requires at most three times attempts to contact a patient and it succeeds once there is one response from a patient. In the first slide and most right column, three buttons indicate the status of the three attempts. Green is successful, red is failed and blank is not yet tried. By pressing any of these three bottom, the volunteer can fill the follow up form (as in slide 2). Once a follow up issue is finished, the issue (also a record) will be display in the history list (as in slide 3). It allows the voluteer to search the record by using name, data, clinicID, and responsible volunteer ID.
I hope this describes the use case well. Please let me know there is any question, I am more than happy to happy. Thank you, it is an amazing community!
Eugene
yujunc wrote on Tuesday, July 15, 2014:
Thanks for your advice, I post more details about this module.
Thank you, fsgl
blankev wrote on Tuesday, July 15, 2014:
Remember I am a USER of average quality with my own preferences.
Most of your wishlist is included in OpenEMR.
What is needed: A new group of USERS with their own specialized permissions called Volunteer Professionals.
Three NEW FORMS that can be created in LBF-Visit Forms (they do not impress as very complicated.)
Dates can be done with the Date and Calendar or as an automatism with something like If, Then, Else, statements.
The Real Professional Developer (RPD-input!) needs indeed to make the connections and screenviews for the Volunteers and Doctors control functions!
BTW Something alike, but not the same, might be found in the “new” developments of Client warnings when checking progress notes or Clinical reminders and Calender appointments. But now I am guessing as a User not as a Developer with programmer skills.
yujunc wrote on Tuesday, July 15, 2014:
That’s really helpful and thoughtful!
Actually I am a college student helping a project, so I think it will meet the requirements at least for now. Once again thank you for your great advice and instructions!
Eugene
bradymiller wrote on Wednesday, July 16, 2014:
Hi,
There are many ways to accomplish this. Just a thought of one route to consider. You could mimick/leverage the mechanism that is used in the Administration->Users->“View Facility Specific User Information” button, which uses a layout that can be edited in “Administration->Layouts->Facility Specific User Information”. In the codebase, look at code that is used in interface/usergroup/facility_user.php, which stores the data in the facility_user_ids sql table. Doing it this way would make it very configurable and generic enough to possibly include in the official codebase.
-brady
OpenEMR
fsgl wrote on Wednesday, July 16, 2014:
Excellent presentation, Eugene.
This Project is indeed very blessed with knowledgeable/hard working developers and cordial users.
I agree with Pimm’s suggestions to modify Access Control List and deploy Layout Based Visit Forms.
There appears to be four prongs to the Followup Module. It is not possible to have all four sitting in one space in the Graphical User Interface, but that would entail a massive amount of code change and would be too great a price in time and effort for a small return.
First Prong:
Access Control Objects for the Front Desk are rather limited. The Front Desk can schedule appointments, create new patient accounts & take copayments. That’s pretty much it. A new group, Volunteers, must be created in order for them to have permission to enter data in the followup forms.
Second Prong:
Slides 1 & 3 can be combined into a new Demographics section (Administration/Layouts/Demographics). Inserting radio buttons.
Third Prong:
For the Slide 2, various LBV Forms can be created for each type of followup.
Fourth prong:
Search would involve deploying a) fictitious in-house CPT codes for the various types of followup calls, b) search from Reports/Clients/Clinical using the in-house CPT codes. The report can be modified to include other filters, which will require code changes.
None of this involves re-inventing the wheel. If search by CPT suffices, then you’re done.
Feel free to post additional questions.