Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

—Discrete Clinical Data Elements as the building blocks to a Connected Health Platform—

Broken down to its basis, any vision of a truly connected Health Network will be reliant on the ability to pass, and ultimately present, discrete data elements.  Although the audiences for the information will be diverse, and the front-end systems will vary, the foundation of the information is the same.  In order to unlock the value that lies in the data being captured every day, an organization must have solid planning and execution. 

Each organization we work with is unique, but overall themes are constant: Reporting for Meaningful Use, Optimizing Health Care Decisions with Analytics, and Growth through Acquisition or Partnership.     

If we consider Clinical Data as building blocks that will be used, in whole or part, to support these efforts, we need to ensure both the ease of access and integrity of that data.  Galen has leading expertise and insight on conversions, reporting, and interfaces that can help you down this path. 

So how do you take the first steps in creating solid building blocks?  We would recommend to:

Define and establish consistency in electronic documentation and workflow.  This starts by understanding the EHR build and configuration decisions that will impact both availability and integrity of the data.   This consistency will also pay dividends to the organization by making the support of the Enterprise EHR system more predictable and efficient. 

Independent of your organization’s current state, Galen has the breadth and depth of expertise to help achieve your vision.

Tags: Allscripts Consultants, Allscripts Enterprise EHR, Clinical Conversion, Data Conversion, EHR Implementation, Enterprise EHR, Healthcare IT, Interoperability

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

 In this demo, we will present Allscripts Enterprise EHR and RelayHealth Portal integration capability. This solution facilitates seamless integration between the two applications, offering single sign-on, messaging between provider and patient,and patient online indicator functionality.

Contact us today so your organization can realize the compelling benefits of Enterprise EHR RelayHealth Portal integration.

Tags: Allscripts Enterprise EHR, Allscripts Patient Portal Integration, Application Integration, EHR Patient Portal Integration, Enterprise EHR, Extensibility, Integration, Patient Online Indicator, Patient Portal Integration, RelayHealth, Single Sign-On

Often times, clients take the approach that their interfaces are functioning as designed and don’t want to risk “breaking” the interfaces by making adjustments. However,  these interfaces may not be performing at maximum efficiency and/or may not be optimized to prevent errors. This issue is magnified for larger clients with a high volume of transactions.

Galen offers interface environment assessments  which leverage Galen’s ConnectR Toolbelt – a ConnectR Add-On – to provide interface engine health, findings and recommendations. Many of the reports offered in our assessment can be automated to email at a regular interval to appropriate stakeholders, yielding a view into the health of the interface engine, which is a critical component to the EHR as it files and extracts data real-time.

Two common opportunities for improvement, which are also incidentally inter-related, include auto-addition of dictionary dependencies (For example – type, status, scheduling location for appointments, order item, result item, and where performed for results) and interface database lookup scripts. In terms of auto-addition of dictionary dependencies, these interfaces are initiated before the main interface. For instance, an interface to check for the existence of orderable/resultable item, and auto-add if it doesn’t already exist can be initiated previous to the interface that actually files the result to the database.

With the aforementioned dictionary dependency interfaces, often times, dictionary lookup scripts are employed to “check” to determine if the particular dictionary item already exists in the database. In a high-volume interface, this can result in a tremendous number of “lookups” to the clinical Works DB only to result in a blocked message for the dictionary auto-add interface call in ConnectR (because the dictionary item already exists). These database lookup scripts are very “costly” in performance terms and can take tens or hundreds of times longer than an in-memory look-up. This adversely affects the systems required to do that look-up – the database and network specifically. We have developed a Cached ConnectR Lookup solution which provides an alternative to the costly traditional database lookup scripts.

In conclusion, we highly encourage clients to take time to evaluate the performance of their interface engine. As those who own a vehicle can attest, preventative maintenance is much more desirable than waiting until something breaks.

