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 order to be able to truly consult and to make sound recommendations on how to approach certain clinical data elements it is important to know what options exist.  One of the main goals heading into a conversion project is to be able to convert as much data as possible in a verified state.  Converted items that file into EHR in an already verified state are ideal since they will appear and behave very similar (if not the same) as data that was directly entered into EHR.  Unverified items will require that a user and/or provider use the Verify and Add functionality in EHR to promote the item to a verified status.  The Verify and Add process guides the user/provider to the appropriate ACI workspace where the unverified item can be queried against the master dictionary, matched up to an appropriate entry, and then committed as a verified item into the record.

Here are some of the essential advantages/disadvantages and potential decision points that might assist in the decision making process with regards to verified vs. unverified data sets.

Impact on workflow and clinical staff – it is important to be aware of the fact that filing items such as Allergens, Problems, and/or Medications as unverified items requires not only additional training and workflow augmentation for the Verify and Add process, but also can take a considerable amount of time and almost make an established patient feel like a new one.  Consideration should be given to how the Verify and Add process could potentially fit into the intake process and what (if any) additional resources might be justified in order to Verify and Add items prior to the visit; very similar to chart abstraction.

DUR checking – when considering handling Medications and Medication Allergens as unverified items, it is crucial to understand that DUR checking will NOT take place for unverified items; only for verified items.

Integration with Note – unverified items will NOT fully integrate and auto-cite into a structured note.  This is important to know so that there is awareness that items (such as Problems and Meds) need to be verified prior to starting a note if it is desired to have those items auto-cite into the Note.  This could adversely impact the amount of time it takes the provider to retrieve information for clinical decision making and also impact on the clinical documentation for the visit.

Charge capture – Problems that are in an unverified state cannot be assessed via the Note or Clinical Desktop.  In order for a problem to be assessed in EHR and electronically charged for it must be a in a verified state and associated with a valid ICD9 code.

Display text – when an unverified item is constructed and filed it basically is a string of textual information prior to the Verify and Add process.  This is significant because once an item is verified against a native EHR dictionary entry it will take on the display name and attributes of that EHR item.  The display name sent over with the unverified item will not persist past Verify and Add so it is important to know what information will remain and which information may need to be keyed in as an additional description or annotation.

The decision to ultimately proceed with verified vs. unverified items can also be driven by external factors related to the legacy system in combination with EHR specific criteria.

Does the source system allow “free text” or “un-coded” items to be added to their clinical record? 

Are these items confidently translatable to any of the dictionary items in EHR?

Are the required data dictionary extracts something that the legacy is able and willing to provide in an accurate and timely manner?  What is the cooperation level of the legacy vendor?

Consider a situation where the legacy system allows the free text “ad hoc” entry of un-coded Allergens in their clinical record and line items such as “Tylenol/Milk/Blue Dye”.  This is a challenge since it is really 3 unique allergens combined into one item.  Since this contains both medication and non-medication related allergens it would not be appropriate to build this as its own entry in Allergen dictionary.  That being the case there is likely nothing to map an item such as this to in EHR.  This situation could then present itself as an appropriate candidate for unverified items.  That way at the point of review and intake (or during chart abstraction) this item can be reviewed, confirmed, and then split out into 3 unique EHR entries that will properly partake in DUR checking and be safer for the patient.

Tags: Allscripts Enterprise EHR, Data Conversion, Enterprise EHR

The conversion implementation consultant is a dynamic project role which includes multiple responsibilities that serve an important function towards the successful execution of a discrete clinical data conversion.  It is a versatile role that requires some level of technical and logistical insight to navigate the project effectively and efficiently.  The conversion IC is also one of (if not) the frontline project resources that drive to ensure integrity, accuracy, and patient safety are kept in high regard during the conversion process.  Not only is the conversion IC responsible for defining, managing, and executing conversion build tasks that are functional in nature, but to also guide and inform the client towards decisions that will assist in adding optimal value and ensure a smooth transition from the legacy system.  The following are some functional responsibilities of the conversion IC defined in greater detail with an emphasis on conversions from legacy systems to EHR.

