Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

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

Galen Healthcare Solutions was founded on the belief that the Allscripts Enterprise EHR is the premier ambulatory electronic health record and the conviction we could add more value to the community by focusing on client side implementations.  Over the past 5 years, we have watched that dream become a reality in many ways.  We are currently working with hundreds of clients and have over fifty experts working on our team in a variety of roles.  Our vast expertise is a critical component of facilitating our partners’ successful deployments and advancements of the electronic health record. 

At Galen, we believe strongly in sharing our success and giving back to our community.  One of our driving tenets internally is to “Perpetually Learn and Share”.  As a team member at Galen, it is not simply an expectation to further one’s knowledge of new and evolving areas of the application and stay current with the latest releases but a requirement. Furthermore, we foster a collaborative environment where this experience and knowledge are communicated to the entire team.  This has been instrumental to our success and ensures that when you work with a Galen team member you are getting full access to the resources that define our organization. 

This goal is not just an internal method for us to keep up to date and deliver value to our clients; it is also our philosophy to share this knowledge with the community for free.  We have established many forms of knowledge sharing for the community and our hope is that we are able to further educate the entire industry by doing so.  Throughout the years, we have actively expanded our roster of free guidance and I’m proud to affirm we now have three ways to share this knowledge:

The Galen Wiki – This houses the industry’s largest source of free Enterprise EHR information.  We currently have many customers, competitors and colleagues that use this repository on a regular basis to research and share information.  The Galen Wiki also allows you to sign up for an account if you’d like to share information.  If you haven’t accessed this site, we hope that you’ll take a minute to see what we’ve shared.  (http://wiki.galenhealthcare.com/Main_Page)

Galen Webcasts – Many groups utilizing the Enterprise application have benefited from the various webcasts that we have offered to date.  Our team offers a few sessions each month to cover various topics, including technical and functional based sessions.  The overall feedback has been remarkably positive and we feel this has been a great forum to educate the community and share some of the experience we’ve gained.  These webcasts are free to join and are announced on our website.  If you haven’t attended a session, we encourage you to register for one of the upcoming events!  (http://www.galenhealthcare.com/calendar/)

Allscripts Interface Developers Network – Most recently, we launched a new forum dedicated to the Allscripts interface developers community.   This is meant to assist with questions and advice for interface developmental needs.  As the content and usage grows, our hope is that this will become the primary place to research interface advice or post a question with the challenges you are currently facing.  If you are an interface developer or work with interfaces on a regular basis, we suggest that you check it out and post questions or suggestions you may have.   (http://interfaces.galenhealthcare.com/)

These forums are our way of giving back to the community that has supported us throughout the years.  As we continue to grow and identify further needs, we expect these to continue to grow as well.  We hope that each of you is able to gain valuable insight from each of these resources and cultivate your own expertise so you can in return perpetually learn and share.  Together we will conquer the challenges universally faced within health care today and ensure that everyone in the community is well prepared to implement and deploy the Allscripts Enterprise EHR.

Tags: Allscripts Consultants, Allscripts Enterprise EHR, EHR, Galen Webcast Series

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

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