Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

In the past on this blog, we’ve addressed the top data integration challenges as well as the ROI of a results interface. Recently, Health Management Technology featured a related article on the economics of interfaces. The key points from the article were as follows:

• Opportunity Cost
• True Investment
• Integration is not simple
• Pitfalls of proprietary
• Features matter
• Think of the future

The last point of the article is one that is often overlooked when evaluating pursuing an interface. We have seen this a great deal recently in supporting data conversions for client’s switching EHR vendors and also for conversion of interfaces to support Hospital LIS (Laboratory Information System) and RIS (Radiology Information System) vendor changes. 

When we scope out conversions, one of the first questions we pose is if there are any existing interfaces with the EHR being sunset? If they are, we immediately inquire as to the expectations of end users having these interfaces in the new system – especially with regard to the interfacing with the practice management system. It is likely that users are going to want to be able to interface demographics and appointments from their existing PM system if that is not changing. Additionally, with regard to existing result interfaces with the current EHR, as part of the conversion, contingency plans for switching to paper results may need to be explored as a stop-gap solution until interfaced results are received in the new system.

Likewise, hospitals may decide to change their laboratory radiology system, or their radiology information system. This impacts downstream subscribers to that data – namely the clinics and providers in the ambulatory setting which send their orders to the hospital for fulfillment and currently receive results electronically. This is especially pronounced with radiology integration, where an ADT interface and an Imagelink interface may be involved in addition to the result interface. Again, a question that looms is who is responsible for paying for the costs associated with migrating vendors for a lab or rad information system and associated interfaces?

We recently had one client that put development of interfaces with the ambulatory EHR on hiatus until the hospital lab decided whether they were switching lab vendors. They felt like they didn’t want to sink costs into integrations only to have them rendered obsolete months down the road when the hospital made a vendor switch.

We’d love to hear other groups experiences with vendor migration and the associated costs of migration of interfaces. Share your stories and experiences on the Allscripts Interface Developer Forum.

Tags: Clinical Conversion, ConnectR, Data Conversion, HL7, HL7 Interface Cost, Integration, Interfaces, Results Interface

 The Allscripts Enterprise EHR is a wonderful example of the healthcare industry utilizing technology to improve the overall quality of the care provided to its patients, who are ultimately its customers.  While many arguments can be made in favor of the electronic health record, perhaps none is more prevalent than the ability to have a patient’s chart only a few clicks away.  The EHR stores an incredible amount of information about patients – from general information that helps identify, such as name and mailing address, to more personal and medically relevant information such as diagnoses and allergies. Let us examine the Allscripts Enterprise EHR, and the various resources that help it work, in the context of Protected Health Information security and privacy.

HIPAA, the Health Insurance Portability and Accountability Act of 1996, is legislation that protects health insurance coverage when workers change or lose their jobs, while also limiting restriction of benefits for preexisting conditions.  It also created several programs to control fraud and abuse within the healthcare industry.  These initiatives are contemplated by HIPAA’s Administrative Simplification Rules, two of which are summarized below:

-        The Privacy Rule

“The Privacy Rule standards address the use and disclosure of individuals’ health information—called “protected health information” by organizations subject to the Privacy Rule — called “covered entities,” as well as standards for individuals’ privacy rights to understand and control how their health information is used. Within HHS, the Office for Civil Rights (“OCR”) has responsibility for implementing and enforcing the Privacy Rule with respect to voluntary compliance activities and civil money penalties.”  (www.hhs.gov/ocr/privacy/hipaa)

-        The Security Rule

“The Security Standards for the Protection of Electronic Protected Health Information (the Security Rule) establish a national set of security standards for protecting certain health information that is held or transferred in electronic form. The Security Rule operationalizes the protections contained in the Privacy Rule by addressing the technical and non-technical safeguards that organizations called “covered entities” must put in place to secure individuals’ “electronic protected health information” (e-PHI). Within HHS, the Office for Civil Rights (OCR) has responsibility for enforcing the Privacy and Security Rules with voluntary compliance activities and civil money penalties.” (www.hhs.gov/ocr/privacy/hipaa)

Protected Health Information (PHI) is generally defined as follows:

“ Any information in the medical record or designated record set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment.”