Galen offers interface assessments, on-site and on-line interface mentorship services, tier 2 interface maintenance and monitoring services (staff augmentation) and general interface consultation. Please contact sales@galenhealthcare.com  if you or your organization would like to learn more about how Galen Healthcare Solutions can help you.

Tags: Allscripts Best Practices, Allscripts Interface Engine, Allscripts Interface Training, Assessment, ConnectR Assessment, ConnectR Best Practices, ConnectR Cache, ConnectR Memory, ConnectR Performance, ConnectR Training, Integration, Interface Assessment, Interface Performance, Interfaces, Interoperability

Galen’s Interface Team had a full house in Boston yesterday, hosting twelve interface analysts from ten healthcare organizations throughout the country, for Galen’s first Results Interface Conference

The training covered the topic of building and maintaining results interfaces within the Allscripts Enteprise EHR. The group covered ImageLink, order reconciliation, Requested Performing Location identifiers, auto synching, troubleshooting errors and the underlying data model.

While I have great confidence in our Interface Team and the instruction provided given their expertise, the best part of the day was the interaction that occurred between the different healthcare organizations that attended the training. Throughout the day, I saw attendees pulling each other aside during breaks. They were discussing approaches to resolving errors they saw in their own environments, best practices for building new interfaces and trading ideas on working with microbiology results in Enterprise (a perennial issue).

The group continued conversations started on the Allscripts Interface Developers Network, which I’m sure will continue today and in coming months.

We look forward to offering similar conferences and trainings, and would love to get your thoughts on what type of training sessions and conferences we should host in the future.

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

In response to a guest post on EMRandHIPAA, we take a look at the top EHR data integration challenges faced today:

Technology

Proliferation of point-to-point interfaces instead of using a hub-and-spoke type of model (like that which Surescripts utilizes with electronic prescribing). Unfortunately, most organizations which exchange data in and out of the AE-EHR utilize highly-customized point-to-point interfaces for orders, results, documents, etc. The point-to-point model is highly inefficient and does not adhere with a “plug and play” model that so many organizations desire.

We’ve seen Allscripts make an effort to move away from this by introducing capabilities to automatically send immunizations to state registries via the Allscripts Hub by  simply modifying configuration setting (with the caveat that Allscripts has worked with the state to develop the intergration).  We’ve also witnessed companies like Medicity and its Novo Grid technologywhich offers electronic communication between physician practices, hospitals, and other health care providers. Novo embeds agents (small but powerful Java programs) in hospital data centers, physician practices and other locations. The grid component is an object oriented system that can replicate an object to multiple agents and keep it in sync across locations.

 Standards

As outlined in the EMRandHIPAA post, there are no mandated standards for EHR vendors to follow, thus making it difficult to coordinate data sharing between medical devices and other systems. Allscripts does offer the Universal Application Integrator (UAI),  which facilitates extendibility to other applications and devices. However, there is a certification process that needs to be pursued. In terms of the point-to-point interfaces previously mentioned, the Allscripts proprietary (API)  Application Programming Interface(which consists of inbound and outbound stored procedures to their primary clinical DB) does not segment out the data and configuration components of clinical exchange, something touched on in detail in a previous Galen Blog post.  Lastly, most vendors have their own specifications for HL7 message definitions. For instance, Quest may send ordering provider in OBR-16 in an interfaced result ORU message while LabCorp sends this in ORC-12. Another example is communication of “Ask at Order Entry” questions – something Quest expects to receive in repeating OBX segments while LabCorp expects this across Z-segments in an interfaced order ORM message.

Adherence to HL7, proprietary approaches.

Cost

John Halamka bravely predicted that when health IT vendors and providers began adopting new standards, the cost for interoperability would plummet: “We know that we won’t get precisely plug and play—this is a journey,” Halamka told Government Health IT. “But each year, we will get more constrained. We are going from a $20,000 -$30,000 venture hopefully to $5,000-$10,000.” Unfortunately the numbers quoted are accurate – and provide a high barrier to entry for smaller groups looking to electronically exchange data. There is the flip-side to cost and that is the ROI, which could include reduction in direct annual labor costs, elimination of non-billable tests, and elimination of lost charges.