Dataset Mappings 

Even though most EMRs set out to fundamentally accomplish the same goals and to some extent offer similar functionality; they are understandably different in many ways.  In general, target systems (converting to) do have to accommodate some level of additional build work in order to account for gaps or differential dictionary content that the source system (converting from) could potentially provide or want to convert.  Identifying these gaps and helping the client to build their data set translations is a major (if not the primary) function of the conversion IC.  These translations or “crosswalk” files are typically manifested in a spreadsheet or flat file and then supplied to the interface and/or integration engineers on the project to install in the inbound interface or database engine.

In general it is recommended that a clinical resource be involved in the data mapping and approval process to ensure that clinical integrity is maintained throughout the conversion process.  Data elements that generally require an interface translation or crosswalk from the source system to the target system are:

Allergens (Medication & Non-Medication)

This dataset involves obtaining extracts from both the legacy and EHR system in order to generate a mapping from the legacy system to EHR.  It helps to handle the medication and non-medication allergen translations as individual crosswalks.  Both types of EHR allergens (medication and non-medication) can be handled as unverified if a translation cannot be established.

Codification values à NDC values can help to automate this process if supplied by the legacy system.

The EHR allergen (non-medication) dictionary can be obtained by running a SSMT extract via the allergen content category.  The medication allergen EHR dictionary must be extracted from the EHR database by a technical resource and provided to the conversion IC.  Any non-medication allergens provided by the legacy system that do not map or exist in the target system (EHR) would need to be built in EHR.

Medications

This dataset involves obtaining extracts from both the legacy and EHR system in order to generate a mapping from the legacy system to EHR.  Due the size and complexity of most EMR medication data dictionaries it is important to consider the amount of time and clinical input required to procure, establish, and test a translation involving medications of a variety of statuses.  Medications can be handled as unverified items if a translation cannot be established.

Codification values à NDC values can help to automate this process if supplied by the legacy system.

The EHR medication dictionary must be extracted from the EHR database by a technical resource and provided to the conversion IC.

Problems (includes Active, Past Medical Hx, Past Surgical Hx, Past Social Hx, Past Family Hx)

This dataset involves obtaining extracts from both the legacy and EHR system in order to generate a mapping from the legacy system to EHR.  Due to the size and complexity of most EMR problem based data dictionaries it is important to consider the amount of time required to procure, establish, and test a translation involving problem entries and categories of multiple statuses; especially cases where a 1-to-many relationship between the source and target system may exist and needs to be resolved.  Problems (all categories) can be handled as unverified items if a translation cannot be established.

Codification values à ICD9, CPT, and/or SnowMed values can help to automate this process if supplied by the legacy system.

The EHR problem dictionary must be extracted from the EHR database by a technical resource and provided to the conversion IC.

Vital Signs

This dataset involves obtaining extracts from both the legacy and EHR system in order to generate a mapping from the legacy system to EHR based on the code values of each vital signs component (orderable and resultable).  EHR vital signs are technically enforced findings, but live in the EHR orderable item dictionary.

The EHR vital signs order and associated result codes can be can be manually retrieved from the orderable item dictionary since the number of items is manageable.  Obtaining these order and result code values is recommended directly from the orderable item dictionary so that the relationship between orderable item and resultable item is kept intact otherwise this can lead to errors upon filing into EHR.

Documents (Unstructured Notes)

This dataset involves obtaining a list of document type codes from both the legacy and EHR system in order to generating a mapping from the legacy system to EHR.  Converted documents are typically filed with a status of “Final – Receipt” since in most cases only finalized or verified documents are migrated from legacy systems.

The EHR document type dictionary can be extracted via the document type SSMT category and filtered to “RTF” manifestation type by the conversion IC to produce a list of potential target EHR unstructured note types.  Any document types provided by the legacy system that do not map or exist in the target system (EHR) would need to be built in EHR.

