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 last quarter’s newsletter we were excited to announce our Galen Certified-Enterprise EHR Application Specialist training and certification program. Today we are proud to share the news that this quarter we added another eight employees to this distinguished group!  

During the 7 weeks of training not only are all modules of the Enterprise product discussed in great detail with an added emphasis of clinical relevance, but each student must demonstrate a complete knowledge and understanding of the Certified Workflows. Prior to taking both a written and verbal examination on Enterprise fundamentals, each student must successfully build out an entire Enterprise environment from the ground up!

Please join me in congratulating the following…Galen Certified™ Enterprise EHR Application Specialist!

Steven Beaucaire, Consultant

Steven joined Galen on September 11, 2011. He comes with us with over 14 years of healthcare experience. He has extensive experience in project management and business operations as well as in-depth knowledge on how technology and healthcare can work together to ensure patient safety and continuum of care. He has significant knowledge on how ambulatory clinics and acute facilities interact within a healthcare organization. His extensive experience as a manager in both clinical and business settings within a healthcare consortium provides an exceptional perspective on today’s healthcare demands. He looks forward to a long and prosperous career at Galen. Steven currently resides in Lewiston, Maine.

 August Borie, Consultant

August joined Galen in January 2011 as a member of the upgrade team, helping to get clients ready to demonstrate Meaningful Use. He worked as both a Project Manager and Upgrade Consultant on this team, while building his Enterprise EHR application experience. Most recently he is working with a client in Portland, Maine on an upgrade and implementation rollout. August graduated from the University of Vermont in 2010 with a Bachelor’s degree in Computer Science Information Systems.

Elise Brault, Associate Consultant

Elise joined Galen in November 2011 as an Associate Consultant and completed Galen’s Certification program in December. Elise graduated from the University of Vermont with a Bachelor’s Degree in Recreation Management. She completed master’s degree coursework in Business Administration at St Michael’s College and also recently completed the Health Information Technology Certificate Program at the Community College of Vermont. Elise brings her diverse background in business, healthcare, and management with her drive for customer service excellence to the Galen team. She looks forward to providing Galen clients with EEHR systems expertise and unsurpassed service.

 Barry Chamberland, Associate Consultant

Barry joined Galen in November 2011, having previous experience as a Software Quality Analyst testing clinical applications and workflows. He has been involved in website development for many years and looks forward to expanding his knowledge and expertise in the Allscripts Enterprise EHR™. Barry lives in Burlington VT, and graduated from the University of Vermont in 2004 with a Bachelors Degree in Recreation Management.

Jon Deitch, Associate Consultant

Jon joined Galen Healthcare in November of 2011. He graduated from the University of Vermont in 2009 with a BA in Political Science and English. He enjoys Skiing, Music, World History, and Traveling.

Evan Lea, Consultant

Evan joined Galen in May of 2011 as an Implementation Consultant. He graduated in 2009 from The University of Vermont with a degree in Marketing. Since joining Galen, he has quickly come up to speed with the front end and configuration of Enterprise EHR. He has recently been working closely with Catholic Health Initiatives in the Midwest with user support, EHR configuration, and build work as they move towards bringing over 500 clinics live in one integrated system.

Kyle Paya, Consultant

Kyle came to Galen in 2011 from UVM with a Bachelor’s Degree in business administration with a concentration in entrepreneurship. Kyle has been part of the success of a multi-million dollar company with focus on project management, inventory management, and operations planning. During his tenure at the aforementioned company; he also designed, built, and implemented the company’s first formal inventory management database mainly for the managerial accounting initiative he introduced. Kyle has been a Project Manager on six (6) v11.x to v11.2 upgrades in 2011. He also became a Galen Certified – Enterprise EHR Application Specialist during this time. As 2011 came to a close, he made a transition to consultant on the professional services team and joined the Galen group at Lexington Medical Center. There, he is helping bring sites live on Allscripts EEHR while also working with the hospital group’s upgrade team as they under-go their own v11.2 upgrade.

Chelsea Stovall, Consultant

