Project: Report Generator for EHR

gsoc2018-project
gsoc2018
ehr

(Terry Hill) #21

The where clause should be for the tables that they have in the report. So the patient_data table would have fields in the where selection like lname,fname,DOB,zip code, sex etc.

When the table is being built the enduser will need a knowledge of the fields that are in the table they are working with. (Advanced User/Vendor)


(Tigpezeghe Rodrige Kwenchu) #22

@teryhill consider a user who drags and drops 4 components that point to 4 different tables in the database. Let’s say patient_data, appointments, drugs and addresses tables. He then specifies drug_name==‘Maalohx’ for the where clause.

  1. Does this mean the report(table) will be generated before the user specifies the where parameter to generate an accurate report?
  2. A report may be generated from more than one table at a time. How do we handle this?
  1. How do we achieve this?

(Terry Hill) #23

the user , for right now, would select the where clause based on the fields used. I do not think that there are any current users that will understand how to apply the logic of the where clause across the tables that are not included in the report.


(Terry Hill) #24
  1. the user will be an advanced user and will be familiar with PHPmyadmin or adminer for now

(Priyanshu Sinha) #25

Hello @teryhill @tony @aethelwulffe @Trodrige

What Rodrige want to implement is something similar to what we have right now (Reports->Clients->Patient List->Provider), and get all the reports. What he is trying to get is something different. What I get is, he wanted to generate report for all patient whose first name is XYZ or who resides in street Honolulu. @Trodrige correct me if I am wrong.

What he wants is from Admin perspective (To get report depending on various fields.) And what we have is more like Clinic perspective. So my question is, do we need report from Admin perspective? If yes then any reasons?

My understanding is he should generate report with clinic as end user. In that case, one clinic can see reports of patients associated with their clinic or others clinic.


(Tigpezeghe Rodrige Kwenchu) #26

We know the fields the user has selected only when the desired draggable components have been submitted. Does this mean that the user will be able to select the where clause after the report has already been generated, then he can specify the where clause, then the final report generated? This doesn’t sound good to me, if that’s what you mean. I think the user should be able to drag components, select where clause (if he wants any), click the ‘Generate report’ button and then the corresponding report is generated.


(Terry Hill) #27

I think the user should be able to drag components, select where clause (if he wants any), click the ‘Generate report’ button and then the corresponding report is generated.

Yes. The user will need to add the where clause components and then generate the report.

The where clause components would , i think, be based on the dragged components.


(Terry Hill) #28

In other words the main items for the where clause would be some of the dragged fields.


(Tigpezeghe Rodrige Kwenchu) #29

Thank you @teryhill, now I’m clear on this, at least for now. :smile:


(Tigpezeghe Rodrige Kwenchu) #30

I’ve been thinking of doing something like in the screenshot below. It’s a rough implementation of what I’m thinking. Some of these components map to several table columns. A where clause should refer to one table column, how do we implement this? (interface)


(Art Eaton) #31

Titling columns…THEN dropping what should go in a column could be a powerful approach as well, if functionality grows to be able to concat() fields, or have columns as sub-queries. This is a good early implementation flow though.


(Tigpezeghe Rodrige Kwenchu) #32

Link to my 6th blog post


(Tigpezeghe Rodrige Kwenchu) #33

Draft final submission for review


(Priyanshu Sinha) #34

@Trodrige

Looks good to me. Meets all requirements. :slight_smile:


(Tigpezeghe Rodrige Kwenchu) #35

@pri2si17 @aethelwulffe @teryhill

Below is a checklist of steps I wish to follow to move my partially finished work to EHR modules folder. It includes installation procedures. Suggestions and ideas are welcome. :wink:

  1. Create .env file from .env.example file.
  2. Generate application key during installation.
  3. Create the database (run artisan database creation command programmatically).
  4. Specify database credentials and other variables in the .env file.
  5. Run migrations and seed (default draggable components, report formats and system features) commands programmatically. (Seamless execution).
  6. serve the application seamlessly (php artisan serve).

(Tigpezeghe Rodrige Kwenchu) #36

This is an attempt to document my work. This file will be a .pdf inside the ReportGenerator folder in the Laravel project. It can be used as documentation. Please suggest changes.


(Tigpezeghe Rodrige Kwenchu) #37

Hello, @teryhill @pri2si17 @aethelwulffe Should the report generator install at same time with the EHR system? OR should we make it optional for a user to install the report generator?

What’s the best option to do this?


(Terry Hill) #38

Install with the system. You will need a way of adding it as an upgrade to existing users.


(Tigpezeghe Rodrige Kwenchu) #39

ok, great. We’ll start with install and upgrade will follow.