Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

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

As seen in the trend from past newsletters, Galen continues to grow not only as a company, but as a presence in the Healthcare IT industry.  Galen’s success continues this quarter with the help of those from within; those that help propel us forward. While we could recognize the talents and valuable contributions of the entire staff, we are pleased to recognize two individuals in their promotions.

 Troy Forcier, Team Lead – Upgrade Technicians

 In the time since our last Spotlight article, Troy was promoted to Team Lead of the Upgrade Technicians. In this role, Troy serves as the front man for his team’s education, client relations, and resource planning. Troy continues to perform assessments and training on effectively maintaining Allscripts server environments, also drives the webinar schedule for the Technical Team’s topics. Since his arrival in 2008, Troy has continuously found ways to work efficiently within his group and will continue to help shape the direction his team as the IT group evolves moving forward.

Join us as we congratulate him stepping into this new role as Team Lead!

 John Buckley, Senior Consultant

 This month, John not only celebrated his fourth year with Galen, but he also was promoted to Senior Consultant. He has been a powerful asset working with clients such as North Shore – Long Island Jewish and Mercy of Maine. Early in his career with Galen, John worked as a technical resource with the upgrade team and continued to grow his working knowledge of the various components of the Enterprise EHR^TM program. In addition to his assignments, he contributes to the Galen Newsletter, Blog, and assists with other internal technical projects. John is very motivated and serves as an excellent role model to others in Galen.

Congratulations John with your promotion to Senior Consultant!

Tags: Allscripts Consultants, Healthcare IT

We’re excited about this one.

For years, doctors have been using tools like the Framingham Risk Calculator to estimate risk for a number of different disease states – like cardiovascular disease, diabetes and breast cancer. These calculators use information commonly found in the patient’s chart like vital signs, lab values and age. The risk scores are increasingly being typed back into the chart.

eCalcs are . . .

Integrated into the EHR – with one click of a button you are brought to a host of the most common health calculators, including the Framingham Risk Calculators.

Patient Specific – pulling in the relevant data from the current patient’s chart.

Documented back into the EHR – the risk scores can be added back into the patient’s chart with a single click.

For a full product overview, and a link to the eCalcs brochure, visit the eCalcs page on our wiki.

Contact information

Cary Bresloff, VP – Sales and Marketing, 312-878-2349 or Cary.Bresloff@galenhealthcare.com

Drew Bradle, Account Manger, 312-239-6648 or Drew.Bradle@galenhealthcare.com

Are we in an EHR bubble? Evan Steele, CEO of SRSsoft, predicts that much like the dot-com era, the EHR market is in the midst of a bubble which is soon to burst. He foresees a shakeout in which consolidation of the current 472 EHR vendors takes place. Steele envisions causes of the popped bubble to be attributable to missed growth projects, government money drying up and physician dissatisfaction with existing vendors, ultimately resulting in a survival-of-the fittest among the EHR vendors.

Several industry leading bloggers have made bold predictions to this same point. John Moore from Chilmark Research offered the following:

Bloom is Off the Rose, EHR Market Plateaus
Going out on a limb, we see 2012 as the year when we start talking of the post EHR-era. Yes, there will be plenty more EHR sales in the year to come but over 2012 we will also see EHR sales growth begin to plateau and level off by end of Q4’12. You heard it here first folks, it is time to collect your EHR winnings and seek new places to invest.

iHealthbeat had its own 2012 predictions for the outpatient EHR market:

• The use of cloud computing;
• The use of mobile devices; and
• Vendor consolidation.

Over the past several months, Galen has seen quite a bit of consolidation in the industry specifically with conversions in support of acquisitions. We have converted groups to the Allscripts Enterprise EHR from a number of legacy vendors – among them AmazingCharts, eClinicalWorks, Greenway, GE Centricity, SRSSoft, SAGE, MedManager – in support of these groups absorption by larger organizations and Integrated Delivery Networks (IDNs).

