EHR + Toolkit Integration

Well, I just discovered that the down arrow key still works to see the content. That helps…me at least! @downey The LEHR team is tiny, but we are sweating hard! I just hope that some sort of conjugal visit between the EHR and the LibreHealth kit can happen pretty soon. Something in that vein, even a minor thing would be really really cool. I have fought to stay clear of Java for the last couple of decades, but I am really really proud of being part of the LibreHealth gang, and have finally resolved my anxiety over having to ignore MRS in favor of EMR. We are in the same house, and something freaking cool is going to happen!

1 Like

I feel this integration shouldn’t be at the Java level… instead I think this integration should be at the FHIR or some other webservices level, so that the UI from LibreEHR can be using what it already uses, but can use the API that even the LibreHealth Toolkit can speak, which is FHIR or may be API.


I am with you on that. The commonality of the platforms should not matter. If they do, then we are doing something wrong. I don’t even have to know what the Tomcat is doing to the Glassfish, or who is the JBoss on the job. All the same, I think I should (on a personal level) try to get in touch with Java as something other than “that thing that runs a Minecraft server” and learn as much as I can about LibreHealth API. I guess I should look at it as a weird C++ with procedural programing completely turned off. Looking forward to the thread that starts talking about synergy between the two.

Integration of the minds for sure and FHIR is high on the list. We are actively working of the FHIR services for the EHR as we speak… as a stand alone service.

@tony maybe @sunbiz and other FHIR-interested people (@maany? @judywawira?) can all brainstorm in an upcoming weekly EMR team meeting? Love the direction this thinking is going! :bulb:

1 Like

Please, Please, Please! We need to hear each others voices and learn how to communicate by written word better if nothing else.
The fhir project is, obviously, the conjugal point, but we should have the conference calls available for all discussions related to LibreHealth organizational activities. API vs. EHR discussions should not be too hard to differentiate in the same conversation, and be good general info. Other organizational business is a large part of the discussions anyway, and ex-patriots from both parties will be equally involved since these are across-the-board issues, either as a core issue or tweaks and interpretations as they apply to the different products.


Over the weekend we are going to migrate the current LibreEHR github account to the LibreHealthIO github account. @r0bby will also turn on mirroring to the gitlab.

All repos and issues will be moved, so you will need to update your local clones after that.


1 Like

All issues and pull requests will be moved automatically.

1 Like

I have moved the repo to The devs have all been invited to that Github group under the LibreHealthEHR team I left the webpage repo on the site (libreEHR) for now and pointed the “View it on GitHub” button to the new location.

@r0bby will start the bi-directional mirror to gitlab this evening

1 Like

Cool stuff :slight_smile: big thanks to all involved and all who are willing to be trailblazers with us! :trophy:

I have renamed the repository for LibreHealth EHR to

Update your remotes accordingly.

This is now mirrored bi-directionally – so merge requests made against gitlab will push to GitHub and vice versa. Everybody is a winner. :trophy:

1 Like

Not real descriptive, but thank-you for making this all happen. The really cool news is the GitHub for Windows users just found out that you can move, rename or whatever you want, and we don’t have to update squat! Woohoo for auto-mayshun!

What did I need to describe @aethelwulffe?

Oh, it isn’t a real concern. My git client updated to the new repo names and I thought “What the heck is an lh-ehr?” I thought, well, if it has to be abbreviated for the convenience of the CLI-only users to save keystrokes, I thought, “Well, couldn’t we at least have some cool acronym? What would that be? I guess LIEHR! Uh…wait…that doesn’t sound too good!” :confused: That did lead me to noticing that the repos don’t have descriptions on the GitHub site, or rules about usage for the auxiliary repos for image resources and external dev tools and the like.

Uh, actually, now that I look at things, changing the name of the repo may actually affect some things. LibreEHR, now presumably named LibreHealthEHR is not a project that has to be built. The name of the repo essentially becomes the directory name it is given unless someone intentionally changes it. That means the the standard installation documentation needs to be changed to make allowances for this. Adding special characters into directory names (and URL’s) isn’t something I am a big fan of, but I feel there is a real consistency issue here. Presumably we need to do a massive commit that once again changes a ton of text and even table name prefixes to add the “Health” part in, but I think based on a number of factors, either leaving it LibreEHR or redoing the “Liberation” commit to add ‘Health’ is wiser than accommodating a hypenated version of an abbreviation (initialization, technically). Often people are typing in the url. I think an unpronounceable bit in there may cause some issues for…average…users.

1 Like

I’d prefer that over going back. The reason I chose that is that it is inline with other project’s repos.

I’d recommend making those changes this week. One of the tasks I made was to create a screencast setting up LibreHealth EHR on Mac OSX and Windows(they’re separate tasks)

Prefer what over going back from what? I are cornfused…'cause I confused the situation…

You mean changing all the documentation and all of the installers and a few thousand lines of comments and code vs the repo name?

A post was split to a new topic: Should the git repo for EHR be renamed to something else?