Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

In the past on this blog, we’ve addressed the top data integration challenges as well as the ROI of a results interface. Recently, Health Management Technology featured a related article on the economics of interfaces. The key points from the article were as follows:

• Opportunity Cost
• True Investment
• Integration is not simple
• Pitfalls of proprietary
• Features matter
• Think of the future

The last point of the article is one that is often overlooked when evaluating pursuing an interface. We have seen this a great deal recently in supporting data conversions for client’s switching EHR vendors and also for conversion of interfaces to support Hospital LIS (Laboratory Information System) and RIS (Radiology Information System) vendor changes. 

When we scope out conversions, one of the first questions we pose is if there are any existing interfaces with the EHR being sunset? If they are, we immediately inquire as to the expectations of end users having these interfaces in the new system – especially with regard to the interfacing with the practice management system. It is likely that users are going to want to be able to interface demographics and appointments from their existing PM system if that is not changing. Additionally, with regard to existing result interfaces with the current EHR, as part of the conversion, contingency plans for switching to paper results may need to be explored as a stop-gap solution until interfaced results are received in the new system.

Likewise, hospitals may decide to change their laboratory radiology system, or their radiology information system. This impacts downstream subscribers to that data – namely the clinics and providers in the ambulatory setting which send their orders to the hospital for fulfillment and currently receive results electronically. This is especially pronounced with radiology integration, where an ADT interface and an Imagelink interface may be involved in addition to the result interface. Again, a question that looms is who is responsible for paying for the costs associated with migrating vendors for a lab or rad information system and associated interfaces?

We recently had one client that put development of interfaces with the ambulatory EHR on hiatus until the hospital lab decided whether they were switching lab vendors. They felt like they didn’t want to sink costs into integrations only to have them rendered obsolete months down the road when the hospital made a vendor switch.

We’d love to hear other groups experiences with vendor migration and the associated costs of migration of interfaces. Share your stories and experiences on the Allscripts Interface Developer Forum.

Tags: Clinical Conversion, ConnectR, Data Conversion, HL7, HL7 Interface Cost, Integration, Interfaces, Results Interface

Often times, clients take the approach that their interfaces are functioning as designed and don’t want to risk “breaking” the interfaces by making adjustments. However,  these interfaces may not be performing at maximum efficiency and/or may not be optimized to prevent errors. This issue is magnified for larger clients with a high volume of transactions.

Galen offers interface environment assessments  which leverage Galen’s ConnectR Toolbelt – a ConnectR Add-On – to provide interface engine health, findings and recommendations. Many of the reports offered in our assessment can be automated to email at a regular interval to appropriate stakeholders, yielding a view into the health of the interface engine, which is a critical component to the EHR as it files and extracts data real-time.

Two common opportunities for improvement, which are also incidentally inter-related, include auto-addition of dictionary dependencies (For example – type, status, scheduling location for appointments, order item, result item, and where performed for results) and interface database lookup scripts. In terms of auto-addition of dictionary dependencies, these interfaces are initiated before the main interface. For instance, an interface to check for the existence of orderable/resultable item, and auto-add if it doesn’t already exist can be initiated previous to the interface that actually files the result to the database.

With the aforementioned dictionary dependency interfaces, often times, dictionary lookup scripts are employed to “check” to determine if the particular dictionary item already exists in the database. In a high-volume interface, this can result in a tremendous number of “lookups” to the clinical Works DB only to result in a blocked message for the dictionary auto-add interface call in ConnectR (because the dictionary item already exists). These database lookup scripts are very “costly” in performance terms and can take tens or hundreds of times longer than an in-memory look-up. This adversely affects the systems required to do that look-up – the database and network specifically. We have developed a Cached ConnectR Lookup solution which provides an alternative to the costly traditional database lookup scripts.

In conclusion, we highly encourage clients to take time to evaluate the performance of their interface engine. As those who own a vehicle can attest, preventative maintenance is much more desirable than waiting until something breaks.

Galen offers interface assessments, on-site and on-line interface mentorship services, tier 2 interface maintenance and monitoring services (staff augmentation) and general interface consultation. Please contact sales@galenhealthcare.com  if you or your organization would like to learn more about how Galen Healthcare Solutions can help you.

Tags: Allscripts Best Practices, Allscripts Interface Engine, Allscripts Interface Training, Assessment, ConnectR Assessment, ConnectR Best Practices, ConnectR Cache, ConnectR Memory, ConnectR Performance, ConnectR Training, Integration, Interface Assessment, Interface Performance, Interfaces, Interoperability

In response to a guest post on EMRandHIPAA, we take a look at the top EHR data integration challenges faced today:

Technology

Proliferation of point-to-point interfaces instead of using a hub-and-spoke type of model (like that which Surescripts utilizes with electronic prescribing). Unfortunately, most organizations which exchange data in and out of the AE-EHR utilize highly-customized point-to-point interfaces for orders, results, documents, etc. The point-to-point model is highly inefficient and does not adhere with a “plug and play” model that so many organizations desire.