Images (Scanned Images)

This dataset involves obtaining a list of document type codes from both the legacy and EHR system in order to generate a mapping from the legacy system to EHR.  Scanned image file types and formats can vary in their manifestation types from system to system so it is important to understand if additional technical manipulation will be required up front to prepare the documents in a format that EHR will accept and properly display.

The EHR document type dictionary can be extracted via the document type SSMT category and filtered to “TIFF” manifestation type by the conversion IC to produce a list of potential target EHR scanned image types.  Any document types provided by the legacy system that do not map or exist in the target system (EHR) would need to be built in EHR.

Immunizations

This dataset involves obtaining an extract from both the legacy system and EHR in order to generate a mapping from the legacy system to EHR.  Depending on the functionality available to end users in the source system this extract is typically low to medium in terms of size and complexity.  Immunizations can be handled as unverified items if a translation cannot be established.

The EHR immunization dictionary must be extracted from the EHR database by a technical resource and provided to the conversion IC.  These are essentially medication entries that have entry codes starting with “CV”.

Results

This dataset involves obtaining an extract from both the legacy system and EHR in order to generate a mapping from the legacy system to EHR.  Depending on the number of lab vendors and current setup of the target system (i.e., synchronization) it is important to consider time and level of clinical involvement.  One of the advantages of executing the Order/Result conversion mapping is the ability for flow sheets to continue to flow historical data in a longitude format.  It also prevents from having to build additional and potentially erroneous entries in the orderable and/or resultable item dictionaries just to house converted data.  It is generally the case that both the orderable items and resultable items will need to be individually mapped in order to honor to the relationship between the parent orderable item and resultable components.

Codification values à LOINC or CPT codes can help to automate this process if available from the legacy system and if assigned to EHR orderable items in the Orderable Item Dictionary.

The EHR orderable item dictionary  and associated resultable items can be obtained by running a SSMT extract on using the Order-Results v11 content category.  The resultable item dictionary itself can be obtained by running a SSMT extract using the RID – Resultable Item Dictionary content category.

Click the following link to read Part 2 of this article:

The Role of the Conversion IC Part 2: Verified vs. Unverified Data Sets

Tags: Allscripts Enterprise EHR, Data Conversion, 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

This piece is the second of a two part series discussing the transition to ICD-10.

As I mentioned before, the healthcare industry is rapidly moving closer to the October 1, 2013 compliance date for ICD-10. As that date draws closer, organizations will need to actively take action to successfully be compliant.  The Centers for Medicare and Medicaid Services (CMS) is actively providing resources to assist in achieving this success.

Before I share another tool that CMS is offering as support to the transition, I wanted to reflect upon some rather humorous information regarding the new ICD-10 codes. Last week, I read a blog from EMR and HIPAA that made me aware of the fact that the ICD-10 code volume has expanded and now includes some “off-the-wall” codes.

One example the article shared was “V91.07XA, “burn due to water-skis on fire”. I would say that’s fairly specific!  After reading this, I was encouraged by curiosity to dig for more interesting codes. After browsing the ICD10 code listing, I did manage to find some more codes that amazed me.

In tribute to the Southeast United States:

• W5803XA Crushed by alligator, initial encounter
• W5803XD Crushed by alligator, subsequent encounter
• W5811XA Bitten by crocodile, initial encounter
• W5811XD Bitten by crocodile, subsequent encounter

I come away from those codes wondering what the actual number of times the code W5803XD will be used.

The fact that these codes have increased in volume and in specificity, to me, seems to have far more benefit than harm as we transition to using ICD-10 codes. But before we see the end result of this transition, we have to endure the transition and arrive to October 2013 with only success. One tool CMS is offering to assist is the Implementation Widget.

Implementation Widget