ePHI, or electronic PHI is described the same way, except it refers to information only in the electronic form.  If you’re using Allscripts Enterprise EHR to look at a patient’s chart on a computer screen, smartphone, iPad, etc., it’s considered ePHI, but if you utilize the application’s print function and then are physically holding a piece of paper in your hand, it’s PHI.  PHI encompasses ePHI and the differentiation only serves to indicate whether or not the information was in electronic form.

HIPAA specifically lists 18 types of information that qualify as PHI.  That list can be found here.

Where do we find PHI within an Allscripts Enterprise EHR implementation?

There are three major ways to encounter PHI within Allscripts:

-        Allscripts Enterprise EHR – the application itself.

-        Works database – the back end database that houses most information filed into and out of the EHR.

-        ConnectR interface engine – this software processes messages, primarily in the HL7 format, to get information in and out of the EHR.

In the screenshot below we see the Clinical Desktop for patient Kelly Test within the EHR. In this single screenshot we see pertinent information in the patient banner that is used to uniquely identify Kelly Test – her first and last name, date of birth, and phone number.  We also see a current health problem of Emphysema, laboratory orders and results, and the fact that she is allergic to Morphine/Morphine Derivatives. All of this is Protected Health Information.

In the next example we’ll look at the Works database, the SQL Server database that houses most of the data found in the EHR.

The SQL in the example queries several tables within the database, including the Person table and the Problem table.  Several other tables and specific columns are integrated into the query; the result of which produces a listing of all of the patients that have electronic health records within this (test) hospital or clinic, along with the corresponding problems and specific ICD-9 codes for those patients.  This query illustrates the nature of the information inside the Works database and emphasizes the PHI it contains as well.

Lastly, let’s examine an HL7 message being used to communicate a laboratory result for Kelly Test.

Most HL7 messages will contain a PID (Patient Identification) segment.  This message segment alone is full of protected health information, as it is designed to communicate a patient’s full name, date of birth, address, phone number, and MRN, among other types of information.  From this single message we learn that there is a patient named Kelly Test, born on January 1, 1981, currently living at 101 Tremont St. in Boston, MA.  Also contained in this example HL7 message is a DG1 segment, which contains information pertinent to Kelly’s diagnosis.  In this specific example we find the value ‘1540’ in DG1-3.  The value ‘1540’ is an ICD-9 code, so this HL7 message tells us that Kelly Test has been diagnosed with a type of cancerous tumor.

The Allscripts EHR and the components of its implementation, such as the Works database and interface engine, store, utilize, and make available an incredible amount of information. Much of this data is Protected Health Information (PHI) and should be secured and protected in accordance with HIPAA and other legislation such as the HITECH Act.  We want you to be aware of the most common ways to access PHI while using Allscripts Enterprise EHR, and encourage you to contact us with any questions or concerns.

Tags: Allscripts Enterprise EHR, ConnectR, HIPAA, HITECH, PHI, Privacy, Protected Health Information, Security, Works DB

Have you ever found yourself asking how the heck does Imagelink work?  How is it possible to click a button in the Allscripts application and view an X-ray?  Have you ever wanted to know how a result closes an order is closed without a Touchworks Order number?  Have you ever heard someone say, did you check the requested performing location dictionary, and not know what they’re saying?  Have you ever wanted to know more about Allscripts result interfaces?

Well you are in luck! The Galen technical services team is proud to host a Free Results Interface Training hosted at it’s brand new office!

Who: Allscripts Interface Analysts

What: Free Result Interface Training

Where:  70 Federal Street, 7th Floor, Boston, MA 02110.

When:  Wednesday, December 14th, 2011 from 9AM-5PM with lunch provided.  There will also be a cocktails and networking hour from 4PM-5PM with beer, wine and light snacks.

Why: Learn about more of the intimate details, nuances, and best-practices surrounding Allscripts result interfaces

Agenda:

• Imagelink
• Reconciliation w/ and w/o eletronic order interface
• Common errors
• Requisitions
• Requested Performing Location
• Auto synching
• Much More!

Please contact us if there is a topic you would like to learn more about that isn’t in the list above.

Travel:  If you are driving into the city, there are parking garages nearby. The cheapest and most convenient is the Winthrop Square Parking Garage at $20/day.  If you are coming in from out of town, there are many hotels in the area.  Also note that we will have wireless internet and workstations with a hardwired internet connection available for those who need it.

Space is limited – Register Today! If you can’t make the training, it’s ok!  Galen offers free webcasts about every two weeks.

