Archive for the 'Meaningful Use' Category

To Perpetually Learn and Share

Over the past year we continued to experience tremendous change as a company, an Allscripts community and as an industry.

As a company we can point to our proficiency with the Allscripts PM and Professional products. Prior to 2010, our Technical Services team had been involved with a handful of interfaces with Allscripts Enterprise PM, primarily the standard interfaces with the Enterprise EHR. In 2010, however, the team took its knowledge of PM interfaces from elementary to expert as demonstrated in the PM Integration article in this newsletter. The team became experts in inbound demographics conversions, customized outbound registration and scheduling interfaces, and began to explore the world of general ledger interfaces. Additionally, the company performed its first conversion of an Allscripts Professional EHR system – splitting a single environment into three as part of a four-party acquisition. Galen also had the fortune of bringing on a handful of experienced Allscripts PM Implementation Professionals in 2010.

It wouldn’t be entirely fair to categorize 2010 as the year of Allscripts PM and Professional at Galen. Our advancements in these areas simply showcase the organization’s willingness to embrace change. Our commitment to learning and, more importantly, sharing what we learn requires us to constantly move into unexplored territory as we strive to add measurable value to our clients. We share our experiences and newfound knowledge within the industry via the Galen Wiki and the Galen Blog. We also see the Allscripts community sharing its knowledge through the Regional User Groups, the AmberSight forums and at ACE each year.

The upcoming year promises to bring even more change to all of us in Healthcare IT. Many groups are aiming to achieve Stage 1 Meaningful Use in 2011. This means an upgrade to Allscripts Enterprise EHR version 11.2. It means capturing new data, like smoking status and language. It means new interfaces, including lab and immunizations. New workflows. New reporting. We all have a lot to do.

At Galen, we began our journey towards Meaningful Use in earnest in 2010 following the release of the Interim Final Rule. Our Meaningful Use Committee began meeting bi-weekly to discuss the rules, their impact and how we can quickly and effectively assist our clients to meet MU in 2011. Galen’s Upgrade Team will be performing nearly 20 upgrades to v11.2 this summer, ensuring the systems are there for our clients to achieve meaningful use in 2011. Additionally our Interface Team has been furiously working the past 12 months on interfaces that aid in achieving Meaningful Use, and will continue to do so over the next two years.

At Galen, we welcome the opportunity of another year working with some of the best health care providers in the nation. We look forward to overcoming the challenges that will come with implementing the software, workflows and procedures necessary to achieve Meaningful Use.
We will stay the course of learning and sharing – with our colleagues, with our existing clients and with the broader Allscripts community.

Mike Dow

Allscripts Enterprise PM (AEPM) Registration and Charge Import

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:

The Healthcare Information System Mosaic

Our clients environments are both sophisticated and complex, often times with different vendors in the fold for the different healthcare information systems that are utilized by the organizations. For those clients that are Managed Service Organizations (MSOs) or have different sub-entities, this is even more pronounced. Consider for a moment a scenario where an Integrated Delivery Network (IDN) consists of four physician groups under its umbrella. Some of these physician groups were added via acquisition – and as such were using existing systems such as EHRs or PMs from vendors different than those of the organization they were joining. The following mosaic illustrates such a case:

Given the graphic above, one can appreciate the complexity involved with the following core enterprise organizational functions:

  • Interoperability – Most systems do not easily interoperate with one another and thus require interfaces to be developed to facilitate communication between the systems
  • Patient Matching – uniquely identifying a patient across the enterprise in a system-agnostic fashion.
  • Reporting and Analytics – Each of the systems may have different database technologies at their core, and additionally the structure of the data is sure to be different.  This creates a challenge in reporting metrics to exhibit adherence to meaningful use criterion for instance or to
  • Trust – Which patient data should be shared across which systems?

A recent presentation at a NEHIMSS last month illustrated these points above and did a great job of communicating how Partners Healthcare is addressing the Healthcare Information System (HIS) mosaic via their COMPASS project. The COMPASS project is an aggressive initiative which implements a common administrative system and processes to streamline revenue cycle management and help manage costs through a “holistic, patient-centric, workflow-driven approach.”

