![]() Gonna be lots of potential ways to do this, and agree good to consider ease of use.Generate laravel seeder file from a real data from your database. And then in this case, wouldn’t be tough to run these processes via commandline in cases where doing OpenEMR autoinstall (it could even be a docker setting). ![]() And then could use OpenEMR to import them (can’t really utilize the API since internal, but can actually run the underlying Service calls that are used in API (ie. The data could be dumped in temp folder (or memory, but guessing a million patients may get out of hand). could be a docker on the local network but could even be a synthea server over internet), then a script/gui in OpenEMR where you could run the process with some settings (number patients, locale, etc). In that case, you could have a setting in globals that directs to the synthea server (ie. Another option would be to follow the way we integrated the following easipro feature: That being said, agree that the easier to use the better. Don’t see medical staff or standard users using this. Target users will likely be researchers, developers, students, and demos. Note these are just some initial thoughts and feel free to go the way that you think is best. For example, could have the synthea docker, the openemr docker, and then a “utility docker” that runs synthea (that curl call) and imports the data into openemr via the api. Regarding dockers, the sky is really the limit. It looks like that Synthea static build docker dumps the data into a shared folder so should be able to share that between dockers. rather than building out a separate openemr/synthea combination docker). If possible, would rec trying to keep the modularity of the main OpenEMR docker since that then makes it much easier to support and maintain (ie. This may require building out the API to support things, but much easier to leverage processes that are already there to bring data into the database than trying to reinvent that very, very complicated wheel Then can take advantage of the code that already exists to create patients, medications, allergies, encounters, etc. Would instead recommend importing the data through the OpenEMR API. I wouldn’t try to import directly to the database, or else you will likely go mad trying to sort out all the relationships after get beyond basic demographics. I also think this will be nice to have as a Separate Openemr project on a separate repository. ![]() It is worthy of note that the PHP Framework Laravel uses something similar to the above structure for seeding databases, Please tell me what you think. Seed specified tables with generated data, for this we could most likely use Iluminate Database packageįor ease of use we could create a CLI tool for the above using Symphony/Console packageįor localization I am not very sure, but maybe the project users can specify local datasets in their locales and the faker package can use that instead of the random data sets it uses This is how this could be achieved technically Make it possible to localize seeding content, so seeding can be more meaningful to local audience Make the mechanism easy to use(GUI or CLI) If this is the case this is how we could approach itĬreate a mechanism to programatically seed OpenEmr Database Tables(If we can seed the tables, we can also use PHPMYadmin to export their content for resuse) ![]() Hello if I understand this project correctly we are looking to build something that allows seeding of Openemr database tables for OpenEMR demos to be more meaningful to Potential Users
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |