Laravel/setup/migration/FHIR project management

Art Eaton
Thu, 28 Sep 2017 19:07:14 +0000
EHR

Hi everyone.

github.com/LibreHealthIO/lh-ehr

Database Refactor

LibreHealthIO:master ← pri2si17-1997:GSoC_LibreEHR

opened 06:09PM - 27 Jun 17 UTC

pri2si17-1997

+22564 -0

github.com/LibreHealthIO/lh-ehr

Upgrading the setup to Laravel framework

LibreHealthIO:master ← eran13com:master

opened 05:07PM - 28 Sep 17 UTC

eran13com

+1149 -0

OK, @pri2si17 (Priyanshu) started a laravel-based database refactor project for GSOC 2017. He progressed quite a way, and also gained a good understanding of the current database structure and use.

@eran13kom (Chandima) has also put in the second PR 692 with some migration files.

We currently have some clear objectives we need to work out. Here are the primary factors:

1. We need a far better setup/migration/configuration toolset.

2. We want to refactor the database so that it is more coherent and efficient.

3. We want to make the application very aware of the FHIR API database scheme.

4. We want the ability to leverage the skillsets of our newest developers and attract more. It has been decided that giving them a Laravel framework to use in that context.

The ultimate goals are:

1. Make setup and configuration better for the end users, and have an upgrade system that removes the need for any customization tinkering.

2. Get the whole project to a documented standard for new developers.

3. Be able to integrate seamlessly with any FHIR API applications, and act as a FHIR server.

4. Leverage Laravel for UI, Reporting, Communication and other new modules.

So, I propose the following rationalization:

Priyanshu has already made some significant efforts towards database refactor. Everyone agrees that Laravel components are a good option to enable and standardize related projects.

So, first goal is to do something that rationalizes merging Laravel components (prefer /assets directory). This would be something in line with the database refactor, migration, and setup needs listed above.

Three, maybe four developers want to work on this, or are already involved and want Laravel to continue. We might get some use out of starting a GITHUB project for managing this. The current PR’s should probably be managed as a feature branch, then merged with the master after the first tested interval that has a complete feature. I don’t think that it should be managed as a separate repository.

14 posts - 6 participants