Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

Introducing the Galen Clinical Conversion Toolkit, a solution and process designed to guide clients through converting from legacy systems and existing EHRs to the Allscripts Enterprise EHR. As Managed Service Organizations (MSOs) seek to expand their footprint through acquisitions, conversions to consolidate to a standardized system are often desirable to avoid the Healthcare Information System Mosaic.  Leveraging experience gained from previous clinical conversions, the Clinical Conversion Toolkit streamlines the process and provides a means of converting clinical data safely and efficiently. It should be noted that while conversions can be extremely useful in the sense that they save duplicate data entry, clients need to exercise caution in that any conversion data should be reviewed.

Discrete Conversion Types

Process Overview

• Data Extraction

• Data Analysis: Cross-Referencing

• Design: Data Filtering, Matching (Provider, Patient Item), and Exceptions/Errors

• Testing

• Go-Live

Data Extraction

Whether the historical system is an EHR such as NextGen, Greenway or eClinicalWorks, a PM such as GE Centricity, or a legacy in-house clinical information system, one of the most important aspect of the conversion will be acquisition of the data. Often times, this will require assistance with the current vendor to trigger a bulk-load export of the data. The preference is to output to flat-file, thus facilitating an intermediary step of data analysis and cross-referencing to prep the data before it is loaded into the EHR.

Data Analysis – Cross-Referencing:

The most important part to cross-referencing is to ensure that the corresponding AE-EHR dictionary dependency exists in the dictionary. If starting from a “blank-slate,” it is prudent to extract the compendium information for the exported data file from the source/reference system. In the case that dictionary entries already exist in the AE-EHR (for instance, in the scenario of a client that is an MSO, multi-org, and single EHRDB), it will be important to setup cross references so that the codes in the reference system match up to the corresponding values in AE-EHR. This is often realized through deployment of translation tables within the Clinical Conversion Toolkit.

• Provider code – Recommendation to use default “dummy” provider to identify clinical items loaded from conversion
• Document type
• Allergy code
• Immunization name, provider, route of admin, body site and manufacturer
• Problem and procedure codes
  • These codes will need to be cross referenced with the more-granular Medcin nomenclature.
  • This presents a challenge in that an ICD9 or CPT code could have a one-to-many relationship with Medcin.
  • The Clinical Conversion Toolkit provides a translation tool utilized in previous problem conversions to assist in the cross-reference.
• Vital sign names
• Order/Result Item Codes

Design – Filtering:

Filtering can be performed up-stream as part of the source/reference system extraction process, or it can be realized within the Clinical Conversion Toolkit logic. Typical filtering options include the following (but are not limited to):

• Items that have been entered in error in vendor system
• Allergies – NKA and NKDA entries are typically excluded to avoid incorrect reporting of NKA and NKDA
• Exclusion of non-finalized documents or results

Design – Matching:

Patient Matching: Patient matching is crucial to the exchange of clinical information between systems.  The Allscripts Enterprise EHR has strict matching criteria – in summary, matching on three of the four of the following: Name, Date of Birth, Medical Record Number (MRN) and Social Security Number (SSN).  As there is a move away from using SSN, by patients at least, this leaves us with only three fields to match on for many patients: Name, Date of Birth and MRN. In certain cases, more advanced options for patient matching can be deployed such as fuzzy matching as previously described on our blog.

Provider Matching: Clinical items will need to tie back to the provider who originally entered, ordered or authorized.  Typically, a short numeric or alphanumeric identifier is used to link a provider entry in the Other Vendor’s system to the provider entry in the EHR.  The current trend is to use a provider’s National Provider Identifier (NPI) as the identifier that the two systems exchange.

Design – Exceptions:

Not all of the data will load to the EHR without error. Some records will require manual assistance via add-on tools such as Allscripts Patient Bridge, while others may require more advanced troubleshooting and re-file. The Clinical Conversion Toolkit takes care of logging those transactions which generated error for future reference.

Contact:

Please contact sales@galenhealthcare.com if you or your organization would like to learn more about Galen’s Clinical Conversion Toolkit for the Allscripts Enterprise EHR.