We continue to see an increasing amount of conversions on the horizon, supporting the claim made by Mr. Steele regarding consolidation in the industry. Organizations are certainly in acquisition and consolidation mode – will the same hold true for vendors? Will we see more mergers and acquisitions in the outpatient EHR space in 2012? I think it is a safe bet to expect activity from those vendors that own most of the market share. The following is a recent ambulatory market share analysis as offered by American EHR:

Tags: EHR Acquisition, EHR Market Analysis, EHR Merger, EHR Predictions, EHR Vendor Consolidation, Healthcare IT, Meaningful Use

This month’s New England HIMSS event filled our usual meeting place, Papa Razzi in Wellesley, MA to near capacity.  While the events typically start off with networking and socializing, it was difficult to walk around the room because of the crowd on hand.  The draw? Mac McMillan, the National Chair of HIMSS Privacy and Security Task Force and Chuck Podesta, the CIO of Fletcher Allen Healthcare were here to talk about a real life security incident that threatened the integrity of the organization’s data, and how they responded.

First, some statistics:  Fletcher Allen Healthcare is Vermont’s academic and university medical center located in Burlington, VT (also home to offices of Galen Healthcare Solutions as well as Allscripts). There are 562 beds and in 2010 there were 50,419 outpatient admissions, and 60,356 ED visits (FletcherAllen.Org).  Podesta currently runs a staff of about 150 people that support 10,000 end users on 6,000 work stations.

In the evening of March 29^th, end users of Fletcher Allens’ system were infected with a virus.  Six users, who were physicians, clicked links in emails purported to be delivery tracking updates.  Instantly the system was infected with a variant of the virus known as ‘PinkSlipBot’, for which there was no virus definition available.

Podesta’s team reacted immediately and was able to ‘secure the perimeter’, including blocking outbound traffic, and isolating the effected networks.  Luckily, only a handful of packets had escaped the network and they were actually analyzed and found to have not contained any protected health information, or PHI.  The virus was very aggressive.  It was programed to obtain local admin rights, shut down the virus scanner that was installed (McAfee), install a rootkit which hid itself from detection, and lastly, install a keystroke logger. Podesta and his team were able to learn off of this after analysis of the temp files left behind by the virus. Before it was brought entirely under control and mitigated, the virus had infected over one thousand hosts!

“The whole org is much more focused on [security] as a result of the virus”, Podesta told the NEHIMSS audience.   At the time of the incident, the team at Fletcher Allen consisted of less than ten people.  In the 48+ non-stop hours spent protecting and cleaning up their networks, the initiative grew to include about sixty people, which spent ninety minutes on each infected host, and ultimately cost the organization “in the 6 figures”.

At the conclusion of the presentation the speakers asked the audience (by a show of hands…) if security is a regulatory issue, or a patient safety one.

While no PHI was disclosed, and no patients were harmed, the answer is simple: it’s both.

While the EHR remained functional and connected throughout the ordeal, portions Fletcher Allen’s network were down for periods of time.  Galen Healthcare Solutions offers VitalCenter, a downtime solution for the Allscripts Enterprise EHR – no matter why the EHR is unavailble.  For more information visit vitalcenter.galenhealthcare.com.

If you missed it, check out my PHI related blog from last month here.

Does your practice utilize the Finish Note task in Allscripts Enterprise EHR^TM? 

If you answered yes, then this blog is for you.

In this article, I wanted to show you two possible outcomes when working in your  v11 Note. You will notice that there are two similar workflows to add and commit clinical data in the note that will impact how a Finish Note task appears in a user’s task list.

While you will find that these two workflows are scaled down to be very basic and generic, I wanted to limit them to clearly demonstrate the difference between the two.

Workflow #1: Committing data while saving and closing the v11 note

In this workflow, we assume that the user already has the patient in context at the clinical desktop.

The basic steps of this workflow are as follows:

1. Create a new v11 note
2. Add a new clinical item
• For example: add vitals to the patient chart
3. Select “Save and Close” in the Note window
4. Select “Save and Continue” on the Encounter Summary
5. Navigate to the Task List and select the Current Patient – All task view

Here you can see that the outcome is:

- One Active Finish Note task