Chelsea joined Galen in September of 2011 as an Implementation Consultant. She graduated from the University of Texas at Austin with a B.S. in Human Biology. Following graduation, she completed a Postbac program at UT Austin in Health Information Technology and received her Health Information Technology Manager and Exchange Specialist certification. She has over a year of experience in EHR training, work flow design, go-live support and EHR customization.

Tags: Allscripts Consultants, Allscripts Enterprise EHR, EHR Certification, 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

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 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

With the release of version 11.2, Allscripts Enterprise EHR^TM has the ability to define acceptable ranges for vital sign readings based on age and gender. Once this range is defined, when a vital sign is input and falls outside the defined range, users are alerted that this value is an abnormal result.  The alert is shown as a red beaker, displayed next to the value in either the Health Maintenance Plan (HMP) or as bolded, red text in the Note Authoring Workspace (NAW).

While four vital signs (Systolic Pressure, Diastolic Pressure, Heart Rate, and Respiration Rate) are pre-delivered with ranges, clients can create their own ranges for any other vital sign, such as Weight.  These ranges are defined solely using the SSMT tool using the RID – Reference Range content category.  This means that clients do not define these ranges anywhere inside the Enterprise^TM application, instead, are only able to be defined using SSMT.

Tip:  The four pre-delivered vital signs will need additional values populated as the user configures the reference ranges.

First and foremost, the organization needs to ascertain what the actual ranges will be.  The NIH Clinical Center provides their guidelines of vital sign ranges. One example of guidelines they provide is Pediatric resting values.  The organization should be aware of the resources should determine which guidelines to follow, whether it is the American Heart Association or NIH Clinical Center.

Once the decision has been made for which data will drive the decision to move forward and be used by the organization’s EHR, the System Administrator can begin to use those decisions to load the data to the system.

Now let us explore the basic fundamental steps to set up the Vital Sign Reference Ranges.

1. First be sure to backup any data prior to making changes in SSMT.
2. Access SSMT and extract the data from the RID – Reference Range content category
3. Copy the data to a spreadsheet that has the cells formatted to “text”
4. Edit the spreadsheet; the following are the applicable column headers:

• [A] HDRResultable Entry Code: value from the Code field in the Resultable Item dictionary
• [B] Resultable Entry Name: value from the Name field in the Resultable Item dictionary
• [C] Where Performed: can be a null value – if populated the range will apply to the resultable item specific to that preforming location
• [D] Reference Range Type: must be set to Numeric
• [E] SEX: leave blank if using for both genders, otherwise M for male and F for female
• [F] Lowest value: lowest allowable value for the vital sign to be considered normal
• [G] PanicLowValue: needs to be a unique value and at least one more than [F] and less than [H]
• [H] LowNormal: needs to be a unique value and at least one more than [G] and less than [I]
• [I] HighNormal: needs to be a unique value and at least one more than [H] and less than [J]
• [J] Panic High Value: needs to be a unique value and at least one more than [I] and less than [K]
• [K] Highest Measureable: highest allowable value for the vital sign to be considered normal
• [L] Reference Text: This can be set to indicate the text to be displayed in the Results Entry dialog screen indicating the range. So if the range from [F] to [K] is 40-90, indicate such in this field.
• [M] Answer: This field is left null.
• [N] Abnormal Flag: Does not need to be set to any value
• [O] Is Inactive (Y/N): Set to Y if setting an item to be inactivated, otherwise set to N
• [P] Create (Y/N):  Must be set to Y if creating a new entry, otherwise set to N
• [Q] Age Min: beginning point for the age range; the lower number
• [R] Age Max: ending point for the age range; the higher number
• [S] Age Units: units of the age range; ex: Days, Months, Years

1. Save the spreadsheet
2. Be sure to clear the text box field in SSMT
3. Copy all applicable rows of data from the spreadsheet and paste into the SSMT box (do not copy the header row)
4. Load the data
1. Return to the Enterprise EHR^TM application and validate using a test patient the applicable vital(s)

While these are basic instructions to successfully set the reference ranges, the steps should provide success in loading the reference ranges.  There are a few main points to reiterate in this process:

• Please back up any data prior to using SSMT.
• Pay close attention to the bullet steps for the column headers indicated above. Certain columns require certain information.
• Ensure the Resultable Item information is reflected in the spreadsheet as it is in the RID
• Keep in mind that columns [F] through [K] must be populated with unique values, that are not 0. [F] must be the lowest acceptable normal value, while [K] must be the highest. The numbers in between CANNOT be the same value!
• Set [P] to a value of Y when creating new values
• Try loading one line to begin – to ensure set up is correct.

 It is important to note that this enhancement has no direct effect on Meaningful Use Core Measure 8 – Record Vital Signs. The Record Vital Signs Objective states: “Record and chart changes in the following vital signs: (A) Height (B) Weight (C) Blood pressure (D) Calculate and display body mass index (BMI) (E) Plot and display growth charts for children 2-20 years, including BMI”. The measure being “for more than 50 percent of all unique patients age 2 and over seen by the Eligible Professional, height, weight, and blood pressure are recorded as structured data”. In reviewing the measure documentation, there was no mention of measuring whether or not the vitals being recorded are being flagged as abnormal.

Allscripts Enterprise EHR^TM version 11.2 offers a plethora of excellent features and this functionality certainly allows users to optimize the system and how charts are viewed. The return from defining these ranges is to provide the visual indicator that certain recorded vitals are abnormal for the patient in context.  So, while there may no added benefit from a Meaningful Use standpoint, there is certainly clinical benefit to utilizing this functionality.

Tags: Allscripts, Allscripts Enterprise EHR, EHR Implementation, Enterprise EHR, v11

This week, the world lost one of the most innovative people of our time. Steve Jobs, co-founder of Apple Computer, passed away leaving behind quite the legacy. I feel obligated to honor Steve Jobs this week and reflect on how he affected technology in health care.

It is amazing to reflect upon the history of Apple computers. It seems not too long ago, I was learning how to use a Macintosh computer playing Number Crunchers and Oregon Trail in Elementary school. Back then, the idea of a computer with a mouse was relatively new technology! Twenty years later, Jobs’ vision has evolved technology well beyond that grey box, keyboard, and mouse.

Take this timeline for example:

• May 1984 – Macintosh was released using a graphical user interface controlled by a mouse (courtesy of Xerox technology)
• April 2010 – Apple releases the first iPhone, optimizing a user interface that would pave the way to the iPad and an extensive library of applications that remains the most popular OS to developers today.

What an advancement in technology in twenty six years! So while the only Apple product I own is an iPod, I remain deeply amazed at the technology Apple offers and how much its technology touches our lives. Apple products remains as probably the most popular choice for mobile computing in the United States.

Business Insider published an article in July 2010 titled “10 Ways The iPad is Changing Healthcare”.  While it’s a quick click through the list, you certainly get a feel for the opportunities the iPad has presented to healthcare. Examples included “Going Green”, cost savings, and information consolidation. All this was made possible with the vision of Steve Jobs.

Did you know?:

According to Wikipedia on Steve Jobs:  “Jobs is listed as either primary inventor or co-inventor in 338 US patents or patent applications related to a range of technologies from actual computer and portable devices to user interfaces (including touch-based), speakers, keyboards, power adapters, staircases, clasps, sleeves, lanyards and packages.”

Being in the Electronic Healthcare Record industry, I want to share a couple examples that resulted from Jobs’ technology.

Thank you to the iOS software and the work by developers at Allscripts^TM, there are two applications that Allscripts^TM offers that can be utilized using an iPad or iPhone.

ePrescribe:

This application allows providers to use their iPhone/iTouch to view patients from their Practice Management System.

Features:

• Summary page that identifies and presented problems, allergies, unprocessed medications, and any active medications
• Allows providers to write prescriptions using an excellent, user-friendly design
• Displays formulary indicators and DUR
• Can submit Rx’s direct to Pharmacy, Send to Mail order, and send to a printer

For more information on Allscripts^TM ePrescribe, visit their webpage to learn more.

Remote EHR:

This is another excellent application that is utilized by healthcare facilities using the iOS software that allows providers to remotely control their AllscriptsTM Electronic Health record from any location.

