Roberts-Hoffman has experience developing healthcare applications utilizing open source technologies. We can help you design and develop solutions to healthcare problems, such as CPOE, medication ordering and alerting, managing lab results, bi-directional HL7 interfacing, and vitals tracking. Please visit our services listing for more information about what Roberts-Hoffman has to offer.
For July of 2013 we have bundled a pretty large update, which includes some advanced interface features. One predominant feature is the bi-directional occupancy management between the EHR system and the HIS system. For our inpatient facility, end-users have the option to make patient location changes in either system, and so we needed to make sure both systems have the most current information. Prior to this release, the discharge operation happened only in the Medical Records department, and often not until several days after the patient had left. Consequently, we added a discharge wizard to the EHR system that allows the clinical staff to indicate that the patient has left, and remove the entry from the inpatient list. But wait, there’s more…
In addition to discharging the patient, the nurses will add a discharge note at the same time, and they can also provide information pertinent to Clinical Quality Measures (CQM), too. So, we made a dynamic wizard for discharge that allows the nurse to do all three at once upon discharge. This, again, is like the CPOE wizard we created, which creates a single document but multiple separate placeholders for the items therein. First, the discharge information impacts the encounter placeholder. Then, the discharge note creates an electronic nursing note that is added to the note list with a focus word of Discharge. Finally, the CQM information updates its own list and portlet. To preserve the integrity of the data, if the nurse nullifies the discharge event (because it was entered in error), then the system will locate and nullify any discharge note or CQM data that was entered as part of the discharge.
All of these events automatically generate interface messages through our Mirth-based interface to the HIS system and other ancillary systems (lab, radiology, etc). All the systems get the information in real-time and everyone is up-to-date. This is a good example of using technology to help make a job easier.
The well-deserved explosion in the popularity of Mirth Connect is a testament to its versatility and stability. You can add Roberts-Hoffman to the list of satisfied users! We have been using the open source version of Mirth Connect since the first production deployment of our EHR system to manage interfaces. More recently, we have made use of the Mirth engine to perform some even more sophisticated tasks and integrate more closely with our EHR system.
There are two options for using Mirth with a Tolven Platform-based system like ours: Webservices or REST. The webservice interface is a little more basic, meaning that there are only two options: processDocument() or queueDocument(). This can be a good thing, because it is a bit more simple to configure. If you have a document processor ready to accept the type of electronic document you are working with, this might be your best option. REST, on the other hand, requires different authentication, but once you get connected you have access to quite a few native REST-enabled functions, as well as the capacity to write your own. REST is the way you want to go if you really need to access placeholder information directly as you might for matching or updating information.
There isn’t (or shouldn’t be, anyway) a production interface anywhere that doesn’t have a staging or test area. You must have portable channels in order to minimize errors when transferring between instances. Mirth gives you a nice feature set that supports importing and exporting channels, which forms the foundation for portable channels, but what about all the instance specific settings? We’ve made use of the global scripts and properties to make channels that can localize themselves to whatever environment they are deployed.
How many times to you want to parse the PID and extract the patient ID? That was the question our team began to ask as we were proliferating Mirth channels for different flavors of the ADT message series. In response to this need, we designed a system of channels that accept a message of a specific type (e.g. ADT) and perform a specific function. Then the channels essentially pass a message back and forth to complete all the necessary translations. We coupled this channel hierarchy with Mirth’s database reading capability to make these reusable channels portable by equipping each channel to know what channel to call next.
Mirth is a really great tool. It has been very stable in our production environment and it has an enormous feature-set. You can save yourself some pain if you plan your channel structure and do a little extra work to make them reusable.
If you missed it from last month, check out my initial post about order verification. We’ve put together a release including this latest feature and it has completed the QA process. Just today, it was deployed to the production environment.
I think there is something important to note about this sequence of events: It is a great example of what we love to do! First off, no small amount of credit is due the Tolven architects for designing a framework that is as flexible and powerful as it is. Beyond this, however, we must have competent developers to harness and direct the platform. The RHS team did something remarkable with the order verification workflow. Within a single 30-day development cycle, we designed and implemented a whole new step in the workflow and the life cycle of the order. Not only did this change impact the existing user experience, but also the electronic order interfaces as well. Way to go team! You can try to put a brand name (like Agile, Scrum, etc.) on this kind of work, but really it comes down to having a team of great people who are committed to excellence in customer service.