Tags: Acquisition, Allscripts Conversion, Allscripts Enterprise EHR, Clinical Conversion Toolkit, Data Conversion, Enterprise EHR, Integration, Interfaces, Interoperability, MSO, Multi-Org, Technical

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 is proud to announce that we will be continuing our popular series of free webcasts this fall related to Allscripts Enterprise EHR.   These Webcasts will cover topics including Analytics, Allscripts Enterprise EHR Note, Interfaces, Reports, Allscripts Enterprise EHR Orders, Tech System maintenance.

Learn more »

Tags: Allscripts, Enterprise Order, Galen Webcast Series, Integration, Interfaces, Meaningful Use, Technical

Galen Healthcare Solutions will be hosting a series of free webcasts covering the Allscripts EHR database and Allscripts Analytics application.

The purpose of the EHR webcasts is to give a detailed view into the underlying database schemas as well as useful queries for the Patient and Order/Results tables. For Analytics we will be covering a basic overview of the Analytics applications as well as detailed examples using Worksheets and Crosstabs. 

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

Allscripts EHR – Patient: Overview of the Patient tables as they relate to the Allscripts EHR Database. This course will cover basic concepts related to Patient tables, as well as useful queries, views and general best practice techniques. 

• Wednesday, June 2nd, 2010 at 2:00pm EST

Allscripts EHR – Order/Results: Overview of the Order/Results tables as they relate to the Allscripts EHR Database. This course will cover basic concepts related to Order/Results tables, as well as useful queries, views and general best practice techniques. 

• Wednesday July 7th, 2010 at 2:00pm EST

Allscripts Analytics: Overview of the Allscipts Analytics application. This course will cover basic concepts related to general functionality of the Allcripts Analytics applications, including example Worksheet and Crosstab problems as well as general best practice techniques. 

• Wednesday August 11th, 2010 at 2:00pm EST

To attend, please contact Dave Boerner, Dave.Boerner@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: EHR Certification, Galen Webcast Series, Technical

We here at Galen have seen a greater influx of requests to be able to integrate client’s EHR environments with 3rd party applications and/or internet websites.

I’ve created a few examples that I’ve added to our Wiki page.

1. http://wiki.galenhealthcare.com/Patient_Portal_Integration

With this case study Galen had a client who has implemented a patient portal application whereby patients are able to send messages to their doctors regarding tests, results and general questions. The client was looking for a way to have the provider be able to integrate this application directly into the EHR. With RelayHealth’s help we have succesfully built a prototype whereby a provider can seamlessly communicate with a patient in the most efficient manner possible!

2. http://wiki.galenhealthcare.com/images/5/57/Add_new_Web_framework_documents_to_the_EHR.pdf

In this example a client was looking for a new link on their vertical toolbar which would allow them to display any website in their current workspace (the main viewing pane of the EHR). This one example integrates the website directly into the EHR window without having to navigate through a new tab or window, showing a FRAX calculator. The other tab actually has the ability to take in patient context (height, weight, blood pressure, etc.) and pass it into a form automatically populating fields to save physicians valuable time. This article goes through the steps involved in setting up new vertical toolbars, horizontal toolbars, and workspaces to set up these outside websites in the EHR. The actual code to populate patient context is fairly complex but definitely something Galen would love to help out with!

Tags: Allscripts, EHR, EHR Implementation, HL7, Integration, Successful EHR Implementation, Technical

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

The requests for reports that we get runs the gamut. Most of the time, clients are looking to modify the existing canned reports that Allscripts offers with the Allscripts Enterprise Electronic Health Record (AE-EHR). Other times, clients envision a custom report that is unlike any of those currently offered and is unique to their particular organization. And still further, some organizations wish to fulfill reporting metrics to receive monetary incentives from initiatives such as the Physician Quality Reporting Initiatives (PQRI) and P4P (Pay for Performance) .  Given the commonalities in the requests we receive, with our reporting solutions store, we have attempted to pick the most popular reports requested from clients and offer them via on-demand payment, download and installation.

We also receive a substantial amount of inquiries from clients as to what exactly goes into customizing existing reports and creating new reports. Clients are often curious as to what types of skill sets are needed. These organizations may feel that they are better suited to have their own personnel develop custom reports. For instance, the organization may have performed an return on investment (ROI) analysis and determined it makes the most financial sense to train their own staff to supply the multitude of administrative and “print” reports they require in the coming future.

That said, let’s get to answering the question of what goes into developing custom reports for the AE-EHR:

1. AE-EHR Clinical Database Stored Procedures: These are used to extract data out of the database to render in the report. The stored procedures can be thought of as a “middle-man” between the database and the Crystal Report. More information on the basics of stored procedures can be found via the following link.
2. Crystal Reports: Most AE-EHR reports are developed using Crystal Reports. Crystal controls the how the data extracted from the stored procedures renders in the final report. Crystal offers functionality for pivot tables, summary of data fields, grouping, custom formulas, suppression based upon data values, etc. For more information on Crystal reports tutorials, follow this link .
3. Insert Scripts:  There are several places that reports can be installed within the context of the application’s user interface (UI) – these are called “Calling Points.” Reports can be printed from the administrative workplace, and also added to the UI for the traditional “print documents” – immunization or results “calling point” for instance.

The most important ingredient to custom AE-EHR report recipes comes in the experience – specifically knowledge of the database schema. Knowing what tables to pull from, how tables are related, and what functions, stored procedures and existing custom reports can be utilized so as to not re-invent the wheel. Knowledge of advanced SQL querying is invaluable as well. If you would like to learn more, Galen is offering free EHR Reporting webcasts.

Let us know if we may assist your organization in developing and delivering custom AE-EHR reports. In addition to the reporting solutions store, 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 Enterprise EHR, Crystal Reports, Custom Reports, Extensibility, Reporting, SQL Server, Technical

The name of the game in Healthcare IT is problem-solving. As such, I find this is where my own background in engineering benefits me in that I  was taught to take a methodical approach in troubleshooting and root-causing technical issues, fully documenting findings and results. That said I would be remiss if I did not mention some invaluable tools which aid technical issue investigation:

A Healthcare IT professional’s tools of the trade (must-haves):

• SQL Profiler
• Diff software (Notepad++)
• HTTP analyzer (Fiddler2)
• Screen capture software  (Printkey2000)
• Paint.net
• Windows Process Monitor
• RedGate tools (SQL Toolbelt, Reflector)
• HL7 Editor

In addition to the technical component of the job, an equally-important component is communication. I’ve found that utilizing the proper communication channels can drastically reduce problem-solving time and effort. As Dr. Halamka alludes to in his blog yesterday, a good rule is if more than 3 rounds of emails go back and forth about an issue, it’s time to pick up the phone or have a meeting.

The first step in investigating an issue starts with having the proper background information provided by the client. Utilization of an issue submission form is invaluable to document all items surrounding the issue. With incomplete background information, the Healthcare IT professional is forced to solicit more information from the client – forcing unnecessary additional communication and driving up the time-to-resolution.

Once background information has been assimilated and an email thread has been opened, if the issue cannot be resolved in more than 3 rounds of emails as alluded to above, a conference call should be scheduled. The components and outcomes for a successful healthcare IT technical troubleshooting conference call are as follows:

• Well formulated problem statement and documentation provided to all parties on the call
• Issue submittal form to include short description, full description, screen shots, steps to reproduce, onset, frequency, users/devices affected, etc.
• Skeleton Agenda
• Ensure that the right representatives are on the phone (RIS analyst, Lab HL7 interface analyst, etc)
• Vet issues related to the different “layers”
  • Application Analysts
  • PC/Desktop Techs
  • Network Analysts
  • Server Techs
  • Server Architects
  • Storage Architects
  • OS Architects
  • DB Architects
  • Application Architects
• Action items for representatives if the problem is not resolved
• Eliminate misinterpretation via oral communication
  • Representative 1: “This is what we are expecting”
  • Representative 2: “Really? Wow, we never expected that.”
  • Representative 3: “We never would have interpreted the spec to mean that”

And finally, for a great article addressing troubleshooting complex IT problems, please see Dr. Halamka’s blog article posted in December of last year.

Please contact sales@galenhealthcare.com and visit our website for more information regarding our technical service offerings.

Tags: Allscripts Enterprise EHR, Integration, Interfaces, Technical

More often than not – in the healthcare IT industry especially – the expectation is that “we want it done yesterday.” That said, it is not so surprising that often the first item addressed in discussing a new interface is the go-live date. Recently we faced two client projects that fit the aforementioned mold with fairly accelerated time-lines for their data exchange implementations with the Allscripts Enterprise Electronic Healthcare Record (AE-EHR). However, with a little bit of luck and more so by following the interface project recipe for success outlined below, we were able to bring the interfaces live within 30 days of project kickoff.

