The following customer success story was written by Aaron Kelley, lead software and database developer at STARS.
STARS—Strategic Administrative and Reimbursement Services, LLC—is a wholly owned subsidiary of Advanced Radiology Services, PC . Both companies are headquartered in Grand Rapids, Michigan. ARS is one of the largest privately-owned radiology practices in the country, and provides radiology services for eight major health systems throughout West Michigan.
At STARS, there are two main use cases for Corepoint Integration Engine . Our Clinical Applications team has processes running through Corepoint to handle and transform HL7 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... messages sent between our Picture Archiving Communication Systems (PACS) are devoted to the storage, retrieval, distribution, and presentation of images. The medical images are stored in an independent format, most commonly DICOM. Synonyms: Picture Archiving Communication Sys..., dictation software, enterprise worklist software, and our health systems. Our Data Management team uses Corepoint to handle receiving and processing data coming back from the health systems used to drive billing and business analytics. I work in the Data Management area so these are the processes that I will be exploring.
Originally, Corepoint was brought in to replace Mirth Connect, bringing along with it high availability, greater ease of use, and more strict HL7 support.
From each health system, we expect to receive HL7 demographics (ADT) and reports (ORU). The reports contain information about the reads carried out by our physicians as well as the physician’s dictated report for each procedure. The demographics contain additional patient information, including insurance information, which is not present in the report. Together, these contain all of the information that we need to bill for the completed procedures.
While the main use case for Corepoint is to handle HL7 messages received in “real time” over a TCP connection, most of our health systems deliver the billing data in a pair of batch files received once every 24 hours—one file containing demographics information and the other containing the reports.
The files are created overnight by the various health systems and contain demographics and report messages for procedures carried out the prior day by our physicians. The files are left on an FTP server for Corepoint to pick up.
In Corepoint, connections using the FTP Gear as the source are used to pick up the files and hand the data over to an action list. Because the files will contain many HL7 messages, the message cannot be loaded as HL7 into Corepoint until it is split into individual messages.
The message must be first loaded unparsed and then split using the ItemSplit command in Corepoint. Each individual message is stored in a SQL database. Individual messages are checked to see if they are duplicates of prior messages; if so, they are ignored. Then, the messages are passed over to a child action list for individual processing.
The child action list performs actions that are more typically seen in Corepoint, moving data between fields and reformatting it in such a way that our billing software will be able to use the result properly.
When the transformations are completed, the individual messages are sent to another connection using the File Gear to write the messages out to a file that is loaded into our billing software. Using a child action list to process the individual messages also makes testing simple.
In Corepoint Integration Engine’s Configuration, the “Load Messages from a File” command can be used to bring in a large selection of messages that can be tested against this child action list. Also, the “Base Run” feature makes it easy to check the output of the Corepoint Action List code when first switching over from Mirth Connect, quickly spotting cases where the output between the two systems was not the same.
Unfortunately, not all of our sites send HL7 messages. Some demographics or reports are received in delimited text files. In this case, the child action list must extract the interesting pieces of the message and create an HL7 message with the data populated appropriately.
The extensibility of the Corepoint Engine allowed us to expand on the built-in functionality of the Corepoint Engine to handle some use cases that were outside the realm of normal processing. This was accomplished using custom C# code that is called from Corepoint.
Data reporting and analytics
STARS also has a Decision Support team that is responsible for the corporation’s business analytics and data reporting needs. Over the past few years, data-driven business analytics has become a big part of Advanced Radiology Services operations.
The data received for billing also contains a lot of information that can be used to make business decisions. As such, in addition to passing the reports to our billing software, certain HL7 fields are loaded into our data warehouse for our analytics team to use for various purposes.
The exam end time (OBR-8) can be compared to the dictation end time (OBX-14) to compute turn-around time—a measure of how long it took our physicians to complete a read after the actual imaging was completed. This can, in turn, be used to drive scheduling and shift coverage decisions, making sure that we have the correct physicians available to cover all modalities, at all sites, at all times of the day. Also, physician productivity reports are generated using data that comes from these messages.
STARS also uses this data to map our patient demographic information across the regions that we serve. This allows us to better understand where we can provide additional services to meet patient needs. This data is used to answer the many daily questions posed to the Decision Support team by the management team.
Where possible, we are trying to move our health systems away from daily batch files and towards TCP HL7 connections so we can perform more real-time monitoring. We are also starting to process order messages (ORM) for some sites. These are not needed for billing, but will give us a better understanding in advance of what reads we have in the work list queue.
Having a measure of how big our potential work queue is allows us to make better decisions on coverage and when we might need to call a surge and bring on additional radiologists when things are particularly busy.