We’ve seen Allscripts make an effort to move away from this by introducing capabilities to automatically send immunizations to state registries via the Allscripts Hub by  simply modifying configuration setting (with the caveat that Allscripts has worked with the state to develop the intergration).  We’ve also witnessed companies like Medicity and its Novo Grid technologywhich offers electronic communication between physician practices, hospitals, and other health care providers. Novo embeds agents (small but powerful Java programs) in hospital data centers, physician practices and other locations. The grid component is an object oriented system that can replicate an object to multiple agents and keep it in sync across locations.

 Standards

As outlined in the EMRandHIPAA post, there are no mandated standards for EHR vendors to follow, thus making it difficult to coordinate data sharing between medical devices and other systems. Allscripts does offer the Universal Application Integrator (UAI),  which facilitates extendibility to other applications and devices. However, there is a certification process that needs to be pursued. In terms of the point-to-point interfaces previously mentioned, the Allscripts proprietary (API)  Application Programming Interface(which consists of inbound and outbound stored procedures to their primary clinical DB) does not segment out the data and configuration components of clinical exchange, something touched on in detail in a previous Galen Blog post.  Lastly, most vendors have their own specifications for HL7 message definitions. For instance, Quest may send ordering provider in OBR-16 in an interfaced result ORU message while LabCorp sends this in ORC-12. Another example is communication of “Ask at Order Entry” questions – something Quest expects to receive in repeating OBX segments while LabCorp expects this across Z-segments in an interfaced order ORM message.

Adherence to HL7, proprietary approaches.

Cost

John Halamka bravely predicted that when health IT vendors and providers began adopting new standards, the cost for interoperability would plummet: “We know that we won’t get precisely plug and play—this is a journey,” Halamka told Government Health IT. “But each year, we will get more constrained. We are going from a $20,000 -$30,000 venture hopefully to $5,000-$10,000.” Unfortunately the numbers quoted are accurate – and provide a high barrier to entry for smaller groups looking to electronically exchange data. There is the flip-side to cost and that is the ROI, which could include reduction in direct annual labor costs, elimination of non-billable tests, and elimination of lost charges.

Summary

The benefits of health information exchange are well documented. As outlined in the EMRandHIPAA post, there is a need for a “consistent, secure and reliable way to capture and share patient data among all systems and healthcare providers,” especially given that benefits in improved coordination of care and reduction of medical errors.

Tags: Allscripts, Extensibility, HIE, HL7, Integration, Interfaces, Interoperability, Results Interface, Standards

Client: MedNetworx – Azalea Orthopedics

Project: MedManager PM -> Allscripts PM Conversion

Project Timeframe: April 15^th – June 1^st (6 weeks from initial scoping to go-live)

Client Contact: MedNetworx – Mark Johnson, President and CEO.

Description: Azalea Orthopedics, located in Tyler Texas, has been providing orthopedic surgery, sports medicine & pain management in East Texas for the past 20 years. Azalea employs 130 including 17 physicians who are specialists in orthopedic surgery, physical medication and rehabilitation. MedNetwoRx, a healthcare application service provider (ASP), located in Dallas, Texas, hosts the practice management and electronic healthcare record applications for Azalea. Azalea looked to convert from a legacy PM system, MegManager, to Allscripts PM, as part of consolidating systems to the Allscripts product line. Partnering with Galen Healthcare Solutions, MedNetwoRx leverage their own in-house Allscripts product and physician practice experts as well as Galen’s deep experience with clinical and administrative data conversion.

To facilitate this conversion, flat-file extracts were obtained from MedManager for dictionaries, demographics and appointments. However, instead of using these extracts to import into Allscripts PM, an alternative approach was taken in which real-time appointment and demographic interfaces were deployed from the client’s existing Allscripts Enterprise EHR to the new Allscripts PM environment. This offered the flexibility of having the PM data populate real-time. Interfaces were also required from Allscripts PM to Allscripts Enterprise EHR. Thus as part of the go-live, existing reg/sched interfaces from MedManager to Allscripts Enterprise EHR needed to be deployed.

Utilizing existing data in the Allscripts Enterprise EHR as well as flat-file extracts from MedManager (for more complete insurance and referring provider information), a conversion of dictionaries, registrations and appointments was executed.  Care had to be taken to ensure that appointments loaded into Allscripts PM would be able to map to existing appointments in the EHR and update appropriately instead of creating duplicate appointments. The same consideration had to be made for dictionaries to ensure proper matching on codes.

All patients (inactive and active) and appointments for the previous 2 years as well as future appointments were loaded from the Allscripts Enterprise EHR into Allscripts PM. Since insurance information wasn’t being captured in the EHR, and update of patient’s accounts in PM had to be executed, utilizing flat-file output from MedManager. Additionally, the patient MRN seed in PM needed to be reset as to avoid contention, and insurance and referring provider dictionaries were updated using extracts from MedManager, since the extracts contained more complete data than the EHR.

Conversion Statistics:

Tags: Allscripts, Allscripts Conversion, Allscripts Enterprise EHR, Allscripts PM, Clinical Conversion, Data Conversion, Galen Clinical Conversion Toolkit, Integration, Interfaces, MedManager, MedNetwoRx, MSO, Multi-Org, PM Conversion, Practice Management Conversion