Features:

• Provides real-time access to patient summary information
• Includes ePrescribing to the patient’s pharmacy
• Integration with Charge capturing and attaching diagnosis codes to scripts
• Compatible with Allscripts^TM Enterprise EHR v11 (among other Allscripts products!)

For more information on Allscripts^TM, visit their webpage to learn more. Additionally, Galen Healthcare Solutions offers a Wiki page with more information regarding Remote EHR.

So, thank you Steve Jobs for making such applications possible. Remote EHR and ePrescribe are two examples of the results of Jobs’ achievements and have allowed for better patient care.

Share your thoughts! Give us your feedback on how you’ve used this technology in healthcare and how you see its benefits or contributions.

As always, do not hesitate to contact Galen Healthcare Solutions for more information.  Galen is a Preferred Platinum Partner of Allscripts^TM .

Tags: Allscripts, Allscripts Enterprise EHR, EHR, Enterprise EHR, ePrescribe, Healthcare IT, iOS, Remote EHR, Steve Jobs, v11

The system is upgraded to Allscripts Enterprise EHR^TM (AE-EHR) version 11.2.x- now what to do? Evaluation of current workflows and deciding on the Meaningful Use measures the organization will be using are the next steps. This article will cover some basic key concepts of Meaningful Use as it related to the application and processes as well as examples to provide the foundation to move forward and build. Ideally, obtaining a baseline of the workflows currently used today in each site/clinic prior to the upgrade itself is the recommended approach. This article will highlight at the end the recommended timeline and priority items to provide the best success of not only the upgrade but more importantly capturing meaningful use.

Step 1- Evaluate current state workflows of each site and the role of the end user population

Even if the site recently went Live or had training- end users continuously find new ways to use the application. AE-EHR version 11 in general provides multiple ways to enter information and despite the best training and/or trainer, an end user may change their behavior over time.  Not only will a potential different workflow result in inaccurate testing of what is believed in the workflow; it may potentially allow for an area of missed training when moving to version 11.2. Here’s a great example, suppose clinical staff were not trained to enter problems, however over time the providers and office managers of a site have asked clinical staff to enter the problems for physicians. This would have an impact on training for meaningful use. Or, perhaps the staff is trained to enter smoking status on the social history but behavior has recently changed by the end users and they started capturing it in the comments field in vitals because the end user thought it would be quicker.

The best approach is to go to each site and evaluate each role on what they currently do in the application, as well as how they document in the application. This will allow the testing team to accurately test the role based workflows as well as train as appropriate on workflows. Once the current workflow is established then the foundation for configuration and re-training can begin.

Step 2- Decide which of the Meaningful Use Measures will be used by the organization.

The 15 Core measures will be required by all eligible providers, however only 5 of the 10 menu sets are required.   Additionally, of the 44 Clinical Quality Measures, three of the Core or Alternate Core will need to be used and three of the remaining Clinical Measures will need to be decided upon in order to have a total of six Clinical Quality Measures.

This step can be quite a task depending on your organization. Here are some sample questions to ask:

• Who will be the lead decision maker?
• What teams need to be informed of the Meaningful Use objectives- Business Admin, Executive, Physician Core team?
• Are there multiple teams that will make decisions on different aspects (clinical versus business versus administrative)?
• Do those key decision makers know about Meaningful Use and if so at what level – high-level or detailed?
• Will basic ARRA- Meaningful Use training be required?
• How will government incentives be paid out (to the organization, to the physician, to the site)? This will be asked at meetings and better to be prepared when instituting workflow change.
• What providers are eligible in the organization?
• Will the eligible providers report for Medicare or Medicaid?
• Who is responsible to enroll each provider with CMS?
• Does an analysis of potential eligible providers need to be assessed to make the decision of MU reporting?
• Does an analysis need to be done, and what patient population and/or diagnoses are seen by eligible providers to select the appropriate Clinical Quality Measures?
• Will eligible providers have a choice on whether to participate in MU reporting or will it be decided by the organization?
• Will each site, specialty, or provider select the measures (MENU and Clinical Quality Measures selections) or will it be directed from the organization?
• Will there be a team dedicated for Meaningful Use?
• Who will track the user’s behavior to ensure the necessary information is obtained?