The efficiency of the mosaic of systems (ala Claude Shannon for those EE nerds out there) is subpar at best. But this is the environment organizations find themselves. The alternative would be to consolidate to utilize one vendor across all systems ala the COMPASS project. However, some vendor systems are better at functions than others and the cost for conversion may be prohibitive or in some instances not feasible. For those organizations seeking out advice or recommendations for healthcare information systems, check out the folks at Software Advice as they offer great resources.

Contact us today if your organization seeks assistance with data conversion or integration of healthcare information systems.

Allscripts Enterprise EHR Imagelink Demonstration

A recent article in Health Management TechnologyPoised to touch all things -  highlighted the importance of Picture Archiving and Communication System (PACs) and offered the opinions of where PACs is headed from various leaders within the industry.

Additionally, as presented in a recent article in Health Data ManagementIs a Picture Worth a Thousand Interfaces?: “integrating imaging workflows – and images – in EHRs can be costly. But the benefits keep many trying.”

Many organizations utilizing Allscripts Enterprise EHR are unaware that image integration capability exists, and those that do figure it is too costly to implement.

In this demo, we will present Allscripts Imagelink capability. Imagelink is an Allscripts add-on that can be used to integrate outside systems with Allscripts Enterprise EHR.

More specifically, Imagelink provides organizations access to images and other documents associated with a result from a variety of different systems that have a web-based image viewer - from within the EHR.

With this solution, users of the EHR are presented with the clinical data they need to interpret, comment on, review or validate a particular result – without leaving the EHR application.

Just a few of the vendors we have experience in integrating to the Enterprise EHR via Imagelink include (but not limited to):

  • NovaRad
  • Stryker
  • SCImage
  • GE

Be sure to look out for one of our upcoming free webcasts covering Imagelink configuration within the AE-EHR and implementation of corresponding result interface dependencies.

Contact us today to see if your organization can realize the compelling benefits of Enterprise EHR Imagelink integration.

Interfaced Microbiology Results: Discrete or Non-Discrete?

One of the “Menu Set” CMS Final Rule Meaningful Use Stage 1 objective and measures specifies that “at least 40% of all clinical lab tests ordered whose results are in a positive/negative or numerical format are incorporated in certified EHR technology as structured data.” Additionally, the Certification Commission for Health Information Technology (CCHIT  - certifying body for EHRs) indicates via IO-AM 07.02 that “The system shall provide the ability to receive and store microbiology laboratory results with organisms recorded as free-text. (Not MU).” This brings to question the handling of interfacing microbiology results into the EHR.

Microbiology results are often longer, textual results including sensitivities. Additionally, microbiology results can have 3 levels of hierarchy:

  1. Orderable item(s) (Urine Culture)
  2. Culture(s)/Organism(s) (Light Growth Escherichia Coli)
  3. Susceptibility(ies) (Amplicillin)

The problem is that most EHRs are not well-suited to rendering interfaced results with three-levels of hierarchy; rather, the EHR is suited for just two levels of hierarchy:

  1. Orderable(s)
  2. Resultable(s)

When the interfaced result is sent by the vendor as a “discrete” result, the result likely will not render in the EHR properly:

To accommodate for this, most vendors have the capability of sending the interfaced result as “non-discrete,” or in other words, sending a free-text version of the result.  However in an instance where the vendor is able to send “discrete” microbiology results only, the interface analyst is charge with developing a interface customization to translate the “discrete” result to file into the EHR as a “non-discrete”:

The disadvantages of filing the result as “non-discrete” include the likely lack of ability to aggregate or report on these types of results.

For reference the original printed report from the Laboratory Information System (LIS) for the example above (recall that if an interface is not setup, this is the report that is usually provided by the LIS via fax).

Please contact sales@galenhealthcare.com if you or your organization would like assistance in interfacing discrete/non-discrete results to your EHR.

Order Reconciliation Woes

