Rhapsody Health Solutions Team

Web Service Trickery: Creative Problem Solving at East Alabama Medical Center

When East Alabama Medical Center (EAMC) implemented Corepoint Integration Engine, their intent was not only to exchange health data with other internal and external systems, but also to solve for organizational IT and workflow challenges .

Jeremy Goslin, an IT Project Director at EAMC, recently presented three creative solutions they developed using the engine’s Web Services functionality to benefit both the providers and the patients in their community.

Video Thumbnail

Solution #1: Retrieving AUMC Student Data

The first solution Goslin presented illustrated a common use for web services: connecting to a remote resource to retrieve and process data to another system within their data center.

EAMC manages Auburn University’s campus medical clinic, which offers non-urgent care and immunizations to students.

Fetching New Patient Demographics

The University wanted a file dump of the incoming students’ demographic information in order to preload the patient data into the AUMC EMR system, AllScripts. That way when students presented themselves at the clinic, they would already have most of the information on hand. Having this information would both speed up the process as well as provide an easy indicator of how many new patients could potentially show up at the clinic wanting, for example, a flu shot.

However, the third-party vendor AUMC uses to oversee health insurance and immunization verification was more of an onboarding and form enrollment company, and not well versed in HL7.

Because the vendor’s initial API rollout was a website with data points, Goslin and the team built a Perl program that queried the web endpoint and pulled data down into multiple flat files, which Corepoint Integration Engine then processed into AllScripts.

Out with the Perl

The program worked fine, but what they soon realized Goslin was the only person who knew Perl scripting, along with several other potential points of failure.

Most everyone on the team was familiar with Corepoint, so moving out of Perl script and using the restful web services functionality in Corepoint Integration Engine made the most sense from an ongoing maintenance and general collective knowledge perspective.

Another problem they were able to address was replaying messages and validating the previous night’s run—which is difficult and time-consuming to do in Perl script. Moving everything into Corepoint gave them the opportunity to leverage the engine’s built-in logging, error handling, capacity to replay, and alert functionality.

“Moving it to Corepoint has made it much more reliable and easier to maintain.” — Jeremy Goslin, IT Project Director at EAMC

Now, fetching new patient demographics for the Auburn University Medical Clinic is comprised of three things: query and response for A04s, query and response for A08s, and feeding both those downstream into AllScripts. All within one application that everyone on the team is familiar with.

The change has been a win for those involved and has greatly decreased the maintenance cost of the interface while increasing usability and reliability.

Solution #2: Strategically Routing and Filtering Patient Results

It wasn’t too long ago that the number one problem healthcare organizations faced was moving and accessing data. Fast forward to today, and organizations are inundated with so much data that it can be difficult to sift through and sort. This is common among hospitals, and exactly the type of issue Goslin and the team wanted to solve for with their second web services solution.

The Firehose

The problem occurred when EAMC moved from the McKesson Star Registration system to Cerner Millennium’s Registration system. In doing so, they lost a field that previously allowed them to indicate whether someone was registered as a lab outreach patient, which primary facility they came from, and who their primary doctor was.

For example, if an OBGYN referred a patient to an EAMC lab for a urine sample pregnancy test, they would be able to indicate that in the McKesson Star Registration field marker. That way, every lab result on the visit would route back to the OBGYN.

Inpatient registration could still be somewhat simple to manage without the field marker, but the outreach registration was less clear-cut. All the results come from the same EMR and the results interface, so it would be much more difficult to know where to route the results.

“We always refer to it as a firehose. We get everything that’s happening in our Cerner system, and we’ve got to take that firehouse and fill a bunch of drinking glasses with it. We’re always looking for different ways to slice up those results and route them appropriately.”

When they discovered they were losing this functionality, they acted quickly.

Routing Unsolicited Results Around the Community

They built an internal web application that stores clinics, clinic physicians, EMRs, and the particular action list each EMR uses to receive results. As a result, Corepoint Integration Engine can query the application for routing and filtering information in order to send data to the right location(s).

“The thing that I’m really proud of about this is that with Corepoint’s web functionality, we built this in a week.”

Now the web application pulls out different variables—inpatient or outreach, final or preliminary, lab or radiology, and a variety of other indicators—from every result that leaves EAMC’s Cerner Millennium system. It also pulls a list of every physician associated with the result in some capacity—referring, ordering, admitting, attending, consulting, whether they signed, dictated, CC, or transcribed—and routes it according to how each physician has their options configured in the application’s webpage.

I Just Want “My” Results

Previously there had to be a clinic-wide consensus on what results they would receive, or else a lot of if/else logic would be required. It was a maintenance nightmare—especially any time a doctor switched clinics.

But now, one doctor at a clinic can choose to receive every type result or document that his name appears on, while another doctor at the same clinic who prefers to see inpatient results in the Cerner system can configure it to where she sees only specified outpatient or outreach results.

