Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

Introducing the Galen Clinical Conversion Toolkit, a solution and process designed to guide clients through converting from legacy systems and existing EHRs to the Allscripts Enterprise EHR. As Managed Service Organizations (MSOs) seek to expand their footprint through acquisitions, conversions to consolidate to a standardized system are often desirable to avoid the Healthcare Information System Mosaic.  Leveraging experience gained from previous clinical conversions, the Clinical Conversion Toolkit streamlines the process and provides a means of converting clinical data safely and efficiently. It should be noted that while conversions can be extremely useful in the sense that they save duplicate data entry, clients need to exercise caution in that any conversion data should be reviewed.

Discrete Conversion Types

Process Overview

• Data Extraction

• Data Analysis: Cross-Referencing

• Design: Data Filtering, Matching (Provider, Patient Item), and Exceptions/Errors

• Testing

• Go-Live

Data Extraction

Whether the historical system is an EHR such as NextGen, Greenway or eClinicalWorks, a PM such as GE Centricity, or a legacy in-house clinical information system, one of the most important aspect of the conversion will be acquisition of the data. Often times, this will require assistance with the current vendor to trigger a bulk-load export of the data. The preference is to output to flat-file, thus facilitating an intermediary step of data analysis and cross-referencing to prep the data before it is loaded into the EHR.

Data Analysis – Cross-Referencing:

The most important part to cross-referencing is to ensure that the corresponding AE-EHR dictionary dependency exists in the dictionary. If starting from a “blank-slate,” it is prudent to extract the compendium information for the exported data file from the source/reference system. In the case that dictionary entries already exist in the AE-EHR (for instance, in the scenario of a client that is an MSO, multi-org, and single EHRDB), it will be important to setup cross references so that the codes in the reference system match up to the corresponding values in AE-EHR. This is often realized through deployment of translation tables within the Clinical Conversion Toolkit.

• Provider code – Recommendation to use default “dummy” provider to identify clinical items loaded from conversion
• Document type
• Allergy code
• Immunization name, provider, route of admin, body site and manufacturer
• Problem and procedure codes
  • These codes will need to be cross referenced with the more-granular Medcin nomenclature.
  • This presents a challenge in that an ICD9 or CPT code could have a one-to-many relationship with Medcin.
  • The Clinical Conversion Toolkit provides a translation tool utilized in previous problem conversions to assist in the cross-reference.
• Vital sign names
• Order/Result Item Codes

Design – Filtering:

Filtering can be performed up-stream as part of the source/reference system extraction process, or it can be realized within the Clinical Conversion Toolkit logic. Typical filtering options include the following (but are not limited to):

• Items that have been entered in error in vendor system
• Allergies – NKA and NKDA entries are typically excluded to avoid incorrect reporting of NKA and NKDA
• Exclusion of non-finalized documents or results

Design – Matching:

Patient Matching: Patient matching is crucial to the exchange of clinical information between systems.  The Allscripts Enterprise EHR has strict matching criteria – in summary, matching on three of the four of the following: Name, Date of Birth, Medical Record Number (MRN) and Social Security Number (SSN).  As there is a move away from using SSN, by patients at least, this leaves us with only three fields to match on for many patients: Name, Date of Birth and MRN. In certain cases, more advanced options for patient matching can be deployed such as fuzzy matching as previously described on our blog.

Provider Matching: Clinical items will need to tie back to the provider who originally entered, ordered or authorized.  Typically, a short numeric or alphanumeric identifier is used to link a provider entry in the Other Vendor’s system to the provider entry in the EHR.  The current trend is to use a provider’s National Provider Identifier (NPI) as the identifier that the two systems exchange.

Design – Exceptions:

Not all of the data will load to the EHR without error. Some records will require manual assistance via add-on tools such as Allscripts Patient Bridge, while others may require more advanced troubleshooting and re-file. The Clinical Conversion Toolkit takes care of logging those transactions which generated error for future reference.

Contact:

Please contact sales@galenhealthcare.com if you or your organization would like to learn more about Galen’s Clinical Conversion Toolkit for the Allscripts Enterprise EHR.

Tags: Acquisition, Allscripts Conversion, Allscripts Enterprise EHR, Clinical Conversion Toolkit, Data Conversion, Enterprise EHR, Integration, Interfaces, Interoperability, MSO, Multi-Org, Technical

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 15^th and 16^th, 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.