These basic questions will allow the core Upgrade/Meaningful Use team to be prepared for configuration, workflow re-design, testing, and end user training. Each item can have a direct affect on one of the aspects of the upgrade/MU project. For example, if all eligible providers will be allowed to decide which measures they will select for reporting then the configuration team will need to configure to all CORE, MENU, and all 44 Clinical Quality Measures. In addition, if each provider selects their own measures ideally the training would be tailored around the measures for that eligible provider. Training all providers on all 44 Clinical Quality Measures or all 10 MENU items that may not pertain to that provider will not increase retention of the information and workflow change and likely decrease the MU reporting success.  Another example, from the above proposed questions is Medicaid provides a greater financial return if the measures are met however what if no one meets the necessary 30% of patients? Does it make sense as an organization to increase an eligible provider’s percentage of Medicaid patients to capture the higher value and if so who makes this decision and how does the front office staff know to direct more new patients of a certain insurance to a certain provider?

Step 3- Workflow Redesign for Meaningful Use

Once the system is configured and reviewed by the implementation consultant during the upgrade process, the workflows will need to be re-designed to meet the Meaningful Use Measures to guarantee success! A workflow is not just the use of the application but also the process in place for monitoring the Meaningful Use within the organization. At this point, the system has been configured by the organization configuration team (system analyst) based on Steps 1 and 2.  However, unless the users actually change behavior Meaningful Use will not count. Here are some examples below that will need to be considered based primarily on the CORE, MENU and Clinical Quality Measures.

• CORE EXAMPLE:  Suppose that currently the organization doesn’t allow clinical staff to enter and/or update problems or medications on patients, however the providers have not been keeping these lists up to date. Will the organization allow the clinical staff to begin to perform these tasks? Does configuration need to change to allow for retrospective/prospective authorization? Does enable verification of problems need to be added? Do clinical staff need to be trained how to do this item?

Remember there are many new alerts for Meaningful Use however everything doesn’t have an alert and likewise an end user can ignore an alert.

• MENU EXAMPLE:  Providing a Summary of Care Record to the patient and Patient Education. First, who will be responsible for providing the Summary of Care Record- clinical staff or providers? Will the Clinical Summary provided by Allscripts be used or will it print out from the v10 or v11 note? If the patient is a portal patient and you don’t want to provide a Clinical Summary or a non-portal patient how will the provider state if no Clinical Summary is to be provided? What/Who/How is the workflow to be defined, tested, and trained? Regarding Patient Education, will there be a standard developed if not already implemented such as every new medication prescribed by the provider the patient will receive the Drug Ed for that medication? How will the patient instructions be populated and printed?
• Clinical Quality Measure EXAMPLE:  Adult Weight Screening and Follow Up- many sites may already obtain the patient weight today and this may appear as an easy Clinical Quality Measure to capture. However, there are a couple of items to consider, by adding a free text box for comments to document if a patient denied obtaining their weight and if used would count for Meaningful Use. Is this configured already and/or do end users know to enter this information to count for Meaningful Use? In addition, to meet this measure the BMI of the patient needs to be evaluated and based on the patient’s age and BMI an additional workflow must be completed. Part of that measure states if the BMI is greater than 25kg/m2 a follow up plan must be in place. What will that plan be if not already used by an organization/site/provider? Will there be a dietary consultation or a BMI Management Follow Up Order? Will the end user be able to select from any of the potential recordable actions: Dietary consult with the appropriate SNOMED or the BMI Management Follow Up order with the appropriate CPT code? Will the clinical staff perform this action at the time the vital is taken or will the provider be responsible for adding this item on the patient.

These are some examples of Meaningful Use and all the decisions, configurations, and workflow changes that could be affected. This article is not all inclusive, rather, it is intended to begin the process for the team to meet the Meaningful Use objectives.  Please feel free to contact Cary Bresloff, Cary.Bresloff@GalenHealthcare.com, for further questions, guidance, or consultation on Meaningful Use and the impact to an organization.

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