This is the central discussion topic for migrating the LibreHealthEHR database to the Toolkit data schema, making and resolving a gap analysis.
May be helpful to post the summary of the current database you are using aka schema
You’ll find the latest toolkit database here - https://gitlab.com/sunbiz/lh-toolkit-docker/blob/master/db/default-data-2.1-install.sql
Yes, sorry, I added the thread without having the time available to do anything else, just to make sure things moved forward.
Unfortunately, a database dump of a mess of tables with undocumented relationships isn’t a very big help. We actually do have a project with a very deep graphical analysis (that is a little bit dated) that we never published, and I never managed to get from the originator. I am trying to get that at the moment. In the meantime, I will have to do a straight structural dump as well as provide the link to the default database content from the EHR repo.
I am starting this by simply diving into the mapping, going as far as I can, using the link provided by sunbiz. A dump that contains realistic data values might be a lot more helpful. A dump of each created by using identical source data would be even better!
Not looking impossible so far, but the billing element/requirement seems to drive a lot of differences in the relationship of the data structures.
Things involving the concepts tables will prove to be a lot of fun!
Maybe the question we should ask is what are the current limitations of the data structure and what gain would be achieved by migrating to toolkit
The answer may end up that there is no need. 
Two objectives (aside from a psychological third): Mapping and 1:1 field names where it is obvious for consistency. Migrating LibreEHR to a non-organic well designed data structure…which it sorely needs.
This process will also allow us to dump 17 years of legacy uselessness and duplication, as well as implement meaninful field and table names.
In LibreEHR, you will find (example) provider_id, providerID, Provider, and provider_ID. The table is the users table, which is also used for the address book…bad. It goes on and on.
1 Like