Web components for libreHealth EHR

I wanted to post on something that me and @sunbiz have been brainstorming about

Is it possible for the new UI feature of LibreHealth EHR as part of #community:gsoc (or any other awesome project) to deliver web components of the UI. Hypothetically if this happened , we can integrate with toolkit backend – which would be awesome! pretty easily in my opinion …

Anyway I would like to hear thoughts from @aethelwulffe @tony and the LH community

2 Likes

Hi Judy! I am trying to get my head around “deliver web components of the UI”. I think you are saying “when developing a new UI piece, see if it can talk to the Toolkit backend as well”. Is that close to being right? What I can say right now: We want to expand the implementation of the FHIR common set of metadata in the EHR. That would at least give us a sort of a translation matrix between the two. It is long past time since we started a database crosswalk between toolkit and EHR, but my attempt to do so sort of went off the rails due to the massive difference between the two. Lots of things that didn’t exist in the Toolkit, and lots of things implemented in a dozen different slapshod manner in the EHR. Priyanshu is going to be working with me as a mentor to move the off of mysqli and to PDO. After this, I believe the main push with our back end will be to bring some sanity to the database. The idea is to utilize something like EloquentORM in this effort. Do you or Sunbiz have a list of requirements, or better yet, an example of a practical application we could try to implement? -Obviously, the EHR needs to be able to get information from the Radiology tool. It would be plain silly to not also ensure that the radiology module can get information from the EHR.

@aethelwulffe @sunbiz

I am trying to get my head around “deliver web components of the UI”. I think you are saying “when developing a new UI piece, see if it can talk to the Toolkit backend as well”. Is that close to being right?

Yes this is what i mean… I think the problem is we are all not talking to each other … since we are actually moving the toolkit backend to use FHIR … Whats PDO?

When we mean by a web component … we are saying we could write a small component that say searches for a patient , or displays patient order etc … If these were built against the backend of FHIR , then we could hypothetically reuse the web components for either EHR or toolkit seamlessly and help with the transition

As for radiology , After June (I have my board exams coming up ) I want to spend a little more time flushing out how the two will communicate as i think this will be a big value add… what i am saying is I will be bothering u a lot come June

1 Like

Well, I have actually been waiting on a toolkit collaborator to pop up. It think I already guessed it would probably be you. :slight_smile: Let me just say that we can do what you are asking pretty darn easily in practice…but that would be just practicing! What we want to do is write this to some sort of standard. That standard would come with the PDO connection functions that will soon be implemented. These, in of themselves, are also not a big deal, but the person(s) doing them will get to make those decisions, and we get to follow their queue. After that, we simply write a script to connect to the Toolkit database, run some queries, then display them on the screen (or any other similar dual-direction functions). I am not sure about displaying NPAPI applets within the iframes of the EHR these days, but anything that is done on any webpage anywhere can be done in the EHR…cause it’s just a web-page…nothing more really. You like a piece out of it? Grab it, or scrape its HTML output and use it somewhere else. There aren’t many restrictions there.

PDO is a PHP data Object. Basically it is a database driver. Currently, we have been using two others, mysql extension(deprecated), and mysqli (which is the preferred). PDO syntax is different than mySQLi, so we are not going to totally replace the use of mySQLi (re-write everything). Doing so would be a huge effort, and frankly mySQLi is faster and more feature-rich in many many ways than the PDO thingie.

To invite discussion on how this affects these future Post-June (June and Judy!) plans, I am going to kind of go over where I think we are based on getting data from one system to another. I will start this off by going on and on for a while about the PDO thingie, because those decisions affect us more immediately.

The PDO thingie

PDO can’t do everything, because it is sort of like a generic (or linux) video driver. It works for a lot of things and and all, but doesn’t give you any of the deep features like mySQLi. What we want is to start using BOTH simultaneously, but in a careful and well documented way. The Pros of PDO are the following:

  1. Can connect to 12 different flavors of database. This is useful for possible database neutrality in the future…but that is a lofty goal due to SQL differences.

  2. Can name and make multiple connections to multiple databases (even of different types) simultaneously.

  3. Allows named data objects (named parameters specifically) in queries.

I think that all three of these will be useful in the future. The last one on the list would take care of a number of issues for integrating with other tools in an async sort of way. Look at the following:

public function test( PQRSPatient $patient, $beginDate, $endDate )
{

$query = “SELECT COUNT(b1.code) as count “. ” FROM billing AS b1”. " JOIN form_encounter AS fe ON (b1.encounter = fe.encounter)". " INNER JOIN billing AS b2 ON (b2.pid = b1.pid)". " INNER JOIN pqrs_efcc3 AS codelist_a ON (b2.code = codelist_a.code)". " WHERE b1.pid = ? “. ” AND fe.provider_id = ‘".$this->_reportOptions[‘provider’]."’". " AND fe.date BETWEEN ‘".$beginDate."’ AND ‘".$endDate."’ “. ” AND (b2.code = codelist_a.code AND codelist_a.type = ‘pqrs_0249_a’) “. ” AND b1.code = ‘88305’; ";

$result = sqlFetchArray(sqlStatementNoLog($query, array($patient->id))); if ($result[‘count’]> 0){ return true;} else {return false;} }

The question mark in " WHERE b1.pid = ? ". is from the first parameter (argument) passed to this function, which is $patient.

" AND fe.date BETWEEN ‘".$beginDate."’ AND ‘".$endDate."’ ". could have been said like this:

" AND fe.date BETWEEN ? AND ? ". …because these are the second and third argument passed to it. The problem is, you have to make sure you have everything in order right, or things get really scary wonky, so sometimes we chicken out and just use the variable name with a whole mess of quotes and concatenations.

Another way we pass arguments to construct a query is like " AND fe.provider_id = ‘".$this->_reportOptions[‘provider’]."’". where we have stored the values in an object’s instance state and made it accessible.

So, here in a single function we have three ways we have used to construct a string for a query in this test function. After writing a few thousand test queries, you stop worrying if it is pretty and just want it to work. With PDO, we can bind the parameters (arguments) by name instead of with question marks keyed to the order described in the function. This will both allow us to connect both systems together without FHIR, and help us keep the integration methods between the two standardized with strict parameter naming conventions.

One thing i don’t understand is how you will implement FHIR

Are you going to make the EHR work as a FHIR server?

1 Like

Let’s get Tony to answer that. Right now, all it does is schedule appointments…and the scheduling system is getting replaced. Implementing FHIR data types is stage II for my interests (though very interested). The pieces are all there as far as I know.

I think instead of going the database level route to integrate toolkit and EHR, using the FHIR model is a more efficient and forward-looking route. We should probably start with the simpler and more commonly used FHIR resources and implement those in both the tools. and then like @judywawira says, use the web components to provide a UI. We can quickly integrate some very useful features, if we build web components that both projects can reuse.

I hear you. Going straight to FHIR is really the better route vs. just cross-walking the two databases, but… Let’s see. If I was running an EHR based in PHP and JS, and I wanted to give it the ability to deploy with a JAVA module built onto it on the same system, I would probably have it all in the same apache stack with php and Tomcat (if possible) ready to deploy with a click. If I were doing that, I would probably just have the UI components that need stuff from the Java module’s database simply read it from there vs. running it through another middleware layer. This is faster in operation by far, yes, but as a development model it really lacks. That, however, isn’t the important point. The important bit is to not re-invent the wheel and cause ever expanding FHIR implementation issues as we go along. If that allows a developer to directly access two DB’s using the same field names, so much the better, but why waste a perfectly good schema (FHIR) when we have to talk to and with it anyway?

Even if, on the same machine, the web components in the EHR that want to access the radiology module (for instance) are always going to be going through FHIR, there is still the requirement to map matching data fields on both sides. This could be done independently on each side of the street, and then they should all just match up, right? Hmmm. Probably, we hope. On the other hand, having someone around here familiar with both schemas would be a good idea, I should say. In addition, there are lots of bits that exist in both schemas. These need to be mapped to the FHIR data types of course, but no harm in making it a foo->foobar<-bar matchup from the git-go. There are also LOTS of stuff that has no cross-over corollary, or (in the EHR) needs refactoring anyway. If we are doing this in a way that approached unity, we can match field names in both schemas from the outset. Naturally, if it exists in neither system, we should use the FHIR field name wherever possible.

That last point brings us to some issues in the EHR we recently debated. Vertical tables for lists of contacts (telecom types as a FHIR example) and abstraction touch lists are seeming to be ever more important to me, vs static fields. When refactoring these things, we should use the FHIR model wherever possible, basically using (in this case) the Cm-contact-point-system-v2 as the table schema. This makes things flow. Feng Shui and all that.