And if a doctor wants to change what results he or she receives, it’s completely configurable within the application’s webpage, resulting in a much quicker turnaround time.

By launching this innovative solution, they were able to reduce the number of action lists required for routing from 30-45 down to around seven or eight.

“This made our result routing more secure, easier to adjust, easier to maintain, and frankly, it looks more professional than sending an email asking: ‘What do you want to see?’”

The team already has plans for a 2.0 version of their web application with more discreet filtering options for the physicians to configure.

Solution #3: Generating Patient CCDs On-Demand

The third solution Goslin presented uses Corepoint Integration Engine to allow a third party vendor, Discus, to query EAMC’s Cerner Millennium database through a web service. Discus has an application, JointMan, that can generate patient visit notes for rheumatology clinics by parsing patient CCDs.

The workflow that powered this capability started when the rheumatology clinic registered a patient in Greenway, and once the ADT crossed into the JointMan application, it would kickback a query to Greenway for the latest CCD on that registered patient.

The CCD information is then processed and pre-filled into documentation. Once the physician visits with the patient and finalizes the documentation, JointMan generates a PDF of the visit note and sends it back to Greenway.

The Need for New Functionality

However, when EAMC migrated from Greenway to Cerner Millennium, they lost some of this functionality. Cerner would only produce a CCD as part of a manual workflow on the medical records side, or at midnight when the CCDs for every patient visit from the previous 24 hours started generating.

And because JointMan does not have any ties into Cerner Millennium as Corepoint does, using the engine to create an on-demand CCD query and retrieval process was the best course of action.

“Corepoint is one of those tools that fills almost any gap that we need it to fill. It’s sort of the glue that holds multiple systems together for us. If we have a problem where vendor A and vendor B can’t meet a solution, Corepoint is how we fill that space—and sometimes it’s how we achieve what vendor A or vendor B is promising.”

On-Demand CCD Query and Retrieval

For starters, Goslin stood a web service endpoint up on the engine and built the WSDL (web services description language).

The workflow consists of an Action List called Query Handler, which sits in Corepoint and waits to be called by a web query containing the medical record number the vendor is looking for or the request ID they want to follow up on.

When a query hits, the engine does two things:

  1. It creates, or updates, a row on a Microsoft SQL table that runs on the Corepoint server and keeps track of all the CCD queries.
  2. It also generates an HL7 message containing the medical record number and headers, and sends it to a custom-built communication server in Cerner.

This server, which is essentially a TCP/IP listener, strips the medical number from the HL7 message and runs a custom script, which initiates Cerner’s nightly CCD generation process for a single patient instead of the entire batch.

The generated CCD is hard-coded to return to the engine through a separate interface, and it hits another CCD handler that checks the medical record number or request ID against those stored in the SQL tracking table.

“This is one of the areas where Corepoint really saved me because it does this so quickly that it’s not a resource hog. Corepoint pulls it in, reads the CCD, pulls the medical record number out, checks that table, and it does all this in a millisecond. I was very afraid that it was going to be too slow, but it’s a complete non-issue.”

While the CCD is generating in Cerner, the Query Handler Action List is checking the table every three seconds for it to send as a JSON response to the initial query.

Where They Are Now

This on-demand CCD query and retrieval solution delivered savings in both cost and time to EAMC, as well as some unexpected efficiencies. It runs even faster than the original workflow in Greenway, so users can run the query whenever they like to fetch a fresh CCD.

Looking Beyond Web Services

The healthcare IT industry has come a long way from simply trying to get data from point A to point B, and technological advances continue to forge new and exciting pathways toward a truly interoperable healthcare ecosystem.

And while there will always be new challenges to overcomes, Goslin and the team at EAMC are a testament to what smart, creative people can achieve when paired with the right tools.

Learn More:

Request a demo to see Corepoint Integration Engine in action.

Related Blogs

Accelerate digital health adoption with Rhapsody Integration Engine 7.3

Shelley Wehmeyer

Accelerate digital health adoption with Rhapsody Integration Engine 7.3

The latest release of Rhapsody Integration Engine offers an efficient and simplified approach to achieving a high quality and useful data foundation.

Read more
Unmatched API capabilities within Rhapsody EMPI

Lynn Stoltz, Senior Product Manager

Unmatched API capabilities within Rhapsody EMPI solution

Understanding a person’s full health journey is critical to making the best possible decisions for their health and wellbeing. Yet, inherent in knowing the person’s journey is ensuring you have the right person's information.

Read more

Lynn Stoltz, Senior Product Manager

Realize the full potential of your data

The latest release of Rhapsody EMPI makes it easier to pull in SDOH data with advanced data analytics, new APIs and focus on scalability and performance.

Read more