Summary

The benefits of health information exchange are well documented. As outlined in the EMRandHIPAA post, there is a need for a “consistent, secure and reliable way to capture and share patient data among all systems and healthcare providers,” especially given that benefits in improved coordination of care and reduction of medical errors.

Tags: Allscripts, Extensibility, HIE, HL7, Integration, Interfaces, Interoperability, Results Interface, Standards

This is the first (in my humble opinion) controversial article to be published on the Galen blog and was inspired by the challenge issued  by John Lynn over at EMRandHIPAA.

I personally like to call it blog sparring. Basically, you take someone else’s post and provide the opposing perspective or at least you add to the conversation that they started. I love these types of interactions with other bloggers. Plus, I love the deep dive into a specific topic that happens when you do this type of blogging. As a reader, I think it’s fun to read the various blogger’s perspective on the topic. So, on that note, I’m going to make the next week, Blog Sparring Week.

Let the parallels between the EHR and the ATM, and between patients safely visiting the hospital and flying in a plane stop here. I find it interesting that humans natural gravitate towards drawing comparisons on past experience. It’s a lot like how the federal government based the model for Regional Extensions Centers (RECs) on the model for US agriculture, which was intended to disperse new info to the family farm. Alike agriculture, the goal is to ensure that HIT is reaching the family physician and providing advice in terms of selection and implementation. Yes, it’s true that there are lessons to be learned from other industries, but as Keith Boone of at the Healthcare Standards blog recently pointed out, it must be done thoughtfully.

Recently, Brad Waugh, CEO of Navinet, brought up another Healthcare IT analogy – that of Air Travel and Interoperability – on the Navinet Blog:

The patient in the National Journal article, after being sold a flight departing months past his desired travel date, after he is required to fax in a consent form, and after he must call a separate company to handle his baggage, informs the customer service representative that in a modern system, he would be sold “a safe round-trip journey, instead a series of separate procedures. It would have back-office personnel using modern IT systems to coordinate my journey behind the scenes. The systems and personnel would talk to each other automatically. At the press of a button, once I entered a password, they would be able to look up my travel history. We’d do most of this stuff online.” He’s describing the way most industries operate today, from air travel to banking to freight transportation, all of which are able to successfully communicate between systems, companies and types of data.

While it’s true we often wish that the healthcare industry was as efficient and safe as the aviation industry, the fact of the matter is, patient safety is harder and will require more effort as Jeff Terry, Managing Principal, Clinical Operations, asserted on the GE Healthcare Quality & Safety blog.

Why is patient safety harder? You be the judge:

1. On any given day in the United States, there are about 800,000 inpatients and many more outpatients. By contrast there are about 30,000 flights per day.
2. The major US airlines fly about 25 different types of planes. By contrast, the ICD-10 lists 12,420 diseases. Each plane, like each disease, requires different protocols to manage.
3. There are 2.5M nurses compared to 200,000 pilots

And that brings us to the recently asserted Boone’s Law, first published on Keith’s aforementioned blog:

Boone’s Law

It’s very similar to Godwin’s law, but related specifically to Health IT.  In any sufficiently long discussion of Healthcare IT, the probability of a comparison being made to the financial sector approaches unity. Keith’s corollary is that that in any sufficiently long discussion of patient safety, the probability of a comparison being made to the aviation industry also approaches unity.

Key points:

1. Transaction payload – Single pieces of data are not being transmitted in the payload with healthcare. Conversely, financial transactions however are very small (include account holder identity info, merchant identity info, and a transaction amount.
2. Business model – in financial transactions, there’s a payment model already built in, who would pay for it in healthcare transactions and why?
3. Regulation, Trust and Security – The financial industry deals with audit trails, logging and security, but again, back to point #1, single pieces of data aren’t in the payload, there are instead hundreds or thousands – especially with imaging studies.

I’ll leave off the debate with an article I read while taking the train home last evening –  “Point to Ponder” written by Greg Gillespie, Editor in Chief, Health Data Management.

Aviation experts quoted in a Wall Street Journal article predict the accident will result in a shake-up of pilot training over concerns pilots have abdicated too much responsibility to computer aids and, when those aids malfunction, can’t handle emergencies because of rusty piloting skills.

Not sure anyone would argue the health care industry is in any immediate danger of being over-automated, but the question of whether automation serves the user, or vice versa, is an important one. Industry gurus typically point to aviation as a model for medical reform, and there is absolutely no question that automation has increased aviation safety. But automation shouldn’t lead us to a point where a pilot stops being a “real” pilot, or a clinician a “real” clinician.

Well put Greg. As much as computers aid our decisions, we should never completely remove or undervalue the human element.

Tags: Air Travel, ATM, EHR, Financial, Healthcare IT, HIPAA, Integration, Interoperability, Patient Safety, REC, Regional Extension Center, Security

Client: MedNetworx – Azalea Orthopedics

Project: MedManager PM -> Allscripts PM Conversion

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

Client Contact: MedNetworx – Mark Johnson, President and CEO.

Description: Azalea Orthopedics, located in Tyler Texas, has been providing orthopedic surgery, sports medicine & pain management in East Texas for the past 20 years. Azalea employs 130 including 17 physicians who are specialists in orthopedic surgery, physical medication and rehabilitation. MedNetwoRx, a healthcare application service provider (ASP), located in Dallas, Texas, hosts the practice management and electronic healthcare record applications for Azalea. Azalea looked to convert from a legacy PM system, MegManager, to Allscripts PM, as part of consolidating systems to the Allscripts product line. Partnering with Galen Healthcare Solutions, MedNetwoRx leverage their own in-house Allscripts product and physician practice experts as well as Galen’s deep experience with clinical and administrative data conversion.

To facilitate this conversion, flat-file extracts were obtained from MedManager for dictionaries, demographics and appointments. However, instead of using these extracts to import into Allscripts PM, an alternative approach was taken in which real-time appointment and demographic interfaces were deployed from the client’s existing Allscripts Enterprise EHR to the new Allscripts PM environment. This offered the flexibility of having the PM data populate real-time. Interfaces were also required from Allscripts PM to Allscripts Enterprise EHR. Thus as part of the go-live, existing reg/sched interfaces from MedManager to Allscripts Enterprise EHR needed to be deployed.

Utilizing existing data in the Allscripts Enterprise EHR as well as flat-file extracts from MedManager (for more complete insurance and referring provider information), a conversion of dictionaries, registrations and appointments was executed.  Care had to be taken to ensure that appointments loaded into Allscripts PM would be able to map to existing appointments in the EHR and update appropriately instead of creating duplicate appointments. The same consideration had to be made for dictionaries to ensure proper matching on codes.

All patients (inactive and active) and appointments for the previous 2 years as well as future appointments were loaded from the Allscripts Enterprise EHR into Allscripts PM. Since insurance information wasn’t being captured in the EHR, and update of patient’s accounts in PM had to be executed, utilizing flat-file output from MedManager. Additionally, the patient MRN seed in PM needed to be reset as to avoid contention, and insurance and referring provider dictionaries were updated using extracts from MedManager, since the extracts contained more complete data than the EHR.

Conversion Statistics:

Tags: Allscripts, Allscripts Conversion, Allscripts Enterprise EHR, Allscripts PM, Clinical Conversion, Data Conversion, Galen Clinical Conversion Toolkit, Integration, Interfaces, MedManager, MedNetwoRx, MSO, Multi-Org, PM Conversion, Practice Management Conversion

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