Archive for the 'Technical' Category

eCalcs – How to video

We have received a warm response to eCalcs, Galen’s latest bolt on for the Allscripts Enterprise EHR.

We have received a lot of compliments along the way – integrated health calculators are much needed, that Galen put out a thoughtfully crafted product, and even that we finally listened a built this type of add-on tool that makes providers happy. That last one is my favorite – it’s a tough time for providers with the rush to Meaningful Use and now to ICD-10, many feel that they are taking on more work with lower results. If we can provide a “cool tool” that makes life easier, I couldn’t be happier.

What we have also received are plenty of questions about how it works. You can cite the scores into a Note? How are the scores stored in EHR – as Results? Questions like those.

This How To video will help answer those questions. It’s just under three minutes long and covers the major functionality within eCalcs and its integration with the EHR.

Our marketing firm also sent over a concise and rather visually pleasing brochure for eCalcs. Thanks guys!

Allscripts Enterprise EHR and RelayHealth Portal Integration

 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.

Steve Jobs and his impact on Electronic Healthcare

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 AllscriptsTM, there are two applications that AllscriptsTM 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 AllscriptsTM 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 AllscriptsTM Enterprise EHR v11 (among other Allscripts products!)

For more information on AllscriptsTM, 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 AllscriptsTM .

ICD-10 Readiness: Implementation & Producing Results

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

 

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

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

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

In tribute to the Southeast United States:

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

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

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

Implementation Widget

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

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

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

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

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

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

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

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

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

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

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

ICD-10 Readiness: Background & FAQ

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

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

FAQ Fact Sheet

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

Among these Q/A’s are:

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

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

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

Allscripts Interface Developers Network

Introducing the Allscripts Interface Developers Network – a forum for Allscripts integrators by Allscripts integrators. The site is intended to facilitate knowledge-share and collaboration within the Allscripts integration community.

Too many of us live in silos and don’t have the means necessary to collaborate and exchange knowledge and IP instead of reinventing the wheel. Our hope is to enable our clients and the community to produce integrations that conform to best-practice principles and are efficient and safe in the transfer of critical patient clinical data. The scenarios for collaboration are vast, with just a few examples listed below:

  • Design: When designing an interface, an integration analyst may not have the necessary documentation they need concerning the functionality of the API, a list of configuration options, or a template to work off of.
  • Scripts (both interface engine and database): Additionally, there may be a need for custom scripts, and perhaps another member of the community has already developed said script.
  • Error Remediation and Mitigation: Perhaps an analyst has encountered an error that they have not seen before, yet another group has and has a process for mitigation
  • Performance Optimization: We recently encountered a scenario where clients were experiencing performance degradation in their live environment – namely results were taking upwards of three minutes (!!!) from when they were first received in the source system to the point where the processed and filed into the EHR. With a Cached Lookup solution, the client was able to get the processing time back down to a more reasonable value.

You’ll also notice that the forum contains quite a bit of content already. We recently conducted a “soft-launch” of the forum, reaching out to our strategic partners, and got phenomenal response. A special thank you and congrats goes out to Ray Lape, EHR Application Manager at Medisync Midwest. His contributions and collaboration have been outstanding thus far. We know there are more like Ray out there, so please register and begin participation today!

So, as integration questions arise, instead of – or in addition to – emailing to a corresponding interface vendor representative, please post on the forum. Create or branch threads where appropriate. Also note that RSS capability has been enabled on the forum to offer ease of subscription.

Lastly, feedback is certainly important and if there are ways we can improve the site, especially in regards to the forum categories, it is certainly appreciated. In fact, there is a separate forum category that addresses site feedback.

 

HL7 & Meaningful Use Hands-on Workshop: CDA R2 track

Ever wonder who designs and develops Health Level 7 (HL7)?  Well HL7 international is based out of Ann Arbor, Michigan and they hold various workshops around the country.  I recently had the chance to attend the HL7 Education Summit at the Hilton Suites Chicago Magnificent Mile over March 15th and 16th, 2011.  (All images and information were taken from HL7 Educational Summit presentations).

The Clinical Document Architecture (CDA) second release (R2) workshop was a very informational, hands-on experience.  Not only did it allow me to obtain a deeper understanding of CDA but gave me the opportunity to meet other members of the EHR/HL7 world.  In addition, the workshop gave me the opportunity to meet some of the key contributors to HL7 standard, including Calvin Beebe of Mayo Clinic, Diego Kaminker of Kern IT, and Keith Boone of GE Healthcare.  I can personally say that they are a bunch of very bright individuals and I am glad they are developing such an important standard.

CDAs don’t replace v2.x HL7 field delimited messages, and instead compliment them.

CDAs are very informational and pack a lot of information.  However, they were not developed to replace the v2.x HL7 field delimited message.  The main advantage of a CDA is that it is human readable and does not require an accompanying style sheet or specification to interpret as opposed to the v2.x HL7 field delimited messages which require a specification.  So you may be asking yourself, why do we still use v2.x HL7 messages?  Well for one, they are much less bulky than a CDA.  And provide an easy, streamlined way of entering data into EHRs.  I have provided an example of each below to show you the main differences.  As you can see, it is much easier for humans to understand CDAs and how it may be easier to enter data using v2.x HL7 field delimited messages:

CDA                                                                                   v2.x HL7 field delimited message

CDA Resources

CDA’s can be used not only as a CCD (Continuity of Care document), but to send lab results, immunizations, allergies, and much more! CDA is the basic template and the number of schema (set of rules, A.K.A. schematrons) determines the constraints.  A CCD can be used to send a plethora of information.

  • A great tool to build CDAs is MiniCDA, you may be able to find it online.  It was developed by Diego Kaminker, one of the HL7 presenters.
  • A great XML editor is Oxygen, it allows you to associate schematrons, i.e. constraints to your CDA.
  • If you would prefer to validate your CDA using an internet-based program, the CDA validation site is a good resource.
  • A great resource for general information about CDAs is CDA tools
  • Once you have created a CDA, a great place to locate various LOINCs to validate the CDA is Regenstrief LOINC Mapping Assistant (RELMA),
  • And finally, Integrating the Healthcare Enterprise (IHE), is a great healthcare integration resource.

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.

Next Page »