Tags: Allscripts, Allscripts Enterprise EHR, Allscripts Interface, ConnectR, ConnectR Training, Galen Webcast Series, Integration, Interface Training, Interoperability, Results Interface

This webcast gives an overview of the reporting capabilities of ConnectR. In addition, it touches on ConnectR’s administrative capabilities such as merging message definitions and exporting translation tables and interface mappings for documentation purposes. The webcast concludes with the ConnectR Toolbelt, which is an imbedded, add-on reporting tool developed by Galen.

For more webcasts visit: http://www.galenhealthcare.com/calendar

Tags: Allscripts Enterprise EHR, ConnectR, Reporting

Client: Lexington County Health Services District (LCHSD)

Project: Columbia Medical Group Greenway Primesuite EMR-> Allscripts Enterprise EHR Conversion

Project Timeframe: April 13^th – June 1^st (6 weeks from initial scoping to go-live)

Client Contact:  Donna Lyles Basden, Director of Physician Support Services, David Gavin, The Columbia Medical Group Practice Administrator

“A key success factor in the assimilation of The Columbia Medical Group into our organization was the conversion of data from their Greenway Primesuite EMR to the District’s Allscripts Enterprise EHR.  The Galen conversion team was able to successfully extract and convert the data, such that our patient demographic and discrete clinical data was available seamlessly within Allscripts EHR on day one . The technical expertise and support from Galen was impressive.” – Donna Lyles Basden, Director of Physician Support Services, Lexington County Health Services District

Background:

Lexington County Health Services District, Inc. (LCHSD), located in Lexington County, South Carolina, is a health care district comprised of more than 40 physician practices which span across multiple specialties (Primary Care, Internal Medicine, Ob-Gyn, Orthopedics, General and Bariatric Surgery, Pediatrics, Rheumatology, Endocrinology, Oncology); Community Medical Centers; Occupational Health and anchored by Lexington Medical Center, a 414 bed acute care facility. Lexington sought to incorporate Columbia Medical Group – an 8 provider multi-specialty practice with 7 Internal Medicine and 1 Neurology provider – into their organization and also have the group convert from Greenway PrimeSuite EMR to Allscripts Enterprise EHR.

The scope of the data conversion spanned approximately 6 months of clinical data from the Greenway PrimeSuite EMR.  The nature of the data included 1^st and 2^nd generation data from Greenway EMR; including data entered directly into Greenway as well as previously converted demographic data from the previous EMR in place at Columbia Medical Group (GE Centricity).

Challenges inherent in some of this information were embedded in the fact that on the fly “free text” entries were previously allowed for Greenway elements such as Problems, Allergens and Allergen reactions.  This presented situations where consolidated translations and additional application build were required in order to account for the different variations and combinations of the data.

Data Extraction:

The data extraction process was performed using SQL based extracts including a common delimiter and standardized field definitions for each data element.  Flat (text) files were generated for each data element from the source system, FTP’d to the interface engine server and ultimately placed in a directory for ConnectR to process.

Data Element Extract Breakdown:

Allergies – manual translations (T-tables generated) for both Med and Non Med Allergens.  Allergens incorrectly categorized or that were not able to map and build on the EHR side were also dealt with as Unverified allergens.  Reactions and comments were formatted, concatenated, and stored in EHR as Allergen annotations.

Immunizations – due to the manageable size of the source system peripheral dictionaries manual translations were performed and maintained in the extract for Vaccine Medication, Route, Site,  and Manufacturer.  Comments and various care providers were also dealt with as Immunization annotations in EHR.

Results –Lab results for all ordering providers which included discrete results spanning 3 previously used performing locations (LabDaq, LabCorp, and Quest).

Vitals – included height, weight, temperature, O2 sat, pulse, respirations, and blood pressure.  Also included were orthostatic vital entries from the source system.

Problems (Unverified) – because an unverified and unrecognized item is considered just that, various discrete elements were identified and concatenated to provide useful and relevant context to unverified Problems in EHR in order to assist in making the verification process manageable and reduce chart pulls and use of the legacy EHR.  Naming convention adopted for Active, PMH, PSH, FamHx, and SocHx: Greenway Problem Name + OnsetDate (or date of procedure) + Notes/Comments

In situations where ICD9 code values were associated with the problem entry in the source system it was passed to EHR in order to assist with codification requirements and provide assistance during the ACI search and problem verification process.

