Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

One of the “Menu Set” CMS Final Rule Meaningful Use Stage 1 objective and measures specifies that “at least 40% of all clinical lab tests ordered whose results are in a positive/negative or numerical format are incorporated in certified EHR technology as structured data.” Additionally, the Certification Commission for Health Information Technology (CCHIT  - certifying body for EHRs) indicates via IO-AM 07.02 that “The system shall provide the ability to receive and store microbiology laboratory results with organisms recorded as free-text. (Not MU).” This brings to question the handling of interfacing microbiology results into the EHR.

Microbiology results are often longer, textual results including sensitivities. Additionally, microbiology results can have 3 levels of hierarchy:

1. Orderable item(s) (Urine Culture)
2. Culture(s)/Organism(s) (Light Growth Escherichia Coli)
3. Susceptibility(ies) (Amplicillin)

The problem is that most EHRs are not well-suited to rendering interfaced results with three-levels of hierarchy; rather, the EHR is suited for just two levels of hierarchy:

1. Orderable(s)
2. Resultable(s)

When the interfaced result is sent by the vendor as a “discrete” result, the result likely will not render in the EHR properly:

To accommodate for this, most vendors have the capability of sending the interfaced result as “non-discrete,” or in other words, sending a free-text version of the result.  However in an instance where the vendor is able to send “discrete” microbiology results only, the interface analyst is charge with developing a interface customization to translate the “discrete” result to file into the EHR as a “non-discrete”:

The disadvantages of filing the result as “non-discrete” include the likely lack of ability to aggregate or report on these types of results.

For reference the original printed report from the Laboratory Information System (LIS) for the example above (recall that if an interface is not setup, this is the report that is usually provided by the LIS via fax).

Please contact sales@galenhealthcare.com if you or your organization would like assistance in interfacing discrete/non-discrete results to your EHR.

Tags: Allscripts Enterprise EHR, CCHIT, Certification Commission for Health Information Technology, ConnectR, Database, Enterprise Order, HL7, Integration, Interfaces, Interoperability, Laboratory Information System, LIS, Meaningful Use, Microbiology Results

Currently, exchange of clinical data in and out of the Allscripts Enterprise EHR is facilitated via stored procedures. This  application programming interface (API) approach certainly comes with its downsides. In this article, we propose a re-design of the API to segment out the data and the configuration components of clinical data exchange.

At the outset of an interface project where there has been precedent set (existing Quest or LabCorp <-> AE-EHR order/result data exchange deployments), we almost always get the following questions from the vendor:

• Shouldn’t the interface be the same from client-to-client?
• Why do we need to pay Galen (vendors will often times subsidize the cost of interfaces) to design a known interface deployed across hundreds of clients?
• Why do we need to reinvent the wheel?

Now these are very valid questions. And the response is as follows: Due to the approach utilized with the Allscripts interface API, an interface designer must take care in translating data extracted from outbound stored procedures into a valid, compliant HL7 message the vendor can accept (ORM for orders) and also take care in translating an HL7 message from a vendor (ORU) into a stored procedure call which sets both data elements and configuration options. To help guide the client and vendor through design decisions, Galen provides interface-specific (document, result, immunization) questionnaires.

Back to our proposed re-design: segmentation of the data elements (patient first name, provider ID, order item code) and configuration settings (enable tasking, utilize NPI for provider matching, utilize EntryCode for item matching – setting the traditional form parameters of the inbound stored procedures). With this approach, the vendor is responsible for providing the data elements as they normally do in the HL7 message (ORU for results), and the client sets the configuration settings via a workplace within the TWAdmin context in the AE-EHR – much as they do to set application preferences:

We have covered AE-EHR inbound interfaces quite well, so let’s address proposed re-design for outbound interfaces. Instead of each client requiring a site-to-site VPN and individual interface deployment, what if Allscripts chose some of its top vendor partners (Quest, Labcorp) and offered the capability to exchange out of the box, without the need for one-off interfaces? This approach is somewhat analogous to that of Surescripts acting as the hub and router for electronic prescriptions. In the case of outbound interfaces (orders for our example), there would still be the need to segment data (patient, provider, item) from configuration settings (a setting to enable or disable sending insurance information – IN1 segment of an HL7 ORM order message).

In conclusion the Allscripts clinical data exchange API serves its purpose quite well, but it could do a better job. Much of the functionality is derived from legacy, antiquated methods. Our hunch tells us that in promoting themes of Community Exchange and Connecting, the “new” Allscripts will be addressing this in short order.

Tags: Allscripts Enterprise EHR, ConnectR, Database, Enterprise EHR, Enterprise Order, HIE, HL7, Integration, Interfaces, Interoperability, Meaningful Use, Results Interface, Technical

Galen Healthcare Solutions will be hosting a series of free webcasts covering ConnectR interfaces.  The purpose of these webcasts is to provide insight into advanced troubleshooting methods as well as advanced design and configuration options within your ConnectR environment.  We will cover various aspects of interface design, development and maintenance as well as best practice techniques.

These will be structured in a similar format to university courses – the initial three classes will be at 100, 300 and 500 levels.  The list of the webcasts and their times may be found below.

100 Series – Configuration and Deployment of Imagelink: Overview of Imagelink configuration within the AE-EHR and implementation of corresponding result interface dependencies.

• Wednesday, May 19th, 2010 at 2:00pm EST

300 Series – Advanced Troubleshooting: Error analysis and resolution as well as custom techniques for error remediation

• Wednesday, June 23rd, 2010 at 2:00pm EST

500 Series – Advanced Design: Interface filtering techniques and interface-driven tasking

• Wednesday, July 21st, 2010 at 2:00pm EST

To attend, please contact Justin Campbell, justin.campbell@galenhealthcare.com.You must be an existing Allscripts Enterprise EHR client to attend.

We also offer training courses and reporting services for the Allscripts Enterprise EHR database, ETL database, Analytics and the ConnectR  database.  Please contact sales@galenhealthcare.com for more information regarding these courses and our reporting services.

Tags: Allscripts, Allscripts Enterprise EHR, ConnectR, Database, Galen Webcast Series, HL7, Integration, Interfaces, Interoperability, Meaningful Use, SQL Server

Galen will be hosting another in Enterprise reporting workshop this coming March.  This has been a popular course, so please sign up early!

What: A three-day course for report writers, DBAs and those in healthcare informatics on the Allscripts Enterprise EHR database.
When: March 1 – 3, 2010
Where: Boston, MA
Price: $2,500

The Galen Database Architecture and Reporting Workshop has furthered our understanding of the Allscripts Enterprise EHR database.  The clear presentation and substantial hands-on time helped us to greatly accelerate our production of customized reports.  And, the data dictionary documentation alone is invaluable.
– Chris Hyde, DBA, Albuquerque Health Partners

The attached announcement includes additional information regarding the course and suggested audience (report writers, DBAs, etc).

Please contact Mike Dow to register, or if you have any questions – mike.dow@galenhealthcare.com

Tags: Allscripts Enterprise EHR, Crystal Reports, Custom Reports, Database, EHR, Reporting, SQL Server

One of the many challenges in interfacing to the Electronic Healthcare Record is patient identification and matching. Results and documents from outside systems need to link to the correct patient record. This is especially profound in data conversion initiatives. Given the scenario of an organization converting to utilize an EHR, aside from the plethora of documents being scanned in and associated with the chart as well as “bulk loads”  from the practice management system, there are could also be several data silos which need to feed data into the EHR.

We encountered one such scenario with one of our clients. Our client had been processing and loading flat-files from its legacy systems into the EHR. The client loaded approximately 15 years of legacy data (equating to millions of records). In the import process, the client had followed a strict patient matching criteria and received a patient matching error rate of approximately 5% which may be considered a reasonable matching rate.