Organizations exploring Computerized Physician Order Entry (CPOE) might first pursue low-hanging fruit and implement an electronic workflow for results and keep a paper workflow for orders. Often times, electronic order entry can be cumbersome for end users and cause longer workflows.  As alluded to in a previous blog article, the benefits of implementing a solicited result interface are compelling – reducing paper and scanning, and offers the capability for automated result tasking.

In the Allscripts Enterprise EHR (AE-EHR), results can tie back to existing orders, facilitating completion of the order. This functionality is enabled and configured within the results interface deployed at a particular group and can be achieved in one of two ways:

  • Order Number: the Order Number EXT generated from Allscripts is sent back with the results. The Order Number is tied directly to a specific order – a specific CBC order in a patient’s chart.
  • Requisition Number: the Req Number EXT generated from Allscripts is sent back with the results. The Requisition Number is tied one or more orders – all orders on a single requisition. A requisition is defined by the Patient, Encounter, Performing Location and Ordering Provider.

For some organizations, a paper order work flow may be utilized, in which a paper requisition is presented to the lab instead of an electronic order. However, the Laboratory Information System (LIS) may not allow for discrete capture of the Allscripts-generated order number or requisition number. For that matter, the LIS also may not have the capability to send back this number in the result interface (typically a HL7 ORU result message).

Additionally, most organizations encounter a percentage of solicited results that do not complete the order. In the latter scenario, a lab may manually enter the order introducing the possibility for human error and can cause issue with not only reconciliation of the order, but potentially patient or provider matching.

Furthermore, if a lab has to change an order for any reason (for instance, changing the orderable item), the corresponding result will likely not reconcile the order (with the AE-EHR, the correct protocol would be to cancel the order and place a new order with the desired changes).

This situation can cause nightmares for organizations that are trying to gain semblance as to where lab vendors stand in terms of order fulfillment.  Additionally, order reconciliation reporting will likely be inaccurate.

This is especially pronounced in v11 AE-EHR, in which solicited results that are unable to reconcile to the original order create a “reported order.’ The original order is left unreconciled and a “duplicate” order renders in the patient chart:

We have resources available on our wiki to guide an organization through interfaced result-driven order reconciliation and can assist those organizations looking to gain control of order fulfillment and reconciliation. Please contact sales@galenhealthcare.com for more information.

Scan MD Chart and Allscripts Enterprise EHR Integration Demonstration

Notes from the 2010 VITL Summit in Burlington Vt

Last Wednesday I attended the VITL Summit ’10 in Burlington Vermont.  VITL is non-profit “public charity” that operates as a partnership between the public and private sectors; VITL receives funding from the federal and state governments, as well as the Vermont Health IT Fund.

As part of the HITECH Act (Health Information Technology Extension Program) VITL became a Regional Extension Center (REC) and received $6,762,080 in Round 1 funding from the ONC.  RECs provide: training and support services to assist doctors and other providers in adopting EHRs, information and guidance to help with EHR implementation and technical assistance as needed.

The Summit Key Note speaker was Dr. David Blumenthal, the national coordinator for health IT.  Vermont Governor Jim Douglas was also there to emphasize how important the topic is to the state.  Dr. Blumenthal’s speech touched on a variety of topics and as expected, stressed how important the adoption and use of EHRs is to the future of how doctors practice medicine.  An interesting personal note Dr. Blumenthal shared was about his daughter who is currently in Residency.  Her current rotation had her moving from a practice that used an EHR to a practice that did not.  Her immediate response… ‘how could someone possibly be affective without an electronic system in place?’; an opinion father and daughter obviously share.  Along those lines, he suggested that new doctors, fresh out of medical school, would know nothing other than an electronic practice.

