Laravel/setup/migration/FHIR project management

Hi everyone.

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.


I started a tentative project layout here:

Change anything you like…if you are going to manage it! In any case, we need to have a good team discussion immediately to get an overall vision together.

1 Like

Hi @aethelwulffe, when do we discuss these issues? I’m excited to get going and get a greater understanding of the system.



Try asking questions. You must have many! How about starting by summarizing your understanding of what we are trying to do, and share your thoughts. By doing that, we can all be more sure we are on the same page.

Putting together a group goal, or breaking up a big goal and sharing it out is usually a matter of a couple of day’s workgroup face-to-face.
Here, we don’t have that option.

From my understanding, we want to

  1. completely refactor the database
  2. use FHIR description for data formats, elements and API for exchange of information with other EHRs
  3. make the system easy to setup and upgrade for users.
  4. get an explicit documentation to new developers**
  5. make use of Laravel and the developers on board here for UI, Reporting …

I have looked at @pri2si17 blog post on the work he did on refactoring the database. Now I’m trying to know the work still to be done on the database.


@Trodrige Remember the explicit documentation is for us OLD developers also. You have a very good understanding of the basic desire (build the best EHR around).


Hi @Trodrige . I have left some tables like acl, payments, logs and rules. So there is some part of database refactor still required. But before proceeding further I need to tell why I have left these modules :

  1. ACL : At present, we are using php-gacl module to have a control. But I think there is authorization in Laravel which can help us achieving this task. I was not able to make it that point, but I would like to have your opinion on this.

  2. Payments : Payment and billing modules need to be revamped. So it is future task ( and a lot more involvement of @aethelwulffe and @teryhill:slight_smile: )

  3. Logs : At present logs are looged in database tables. If we can store it in file (as they are transaction logs and file is best option for it according to me).

Seeing the priority, I think we should work on setup script which automatically create those migrations. Then we can proceed further with FHIR component.

As to log files. To meet Certification Criteria for EHR (should we desire to do that in the future) the logs must be easy to use for end users to search and report, which is why they are a table in a database. Other model like storing them as JSON or NOSQL data with key/value pairs and providing a fast log file mining tool are options.

1 Like

Thanks, @pri2si17. I think Laravel authorization (Gates and policies) will be good for access control to resources.


Honestly, Terry and I are a bit fuzzy on the whole Laravel thing. Neither one of us are used to operating inside any framework other than that provided by standard and common libraries…in whatever language we old fuddy-duddies may be playing in. Neither of us would mind getting a nice document describing a list of cool functions we can use all over the place, something I am more used to describing as an “engine”.

Our whole concern with including Laravel is, and always has been, that someone will add a kind of ad-hoc bunch of code to the code base (a few thousand files) that are only used for one or two things, and are scattered all over the place with no reference or way forward. This has been done many times in the past with the project we forked from. 18 months ago, the code-base was 110% larger than it is today, and didn’t do as much. There are still remnants of the ZEND framework, as well as…a lot of other stuff…from iterations of folks thinking “This is a great new thing, let’s include it”.

In the previous year, our tiny team knew we needed to attract new blood. New developers seem to…at some point…mention Laravel. So, it seems like the best way to attract and keep new folks is to give them the tools they want to work with.

So, what we are hoping for is the following:

  1. Get a good rationalization for adding the Laravel Framework. We have that in the whole database related issue.
  2. Build a coherent project using Laravel, ensuring it is clean, clear, and documented…both in use as well as code location/organization. Careful attention should be made to minimizing the footprint, as well as planning for extension/scale needs for future features using the libraries.
  3. End result: New devs can dive right in, and the oldsters have an easy ramp to climb for getting with a new way of doing things. This should all result in a more coherent and efficient code base, and help the project get and keep new developers.

On my side of the tool, I’m old too, but we are doing work in Laravel for other projects, so me and mine are a bit more comfortable with the core. However, in general, I agree with Art.

Let’s make sure that Laravel is a tool we use, not an embedded part of the application we deploy. There will be transitional steps where we are running Laravel and legacy code that can get very messy. Baby steps, please. (NOTE to Art and Terry: this is were composer comes into play … )

Tony McCormick, CTO Support: 866-735-0897, Direct: 713-574-6709 My Calendar: -Verba volant, scripta manent

Hi @tony, can you please explain :

Havent done any php for the last many years, but Laravel does look like a very interesting framework. If it matters, I give my :+1: for the use of Laravel in LibreHealth EHR.

1 Like

I mean; do not copy the Laravel framework into the Librehealth EHR repo. Create a installation/build process that packages them for runtime use. No need to embed someone else’s codebase when all you need to do is reference it or install it.