Break the interface project up into phases, and assign reasonable deadlines to each phase, identifying any dependencies up-front:

1. Candidate – Initiated by the client, schedule kick-off call with Interface Analyst and Vendor
2. Scope – Client review of high-level architecture and requirements with Interface Analyst
3. Client Approval – Client signs-off on interface design
4. Development – Interface Analyst implements interface in test/development environment, establishes connectivity and performs and validates unit test.
5. Client Review – Client validates that interfaces are built to meet the needs of the organization. Clinician/End-user review is strongly recommended.
6. Go-Live – Interface Analyst moves interface from test/development environment to production environment during non-production hours and connectivity/smoke test is performed.

Factors that influence the success of an interface project:

• Motivated client
• Motivated vendor
• Environment access up-front: Systems login and access, interface engine login and access, EHR login and access.
• Systematic approach
  • Configuration options presented and discussed up-front.
  • Decisions concerning configuration are documented.
  • Weekly status calls with vendor/client and action item assignment
• Preparedness
  • Documentation of current client work flow/data flow supplied for interface design.
  • Functional prerequisites complete before volume testing phase
    • Connectivity setup
    • Unit test
• Complexity of the interface
  • Standard versus custom interface
  • Excessive business logic requirements (maintenance and supportability concerns).
• Dependencies in place: Module (such as charge, order or immunization) functional & stable and pertinent bulk loads have taken place (compendium, provider, etc. loads)
• Resource availability and experience: Focused and experienced client resources allocated and available for testing & go-live
• Interface support: Post go-live ensure there is a defined path for interface support – including working of errors (patient matching errors for instance)
• Experienced Interface Analyst/HL7 analyst
  • IA with experience with the application programming interface (API) to the EHR – what options are available, common issues encountered, customizations to accommodate client’s work flow, etc.
  • Quickly troubleshooting and mitigating any issues that arise.

For additional information regarding Galen Healthcare Solutions’ data exchange / interface services please contact justin.campbell@galenhealthcare.com or visit www.galenhealthcare.com/interface-service

Tags: HL7, Interfaces, Technical

The benefits of a results data exchange between a vendor system and the Electronic Healthcare Record (EHR) are profound, as the need for redundant and often erroneous data is greatly reduced. More importantly, by implementing a results data exchange to the EHR, providers are delivered more timely and accurate clinical data, yielding an increased level of patient care.

Benefits

• Elimination of redundant entry of patient data.
• Result reconciled to order automatically
• Immediate availability of the results to the enterprise.
• Decreased risk of patient matching errors (name misspellings, missing dates of birth, etc).
• Elimination of scanning of signed paper labs to the EHR.
• No more lost lab results.
• Run reporting on the data from labs in EHR (for example, blood sugar change over time).
• Automated result tasking as well as the ability to send copies to related providers, such as the referring provider or the patient’s primary care provider.
• Automated Tasking.
  • Verify result task.
  • Carbon Copy (Review result task).

  

• Automated synchronization of item dictionary.
• Drop a charge automatically to the PMS (assuming a charge data exchange is in place).
• Capability to automatically send insurance information to labs for lab direct client bill (assuming the insurance data exists in the EHR. This data is usually fed from a separate PMS data exchange).
• For PACs data exchanges, facilitates viewing of image result directly from EHR.
  

And perhaps the biggest benefit is that many groups are able to negotiate with their lab and radiology providers to subsidize the cost of the data exchange. Since the data exchange presents many benefits from their point-of-view, the lab and radiology providers are often happy to provide financial incentive for practices to participate in an electronic data exchange.

Return on Investment (ROI)

A three-hospital study conducted by LINK Medical and Philips Medical provides great insight into the return on investment that interfacing can provide. These hospitals analyzed and assessed the effectiveness of automating the process of Electrocardiogram (ECG) orders and test results, with the following realized outcomes:

• Reduction in direct annual labor costs ($11–25,000).
• Elimination of non-billable tests.
• Elimination of lost charges (1% to 2% of ordered tests).
• Short payback period (less than 12 months).
• On-going ROI – these savings and associated benefits continued.

Overall cost savings were in the range of $43,000 to $59,000 per annum.

Galen Healthcare Solutions: Interface Services

Tags: Custom Reports, EHR, Integration, Interfaces, Results Interface, Technical