Additional notes from Dr. Blumenthal’s remarks;

  • Dr. Blumenthal is an self-proclaimed “non-geek”, with a house in South Pomfret, VT.  He believes Vermont serves as a model for how EHR/HIE programs could be designed and thinks VT has a unique, competitive edge because of its collaborative spirit and natural desire to exchange information.
  • Some reasons he thinks EHRs develop better doctors;
    • 24/7 Information access – problems, meds, history, etc
    • “See” what’s been done – even if you weren’t around when it happened
    • Knowing/receiving result more quickly
    • Decision support
    • Interaction checking – allergies, meds
  • The big benefits of adoption – (most, if not all are oft repeated by those in our industry)
    • Reduce costs – an important point for many of the individuals participating in the conference.  Short term improvements in terms of reducing operational costs of a practice (efficiencies), longer term.. see next bullet.
    • Increase the quality of care – this was a point he expressed a number of times.  He pointed out that perhaps not in phase 1 of MU, but long term (phases 2 and 3), this was the ultimate goal.  I.e. EHRs would improve patient outcomes, remove redundancies and ultimately affect overall patient health.
  • 3 Barriers of EHR adoption (+1 more)
    1. Financial
    2. Logistical/technical – especially for smaller practices.. there is a tendency to think it’s too difficult or time consuming
    3. Sharing – Will sharing patient data be accepted?  Will it actually hurt my practice?
    4. Trained workforce – Dr. Blumenthal mentioned that many more colleges and universities are now developing disciplines in Healthcare IT (including some in Vermont!)
  • Meaningful Use will be here before you know it…
    • Practices will have 2 years, from Oct 1st , to pick an EHR and meet MU requirements for reimbursement.  DO NOT wait.  Time will pass quickly and inevitably a bottleneck will develop.

In a separate presentation, VITL’s HIE offering was discussed.  Connection to an Exchange like this one will eventually be a requirement for all those participating in the MU program.  VITL’s exchange is run by GE and like other HIE’s, employs a hub and spoke model to connect practices and make the exchange of patient data possible.  Besides the physical network making the connections and the software platform running the exchange, HIE policy will play a large part in how information is shared.  Whether individual patients choose to participate, what privacy rules are in place and how security is managed will all play a central role in an HIE.

An interesting part of the Summit was the presence of all the big vendors; GE, McKesson, Greenway, NextGen, Athena, Cerner, Medent, eClincalWorks and of course Allscripts.  The interesting part came from being able to go from both to both and see one application after the next.  Seeing and feeling the dramatic differences in how they each work, look and perform.

This year’s event was sold out and overall seemed like a big hit with everyone in attendance.  Great job VITL!

Proposing an Allscripts Clinical Application Programming Interface Re-design

Currently, exchange of clinical data in and out of the Allscripts Enterprise EHR is facilitated via stored procedures. This  application programming interface (API) approach certainly comes with its downsides. In this article, we propose a re-design of the API to segment out the data and the configuration components of clinical data exchange.

At the outset of an interface project where there has been precedent set (existing Quest or LabCorp <-> AE-EHR order/result data exchange deployments), we almost always get the following questions from the vendor:

  • Shouldn’t the interface be the same from client-to-client?
  • Why do we need to pay Galen (vendors will often times subsidize the cost of interfaces) to design a known interface deployed across hundreds of clients?
  • Why do we need to reinvent the wheel?

Now these are very valid questions. And the response is as follows: Due to the approach utilized with the Allscripts interface API, an interface designer must take care in translating data extracted from outbound stored procedures into a valid, compliant HL7 message the vendor can accept (ORM for orders) and also take care in translating an HL7 message from a vendor (ORU) into a stored procedure call which sets both data elements and configuration options. To help guide the client and vendor through design decisions, Galen provides interface-specific (document, result, immunization) questionnaires.

Back to our proposed re-design: segmentation of the data elements (patient first name, provider ID, order item code) and configuration settings (enable tasking, utilize NPI for provider matching, utilize EntryCode for item matching – setting the traditional form parameters of the inbound stored procedures). With this approach, the vendor is responsible for providing the data elements as they normally do in the HL7 message (ORU for results), and the client sets the configuration settings via a workplace within the TWAdmin context in the AE-EHR – much as they do to set application preferences:

We have covered AE-EHR inbound interfaces quite well, so let’s address proposed re-design for outbound interfaces. Instead of each client requiring a site-to-site VPN and individual interface deployment, what if Allscripts chose some of its top vendor partners (Quest, Labcorp) and offered the capability to exchange out of the box, without the need for one-off interfaces? This approach is somewhat analogous to that of Surescripts acting as the hub and router for electronic prescriptions. In the case of outbound interfaces (orders for our example), there would still be the need to segment data (patient, provider, item) from configuration settings (a setting to enable or disable sending insurance information – IN1 segment of an HL7 ORM order message).