However, the client’s help desk was getting a multitude of calls reporting missing legacy system records in the EHR (suspected to be in the 5% that did not make the conversion). The issue working against the client was a drop-dead date upon which these legacy systems were being deprecated and thus the clinicians would no-longer have a “fall-back” plan to access the records – the repercussions of which were potential patient care issues.

As such, Galen was engaged to analyze the records that did not meet the strict patient matching criteria , determine which records could be successfully loaded to the EHR under relaxed patient matching rules, and describe the impact of relaxing the patient matching. In the analysis that followed, it was recognized that in the data set that erred due to patient matching errors, identifier fields (namely first name, last name, DOB, MRN, Other Number1 and Other Number2) exhibited typos and inconsistencies. Enter Microsoft SQL Server Integration Studio’s (SSIS) Fuzzy Lookup Transformation. For those unfamiliar with fuzzy logic, it is “the process of reaching conclusions based on information and facts that are not 100 percent certain.”

The underlying algorithm to the Fuzzy Matching transformation is the SOUNDEX function:

• In the late nineteenth century, United States census officials faced a dilemma. During the process of counting the huddled masses, our public servants created a huge paperwork trail that the law required them to preserve for future historians. With amazing forethought, they realized that people searching for records might not know the exact spelling of their ancestor’s name. Was it Smith or Smythe? Chapple, Chapel or Chapelle?

• To ease these searches, census officials turned to the Soundex phonetic filing system. This system uses a simple phonetic algorithm to reduce each name to a four character alphanumeric code. The first letter of the code corresponds to the first letter of the last name. The remainder of the code consists of three digits derived from the syllables of the word.

• Largely unused outside of the halls of government and genealogy, the Soundex system is making a comeback in modern databases. Database developers have long struggled with the problem of matching words that might not look alike, but actually sound alike.

Thus to reclaim some of the records that erred in matching to a patient chart in the EHR, the Fuzzy Matching transformation was utilized. Flat-files output from legacy data silos were input, pre-processed and then fed to the transformation. Given previous studies, the matching criterion utilized was as follows:  Match on LastName and FirstName Similarity Threshold >.8 AND DOB matches exactly AND one of three (MRN, OtherNumber, OtherNumber2) cross-referenced match exactly. The end result was reclamation of close to 25% of those legacy system patient records that originally failed patient matching.

If your organization is looking for assistance in data conversion, please contact sales@galenhealthcare.com and visit our website for more information regarding our technical service offerings.

Tags: Allscripts Enterprise EHR, Data Conversion, Database, Integration, Patient Matching, Technical, TouchWorks

Galen Healthcare Solutions will be hosting the second series of free webcasts covering Allscripts EHR Reporting.  The purpose of these webcasts is to provide insight into reporting options within your EHR database.  We will cover approaches to reporting, database structure, and hands-on querying of the EHR database.

These will be structured in a similar format to university courses – the initial three classes will be at 100, 300 and 500 levels.  The list of the webcasts and their times may be found below.

100 Series – Introduction to the Allscripts EHR Database: Overview of the database, patient demographics and dictionary linking.

• Wednesday, December 2nd, 2009 at 2:00pm EST

300 Series – v11 Order and Results: querying configuration and patient data.

• Wednesday, January 13th, 2010 at 2:00pm EST

500 Series – Advanced ConnectR Architecture and Querying

• Wednesday, February 3rd, 2010 at 2:00pm EST

To attend, please contact Mike Dow, mike.dow@galenhealthcare.com.  You must be an existing Allscripts Enterprise EHR client to attend.

We also offer training courses and reporting services for the Allscripts Enterprise EHR database, ETL database, Analytics and the ConnectR  database.  Please contact sales@galenhealthcare.com for more information regarding these courses and our reporting services.

Tags: Crystal Reports, Database, Reporting, SQL Server