Medications (Unverified) – naming convention adopted for unverified medications. Greenway Medication Name + ‘*’ if RX originated outside of the practice + medication status (Active, D/C, etc.) + RX original date + RX provider + Notes/Comments

In situations where codification requirements could not be met or supplied the first 8 characters were defaulted into the Search Text for unverified medications in the ACI search field in order to assist with the ACI search and verification process.

Clinical Conversion Toolkit

The Galen Clinical Conversion Toolkit was utilized to load the extracted conversion data into the Allscripts Enterprise EHR. The conversion statistics for the go-live can be seen below:

*Note that all of the errors above were patient matching errors and were manually reconciled using the Allscripts Patient Bridge tool.

Tags: Acquisition, Allscripts Conversion, Allscripts Enterprise EHR, Clinical Conversion, ConnectR, Data Conversion, Integration, Interfaces, Success Story

Introducing the Allscripts Interface Developers Network – a forum for Allscripts integrators by Allscripts integrators. The site is intended to facilitate knowledge-share and collaboration within the Allscripts integration community.

Too many of us live in silos and don’t have the means necessary to collaborate and exchange knowledge and IP instead of reinventing the wheel. Our hope is to enable our clients and the community to produce integrations that conform to best-practice principles and are efficient and safe in the transfer of critical patient clinical data. The scenarios for collaboration are vast, with just a few examples listed below:

• Design: When designing an interface, an integration analyst may not have the necessary documentation they need concerning the functionality of the API, a list of configuration options, or a template to work off of.
• Scripts (both interface engine and database): Additionally, there may be a need for custom scripts, and perhaps another member of the community has already developed said script.
• Error Remediation and Mitigation: Perhaps an analyst has encountered an error that they have not seen before, yet another group has and has a process for mitigation
• Performance Optimization: We recently encountered a scenario where clients were experiencing performance degradation in their live environment – namely results were taking upwards of three minutes (!!!) from when they were first received in the source system to the point where the processed and filed into the EHR. With a Cached Lookup solution, the client was able to get the processing time back down to a more reasonable value.

You’ll also notice that the forum contains quite a bit of content already. We recently conducted a “soft-launch” of the forum, reaching out to our strategic partners, and got phenomenal response. A special thank you and congrats goes out to Ray Lape, EHR Application Manager at Medisync Midwest. His contributions and collaboration have been outstanding thus far. We know there are more like Ray out there, so please register and begin participation today!

So, as integration questions arise, instead of – or in addition to – emailing to a corresponding interface vendor representative, please post on the forum. Create or branch threads where appropriate. Also note that RSS capability has been enabled on the forum to offer ease of subscription.

Lastly, feedback is certainly important and if there are ways we can improve the site, especially in regards to the forum categories, it is certainly appreciated. In fact, there is a separate forum category that addresses site feedback.

Tags: AIDN, Allscripts, Allscripts Forum, Allscripts Interface Developors Forum, Allscripts Interfaces, Collaboration, Community, ConnectR, Extensibility, Integration, Interfaces, Interoperability, Knowledge Share

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

Issue:

A recent issue came up with one of our clients in that interfaced patient appointments from their Practice Management system were not making it in a timely manner to the EHR. The client witnessed that appointment messages built up in the interface queue and there was a delay in processing the messages. The client desired a resolution that would assist in speed up of the processing of the messages such that appointments booked in PM would render in the EHR quickly without a disruption to workflow.

Investigation:

Enter the ConnectR Toolbelt “Transaction Processing Time” report:

This report extracts transaction count, minimum, average, and maximum ConnectR processing time per hour. Using the report, the following analysis was conducted.

Findings:

Based on the aforementioned analysis, it was determined that in the clients Live Reg/Sched system target, blocked messages were being logged. Having blocked messages logged can be invaluable when first designing and developing interfaces. However, as evidenced in the analysis, it can lead to performance degradation as the system requires much less processing time when messages are not logged.

Outcome:

Logging of blocked messages in the Live Reg/Sched target was disabled on 6/30/2010 and as witnessed in the analysis spreadsheet the number of transactions decreased by roughly 70% and peak transaction processing time decreased by roughly 90%.

Tags: Allscripts Enterprise EHR, Business Intelligence, ConnectR, ConnectR Toolbelt, Integration, Interfaces, Meaningful Use, SQL Server Reporting Services

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