In conclusion the Allscripts clinical data exchange API serves its purpose quite well, but it could do a better job. Much of the functionality is derived from legacy, antiquated methods. Our hunch tells us that in promoting themes of Community Exchange and Connecting, the “new” Allscripts will be addressing this in short order.

The Path to Meaningless Use

The Path to Meaningless Use:

As many of you know the ACE 2010 event just took place last week. As I was pouring through some of the handouts I couldn’t help but be drawn into the “Handy Trail Guide” which Allscripts has touted as “The Path to Meaningful Use” This is a great high level guide to reaching Stage 1 of Meaningful Use – Capture and Share Data.

The more I read through this the more I thought of how clients will be looking at this with an eye to the shortest path to receiving their stimulus check, and rightfully so – every group should be looking to take advantage of this, from the largest hospital to the smallest single-doc practice. However, I wanted to make sure we don’t lose sight of the forest from the trees here and bring this trail guide back to the true reason for the stimulus – improving patient care! Hence the genesis of this article, The Path to Meaningless Use.

There are a couple of main points I’d like to highlight before dissecting the step by step approach.

  1. Sell benefits of the EHR – I feel like this process is woefully underappreciated. In order for your rollout to be a success you absolutely need buy-in from all end-users, including physicians, nurses, data-entry folks and really any person that will touch the EHR on any level. How is this product going to improve their productivity? Make their job easier? Make their work experience more enjoyable?
  2. Change is a good thing – Change is the process by which innovation and improvement are instilled. I know that people are comfortable with the status-quo and yes, change for change sake is useless, but there’s a reason for change here, I promise! Challenge your co-workers to look at everything objectively and really question if the products and processes currently in place really make sense or if there could be a better way.
  3. Make concessions, don’t over-customize – The product is designed to work best when used in an out of the box capacity, sans customizations. The reality is that you probably aren’t going to be able to sell the idea of changing every workflow to fit the product, but that doesn’t mean you shouldn’t try. Ultimately in the long term the stability of the system is most closely tied to how close you stay to it’s intended use, therefore fight for those process changes to model the system, there’s a reason the EHR was designed the way it was! This point goes back to selling the benefits, be able to show how using the new workflows will actually improve the end-user experience!

With those main points made here are a few comments on the step in the Path to Meaningless Use, enjoy!

  1. Understand Stimulus – Don’t just aim for the stage 1 level of capturing and sharing data, yes this can improve productivity but don’t lose sight of the true end goal, improving patient care.
  2. Assess Gaps – Be honest with yourself. Are the tools you are using as efficient as they could be? Don’t keep old processes and tools in use just because people are “comfortable” with them, if there is a better tool out there, use it! Sometimes taking people out of their comfort zone is exactly what is needed to promote healthy growth.
  3. Design New Workflows – Don’t be unwilling to change workflows simply because that’s the way it’s always been done. Be prepared to pitch workflow re-design to physicians with benefits for them in mind.
  4. Upgrade EHR & Stimulus Set – Don’t rush this upgrade. There are many factors that go into an upgrade (depending on how many versions you are jumping) and simply upgrading for the sake of getting the stimulus approved version may end up biting you if you haven’t correctly re-worked process flows to use the EHR in a meaningful way.
  5. Rollout – During training stress benefits to end users, a 3 day crash course on the new EHR system is great but if you can’t prove to your end users why the new product and workflows make sense you aren’t going to receive full buy in and consequently won’t get the most out of the product.
  6. Begin 90-day Meaningful Use – Metrics should be kept on an ongoing basis, not just for 90 days. It’s great to hit the 90 day plateau to receive the stimulus check but the true purpose of the EHR is to improve patient treatment, and you can’t improve what you don’t measure.
  7. Report & Claim Stimulus – Nothing meaningless about this step, claim the money and move on to the next stage!

« Previous PageNext Page »