Client: Lexington County Health Services District (LCHSD)

Project: Columbia Medical Group Greenway Primesuite EMR-> Allscripts Enterprise EHR Conversion

Project Timeframe: April 13^th – June 1^st (6 weeks from initial scoping to go-live)

Client Contact:  Donna Lyles Basden, Director of Physician Support Services, David Gavin, The Columbia Medical Group Practice Administrator

“A key success factor in the assimilation of The Columbia Medical Group into our organization was the conversion of data from their Greenway Primesuite EMR to the District’s Allscripts Enterprise EHR.  The Galen conversion team was able to successfully extract and convert the data, such that our patient demographic and discrete clinical data was available seamlessly within Allscripts EHR on day one . The technical expertise and support from Galen was impressive.” – Donna Lyles Basden, Director of Physician Support Services, Lexington County Health Services District

Background:

Lexington County Health Services District, Inc. (LCHSD), located in Lexington County, South Carolina, is a health care district comprised of more than 40 physician practices which span across multiple specialties (Primary Care, Internal Medicine, Ob-Gyn, Orthopedics, General and Bariatric Surgery, Pediatrics, Rheumatology, Endocrinology, Oncology); Community Medical Centers; Occupational Health and anchored by Lexington Medical Center, a 414 bed acute care facility. Lexington sought to incorporate Columbia Medical Group – an 8 provider multi-specialty practice with 7 Internal Medicine and 1 Neurology provider – into their organization and also have the group convert from Greenway PrimeSuite EMR to Allscripts Enterprise EHR.

The scope of the data conversion spanned approximately 6 months of clinical data from the Greenway PrimeSuite EMR.  The nature of the data included 1^st and 2^nd generation data from Greenway EMR; including data entered directly into Greenway as well as previously converted demographic data from the previous EMR in place at Columbia Medical Group (GE Centricity).

Challenges inherent in some of this information were embedded in the fact that on the fly “free text” entries were previously allowed for Greenway elements such as Problems, Allergens and Allergen reactions.  This presented situations where consolidated translations and additional application build were required in order to account for the different variations and combinations of the data.

Data Extraction:

The data extraction process was performed using SQL based extracts including a common delimiter and standardized field definitions for each data element.  Flat (text) files were generated for each data element from the source system, FTP’d to the interface engine server and ultimately placed in a directory for ConnectR to process.

Data Element Extract Breakdown:

Allergies – manual translations (T-tables generated) for both Med and Non Med Allergens.  Allergens incorrectly categorized or that were not able to map and build on the EHR side were also dealt with as Unverified allergens.  Reactions and comments were formatted, concatenated, and stored in EHR as Allergen annotations.

Immunizations – due to the manageable size of the source system peripheral dictionaries manual translations were performed and maintained in the extract for Vaccine Medication, Route, Site,  and Manufacturer.  Comments and various care providers were also dealt with as Immunization annotations in EHR.

Results –Lab results for all ordering providers which included discrete results spanning 3 previously used performing locations (LabDaq, LabCorp, and Quest).

Vitals – included height, weight, temperature, O2 sat, pulse, respirations, and blood pressure.  Also included were orthostatic vital entries from the source system.

Problems (Unverified) – because an unverified and unrecognized item is considered just that, various discrete elements were identified and concatenated to provide useful and relevant context to unverified Problems in EHR in order to assist in making the verification process manageable and reduce chart pulls and use of the legacy EHR.  Naming convention adopted for Active, PMH, PSH, FamHx, and SocHx: Greenway Problem Name + OnsetDate (or date of procedure) + Notes/Comments

In situations where ICD9 code values were associated with the problem entry in the source system it was passed to EHR in order to assist with codification requirements and provide assistance during the ACI search and problem verification process.

Medications (Unverified) – naming convention adopted for unverified medications. Greenway Medication Name + ‘*’ if RX originated outside of the practice + medication status (Active, D/C, etc.) + RX original date + RX provider + Notes/Comments

In situations where codification requirements could not be met or supplied the first 8 characters were defaulted into the Search Text for unverified medications in the ACI search field in order to assist with the ACI search and verification process.

Clinical Conversion Toolkit

The Galen Clinical Conversion Toolkit was utilized to load the extracted conversion data into the Allscripts Enterprise EHR. The conversion statistics for the go-live can be seen below:

*Note that all of the errors above were patient matching errors and were manually reconciled using the Allscripts Patient Bridge tool.

Tags: Acquisition, Allscripts Conversion, Allscripts Enterprise EHR, Clinical Conversion, ConnectR, Data Conversion, Integration, Interfaces, Success Story

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.

Tags: AIDN, Allscripts, Allscripts Forum, Allscripts Interface Developors Forum, Allscripts Interfaces, Collaboration, Community, ConnectR, Extensibility, Integration, Interfaces, Interoperability, Knowledge Share

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

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

Tags: Allscripts, Allscripts Consultants, Allscripts Enterprise EHR, EHR Implementation, Enterprise EHR, Interfaces, Meaningful Use