So in this case, using the Current Patient – All or Current Patient – Active task views, you will see that just one Finish Note task has been created in an active status.  The task indicates that the note has been created and saved.  Keep in mind, at this point, that the commit action occurred while the user selected Save and Close in the Note. In this workflow, the system only reviewed the data once.

Workflow #2: Committing data prior to saving and closing the v11 note

As we did in the first workflow, here we assume that the user already has the patient in context at the clinical desktop.

The basic steps of this workflow are as follows:

1. Create a new v11 note
2. Add a new clinical item
• For example: add vitals to the patient chart
3. Click the Commit button
4. Select “Save and Continue” on the Encounter Summary
5. Select “Save and Close” in the Note window
6. Navigate to the Task List and select the Current Patient – All task view

Here you can see that the outcome is:

- A Complete Finish Note task and an Active Sign-Note task

If you use a task view that simply shows Current Patient – Active, you would not typically see the Finish Note task in this instance, but instead the Sign-Note task.  This means the note has not been signed and might not be the task you expect to receive if you seek the Finish Note task.

While a Finish Note task has been generated and marked as Complete, there may yet be information to add to the note.  The logic behind this workflow is that the second action of “Save and Close” is the second review after having hit “Commit”, and therefore results in the outcome we see here.  In this case, the system has reviewed the data twice, and the Finish Note task in regards to this note is completed and the active Sign Note task is automatically generated.

My advice in this situation is to follow Workflow #1 when working in a v11 Note. If users are creating a note and adding clinical data, but need a provider or second user to receive a Finish Note task and add additional items to the note; use the first workflow.   This way, the Finish Note task will be assigned and visible to the correct person, and users will be trained in such a way that ensures the success of this workflow.

Please don’t hesitate to leave your feedback below or Contact Galen Healthcare Solutions should you have further questions!

Tags: Allscripts, Allscripts Enterprise EHR, EHR, Enterprise EHR, Galen Webcast Series, Tasks, TouchWorks, v11, v11 Note

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

CMS released a couple of updates last month regarding Meaningful Use and the EHR incentive program. I wanted to pass this information along to our readers.

In their December 7 update, CMS indicated that “HHS announced its intention to delay the start of Stage 2 meaningful use  for the Medicare and Medicaid EHR Incentive Programs for a period of one year for those first attesting to meaningful use in 2011”.  The reason as such, according to them, is that the current schedule for compliance to Stage 2 could be a challenge for those that attested in 2011. The decision also was in consideration for vendors and practices.

 The CMS update identified some benefits from the proposal:

• The delay could provide vendors more time to develop their certified technologies for Stage 2
• The delay could also provide providers more time to implement the new software to meet Stage 2 requirements
• Expectations remain current so that providers attesting in either 2011 or 2012 begin Stage 2 in 2014
• And while 2011 has passed, CMS believed this idea would provide added incentive for providers to attest in 2011.

While I am sure there is a group of people out there that is ambitious enough to keep pace for this process, I am certain that we all can stand to benefit from the proposed delay.  The benefits from the added amount of time for both the vendors and practices/providers seem more appealing, in my opinion.

Back on December 1, CMS also announced a new tool to help Eligible Professionals (EPs) through the phases of Meaningful Use.  This tool is an eighty-five (85) page PDF file, dubbed as a “Beginner’s Guide”. This file provides a thorough, interactive walkthrough of Meaningful Use.

Among the items of information provided are:

• EHR Incentive Program basics
• How to participate (determining eligibility and registration)
• Meaningful use and choosing measures
• Attestation
• Helpful resources on the Medicare and Medicaid EHR Incentive Programs

Lastly, they also provided a link to their Educational Materials page for the EHR Incentive Program. This link offers an extensive array of files and tools regarding the EHR Incentive Program.  This is definitely a link to bookmark, as well as the guide previously mentioned.

If you haven’t already done so, visit the CMS EHR Incentive Programs webpage and register to receive their email notifications. 

Contact Galen Healthcare Solutions for any additional questions regarding Meaningful Use and Allscripts Enterprise^TM EHR.

Tags: Allscripts, Allscripts Enterprise EHR, EHR Certification, Enterprise EHR, Meaningful Use