Tags: CCD, CDA, Clinical Document Architecture, Continuity of Care Document, HL7 Educational Summit, Integration, Interfaces, Interoperability, LOINC, Meaningful Use, RELMA

Were you aware that the moment the IS staff plugs a USB connector into a medical device to send data from it to another device, the organization could become the manufacturer of a completely new medical device and subject to recently announced Medical Device Data System regulations from the FDA? Were you aware that devices that collect and store data from a blood pressure cuff for future use or that transfer thermometer readings to be displayed at a nursing station for future use are considered an MDDS product and thus governed by the FDA?  Well if you didn’t know, you are not the only one as neither did I until attending the latest New England HIMSS (NEHIMSS) Monthly Event and Social Tuesday evening at the Papa Razzi in Wellesley, MA.  Rick Hampton did a phenomenal job of running through the rules and regulations surrounding “Integration of HIT & Medical Devices.”  Rick is a Clinical Engineer who has helped write several international standards, including the latest on risk management of integrated HIT and medical networks.  He works for Partners HealthCare as their Wireless Communications Manager.

Rick outlined the trend in increasing attention being paid to HIT integration efforts over the past few years.  The latest are new FDA rules from February 15, 2011, which specified “Medical Device Data Systems are off-the-shelf or custom hardware or software products used alone or in combination that display unaltered medical device data, or transfer, store or convert medical device data for future use, in accordance with a preset specification.”  He then discussed how the new standard, IEC 80001-1, was written to help hospitals perform proactive risk management when creating these integrated systems.

Currently, Electronic Health Records (EHRs) are granted an exception from being considered a medical device, however one might anticipate the day when they are considered as such and are regulated the same as a Laboratory Information System (LIS) or Radiology Information System (RIS). For an interface analyst such as myself, the implications are that there will be liability in the exchange of unsolicited results (for instance) between the LIS and the EHR. For those Allscripts users, this also brings into question the applicability of the regulations on the Allscripts Universal Application Integrator (UAI), which provides Allscripts Enterprise EHR the ability to interface with third party applications. An example would be a Welch Alynn Vital device.

A great question was posed from a HIT project manager in the audience who inquired about where this all fits in the scheme of all of the potentially competing projects in the enterprise (HIPAA 5010 EDI, ICD10 and MU come to mind), and also, where does it come into play in terms of the project to get the necessary departments together to discuss compliance? Often times the clinicians, end-users or decision-makers have already procured the software/solution/system and simply hand-off to IT to implement, and unfortunately it is too late by that point to perform the necessary risk assessment and ensure compliance.

Additionally, Rick provided a great link for organization’s to participate in the AAMI/ACCE/HIMSS Risk Analysis Survey to ensure compliance. This survey is intended to obtain baseline information from healthcare delivery organizations about the application of risk management during the healthcare technology life-cycle (eg. acquisition, deployment, use, modification and retirement).