CMS offers a “timeline widget” that users can download to their desktop of mobile device.  Once downloaded by a user, that person can share the application through email, social media, or post in a website. The purpose of the widget is to “identify and take action on the benchmarks you will need to ensure smooth transitions to” the ICD-10 compliance date. HIMSS News summed it up perfect indicating that it would help organizations:

• Understand what should be done right now to prepare for the switches to 5010 and ICD-10
• Know the steps needed to take in the future and when
• Stay on top of approaching transition deadlines to help manage the implementation process

The widget first prompts for a selection among four choices: Vendors, Payers, Large Providers, or Small Providers.  Each category differs in the output of the timeline, benchmarks, and necessary actions suggested by CMS to act upon.  A full timeline can be downloaded in each category. The timeline, viewed as a PDF file, indicates the suggested immediate actions/goals, then broken down by quarter up to the deadline. However, users can step through the timeline using the widget, making the experience more visually appealing as it breaks down the timeline piece by piece.

The goals and action points are clean, concise bullet points set to guide the organization in the direction of a successful compliance. Here’s an example of the bullet points for Venders listed of Actions to take immediately:

• Identify staff to receive training and develop training materials (5 months)
• Establish organization’s implementation chart (6 months)
• Determine product requirements (8 months)
• Estimate budgets.  Budgets should include all costs associated with implementation including software, software licensing, hardware procurement, development, and staff training costs (8 months)
• Conduct product re-engineering analysis (6 months)
• Start product/solution development (9 months)

Each action point has a timeframe given. That timeframe is the estimated total duration needed for that action point.

The information presented in this tool should prove to be a valuable resource to organizations. I am interested to hear feedback from organizations whether they are using this tool or not, and if so, how the information is helping steer them successfully to compliance.

Another key ingredient to the October 2013 compliance date will be the incorporation of the ICD-10 codes to vendor systems. This will certainly affect systems such as the EHR and PM systems. Hopefully soon, the various vendors will begin (if they haven’t already started) to incorporate plans to swap the ICD-9 codes to ICD-10. Organizations will need to pay close attention to any vendor communications, as vendors will surely indicate release dates and material that correspond to the ICD-10 implementation.

As we move closer to the deadline, CMS will certainly provide more information on the ICD-10 transition. Visit their Latest News page to sign up for notifications, industry updates, attend teleconferences, and obtain other valuable resources.

One common and important theme from the CMS resources is training.  Proper and well established training inside each organization will prove to be a crucial step to ensure a smooth transition to using ICD-10 codes.  Training is the most powerful force behind deciding the level of success to using any new or updated information and procedures.  An organization that chooses to invest more in training will certainly have a higher return on that investment.

Galen Healthcare Solutions offers project management and training solutions. Contact us to find out how Galen might assist in the ICD-10 transition.

Tags: Centers for Medicare and Medicaid Services, Clinical Conversion, CMS, Compliance, Data Conversion, Galen Healthcare Solutions, Healthcare IT, ICD-10, Implementation, October 2013

This piece is the first of a two part series discussing the transition to ICD-10. The ICD-10 transition should be a high priority concern in healthcare.

Today, the healthcare industry is rapidly moving closer to the compliance date for ICD-10. That date is October 1, 2013.  As that date draws closer, organizations will need to actively take action to successfully be compliant.  The Centers for Medicare and Medicaid Services (CMS) is actively providing resources to assist in achieving this success.

FAQ Fact Sheet

CMS posted a downloadable PDF FAQ “transition basics” fact sheet indicating sixteen question and answers.  This tip sheet gives an excellent and informative overview to the transition to ICD-10.

Among these Q/A’s are:

• What does ICD-10 compliance mean?
• ICD-10 compliance means that all Health Insurance Portability and Accountability Act (HIPAA) covered entities are able to successfully conduct health care transactions on or after October 1, 2013 using the ICD-10 diagnosis and procedure codes. ICD-9 diagnosis and procedure codes can no longer be used for health care services provided on or after this date
• What is the transition to ICD-10 happening?
• The transition is occurring because ICD-9 codes have limited data about patients’ medical conditions and hospital inpatient procedures. ICD-9 is 30 years old, has outdated and obsolete terms, and is inconsistent with current medical practice.
• Also, the structure of ICD-9 limits the number of new codes that can be created, and many ICD-9 categories are full.
• A successful transition to ICD-10 will be vital to transforming our nation’s health care system.
• What type of training will providers and staff need for the ICD-10 transition?
• Training should take place in late 2012 or early 2013 for most staff. Training needs will vary for different organizations. For example, physician practice coders will need to learn ICD-10 diagnosis coding only, while hospital coders will need to learn both ICD-10 diagnosis and ICD-10 inpatient procedure coding.
• Look for specialty-specific ICD-10 training offered by societies and other professional organizations. Take into account that ICD-10 coding training will be integrated into the CEUs that certified coders must take to maintain their credentials.
• ICD-10 resources and training materials will be available through CMS, professional associations and societies, and software/system vendors. Visit http://www.cms.gov/ICD10 regularly throughout the course of the transition to access the latest information on training opportunities.

As we move closer to the deadline, CMS will certainly provide more information on the ICD-10 transition. Visit their Latest News page to sign up for notifications, industry updates, attend teleconferences, and obtain other valuable resources.

The second part of this series will discuss implementation and producing results.  Look for that piece next week!

Tags: Centers for Medicare and Medicaid Services, Clinical Conversion, CMS, Compliance, Data Conversion, Healthcare IT, ICD-10, ICD9, October 2013

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

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

We recently had the opportunity to assist clients in designing and deploying interfaces to automatically import charges into Allscripts Enterprise PM from not only Allscripts Enterprise EHR, but also other vendor EHRs including Mosaic and eCW. At one particular client, AEPM served as the aggregator for all charges generated in the enterprise. In addition to the inbound charge interface, an inbound demographic interface was required to ensure that the patient exists before trying to interface and import charges for them. Thus with each generated charge in vendor systems, a HL7 ADT registration message was sent immediately preceding the HL7 DFT charge message.

When importing registrations and charges into AEPM, several matching and translation considerations need to be made. In terms of inbound registration, the following list a subset of “linking” items and their respective options for match:

• Patient
  • Name/date of birth
  • SSN
  • MRN
• Policy
  • Policy Reference Number
  • Subscriber Certificate Info
• PCP
  • Default value
  • Cross Reference Link
  • Direct Map (Abbreviation)
• Carrier (Insurance)
  • CarrierID
  • Default Carrier
  • Cross-Reference Link *Note: a cross-reference link can be likened to a translation table – simply translating an input (vendor insurance code for instance) to a corresponding output (AEPM carrier abbreviation)

Additionally, import options exist including the following subset:

• Auto-Import
  • This function will allow for the automatic import of demographics which do not have any data errors or missing cross reference links. Only those patients which pass all of the validations will be auto registered.
• Allow Update of existing Demographics?
  • Answer Yes – if you wish to allow existing demographic information for patients to be changed to match the data that was imported.
• Default to update existing Demographics?
  • Answer Yes – if you will be updating information for all existing patients.
  • Answer No – if you wish to update patients one at a time or if you do not wish to import all of the patients included in the file.

Lastly, we can selectively block certain fields from importing. This will facilitate certain fields in AEPM to be maintained manually instead of receiving update when importing data. An example of this would be for indicating the Patient Student Status, or Employment Status, which may be required for billing purposes.

The following demonstration illustrates the process for importing interfaced charges and demographics into AEPM:

Tags: ADT, AEPM, AIE, Allscripts Enterprise EHR, Allscripts Enterprise PM, Charge, Data Conversion, Demographic, DFT, eCW, Enterprise EHR, Integration, Interfaces, Interoperability, Mosaiq, Practice Management