On a side note, this was my first NEHIMSS meeting which I attended as a member. The group has historically been very gracious in allowing non-members to attend free of charge, but to me it made sense to invest $30 for a chapter membership (essentially a drop in the bucket). Not only do I get great exposure to topics and presentations I normally wouldn’t have access to, but I also get the opportunity to network and form contacts with fellow members of the HIT industry.  To me, that is a $30 well spent (by Galen of course .

Lastly, for those project managers out there, be sure to register for the 5^th Annual New England HIMSS/PMI-NH Project Management Symposium, hosted at the Sheraton Portsmouth Harborside Hotel in Portsmouth, NH. There are some great speakers presenting who will surely offer valuable insight into their experiences with initiatives that directly impact the healthcare organization today (Patient Portal, PM’s role in an EMR implementation, Project Managing a 5010 and ICD-10 upgrade, and HIE implementation to name a few). CPHIMS Credits will be offered for this event as well!

Tags: Allscripts UAI, EHR, FDA, IEC 80001, Integration, Interfaces, Interoperability, LIS, MDDS, Meaningful Use, Medical Device, NEHIMSS, New England HIMSS, Partners, RIS, Universal Application Integrator

As more providers go live with Allscripts, we often hear the request for better integration between the EHR and external devices. With all the biometric equipment in a modern practice, the goal should be to pull as much data directly into the EHR as possible. One of Allscripts’ largest clients in the Northeast is leading the way by pulling data directly from Welch Allyn vitals devices and Midmark EKG devices across Citrix.  There are also plans to integrate Holter monitors soon as well. This shows that it can be done, but there are some things to consider when going this route.

Device integration obviously takes some effort to set up and support. When you bring in third-party devices to the EHR, you need to take responsibility for that connection. Resources and time will be needed to manage and troubleshoot their communication.  It is critical that you have strong Allscripts technical resources available during this integration. Similarly, a strong partnership with the device vendor is important. Fortunately, device communication is getting increased attention from both Allscripts and many of the biomed device vendors. Make sure you are working with someone who understands the requirements.

Overall in our experience, the benefits usually outweigh the cost of support efforts, especially if the device is used frequently in a practice. Think about a clinic that takes vitals for each patient. The time that a nurse or medical assistant would otherwise spend manually entering each vitals panel can now be directed back towards the patient. The EHR becomes simpler to use, and its data becomes more accurate and reliable.

 For a Cardiologist who orders 15 EKG’s a day, being able to view them effortlessly from the patient’s chart is a great time-saver. One of the biggest complaints we hear from EHR users is that they spend too much time on the computer. By integrating external devices, you can give them some of that time back.

Allscripts is in the process of expanding its list of UAI certified devices, so be sure to check with an Allscripts representative for the latest list of certified manufacturers. The capabilities for device integration are improving quickly.

Tags: Allscripts Enterprise EHR, EHR Implementation, Enterprise EHR, Integration

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

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

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

Additionally, import options exist including the following subset:

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

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

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

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

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.

Tags: Data Conversion, IDN, Integration, Interfaces, Interoperability, Meaningful Use, MSO, Multi-Org, Reporting

A recent article in Health Management Technology – Poised 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 Management -  Is 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.

Tags: Allscripts Enterprise EHR, Demonstration, Enterprise EHR, Extensibility, Imagelink, Integration, Interfaces, Interoperability, Meaningful Use, Results Interface

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.

Tags: Allscripts Enterprise EHR, CCHIT, Certification Commission for Health Information Technology, ConnectR, Database, Enterprise Order, HL7, Integration, Interfaces, Interoperability, Laboratory Information System, LIS, Meaningful Use, Microbiology Results

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.

Tags: Allscripts Enterprise EHR, CPOE, Crystal Reports, Custom Reports, Integration, Interfaces, Interoperability, Meaningful Use, Order Interface, Reconciliation, Reporting, Requisition, Results Interface

As physicians migrate to the Electronic Health Record, there are many new systems and processes they have to learn and adapt to.  One of these systems is voice recognition software, such as Dragon Medical 10.  I have worked with some physicians recently who were implementing a new EHR in their office, as well as transitioning from a transcription service to Dragon voice recognition.  This introduced some new challenges which I hope to shed some light on in this article.

Dragon Medical has the ability to ‘Type as you Talk’, which allows the user to dictate blocks of text and see this appear in their note in the EHR.  This has a huge benefit to the provider by allowing them to review and finalize their documentation for the visit immediately, rather than waiting a few days to receive the note back from a transcription service.  We discovered that there are some steps that you can take to improve the performance and/or accuracy of Dragon.  Here are a few to note:

1. Spend the time training Dragon to recognize your voice.  During this process, the application will learn how you speak, and adapt to your voice patterns.  This will prove to be very beneficial in the long run.
2. Follow the recommendations for the settings for your EHR vendor.  The Dragon representative will have recommendations on how settings should be configured based on the EHR you are using.
3. When words are not typed correctly, correct them using the built in features of Dragon to Train it on how you speak those words.  This will save you time and energy as you become a more advanced user of the speech recognition software.
4. Have reasonable expectations.  Dragon is a tool that improves over time.  When you first begin using speech recognition software, it only has a basic understanding of your vocabulary and how you speak.  It will take time for the application to improve, which will occur naturally as you train it when words are not recognized correctly.

These are a few items that will hopefully help you be more successful when using speech recognition software, such as Dragon Medical.  I have also found that it is beneficial to have a follow-up training session with Dragon after the user has been using it for a few weeks/months.  At this point, the user understands some basic functionality, and is usually interested in how to do more complex functions such as Macros.

Tags: Allscripts, Allscripts Enterprise EHR, Dragon, EHR Implementation, Enterprise EHR, Integration, Successful EHR Implementation