Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

—Discrete Clinical Data Elements as the building blocks to a Connected Health Platform—

Broken down to its basis, any vision of a truly connected Health Network will be reliant on the ability to pass, and ultimately present, discrete data elements.  Although the audiences for the information will be diverse, and the front-end systems will vary, the foundation of the information is the same.  In order to unlock the value that lies in the data being captured every day, an organization must have solid planning and execution. 

Each organization we work with is unique, but overall themes are constant: Reporting for Meaningful Use, Optimizing Health Care Decisions with Analytics, and Growth through Acquisition or Partnership.     

If we consider Clinical Data as building blocks that will be used, in whole or part, to support these efforts, we need to ensure both the ease of access and integrity of that data.  Galen has leading expertise and insight on conversions, reporting, and interfaces that can help you down this path. 

So how do you take the first steps in creating solid building blocks?  We would recommend to:

Define and establish consistency in electronic documentation and workflow.  This starts by understanding the EHR build and configuration decisions that will impact both availability and integrity of the data.   This consistency will also pay dividends to the organization by making the support of the Enterprise EHR system more predictable and efficient. 

Independent of your organization’s current state, Galen has the breadth and depth of expertise to help achieve your vision.

Tags: Allscripts Consultants, Allscripts Enterprise EHR, Clinical Conversion, Data Conversion, EHR Implementation, Enterprise EHR, Healthcare IT, Interoperability

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

Have you ever found yourself asking how the heck does Imagelink work?  How is it possible to click a button in the Allscripts application and view an X-ray?  Have you ever wanted to know how a result closes an order is closed without a Touchworks Order number?  Have you ever heard someone say, did you check the requested performing location dictionary, and not know what they’re saying?  Have you ever wanted to know more about Allscripts result interfaces?

Well you are in luck! The Galen technical services team is proud to host a Free Results Interface Training hosted at it’s brand new office!

Who: Allscripts Interface Analysts

What: Free Result Interface Training

Where:  70 Federal Street, 7th Floor, Boston, MA 02110.

When:  Wednesday, December 14th, 2011 from 9AM-5PM with lunch provided.  There will also be a cocktails and networking hour from 4PM-5PM with beer, wine and light snacks.

Why: Learn about more of the intimate details, nuances, and best-practices surrounding Allscripts result interfaces

Agenda:

• Imagelink
• Reconciliation w/ and w/o eletronic order interface
• Common errors
• Requisitions
• Requested Performing Location
• Auto synching
• Much More!

Please contact us if there is a topic you would like to learn more about that isn’t in the list above.

Travel:  If you are driving into the city, there are parking garages nearby. The cheapest and most convenient is the Winthrop Square Parking Garage at $20/day.  If you are coming in from out of town, there are many hotels in the area.  Also note that we will have wireless internet and workstations with a hardwired internet connection available for those who need it.

Space is limited – Register Today! If you can’t make the training, it’s ok!  Galen offers free webcasts about every two weeks.

Tags: Allscripts, Allscripts Enterprise EHR, Allscripts Interface, ConnectR, ConnectR Training, Galen Webcast Series, Integration, Interface Training, Interoperability, Results Interface

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

This is the first (in my humble opinion) controversial article to be published on the Galen blog and was inspired by the challenge issued  by John Lynn over at EMRandHIPAA.

I personally like to call it blog sparring. Basically, you take someone else’s post and provide the opposing perspective or at least you add to the conversation that they started. I love these types of interactions with other bloggers. Plus, I love the deep dive into a specific topic that happens when you do this type of blogging. As a reader, I think it’s fun to read the various blogger’s perspective on the topic. So, on that note, I’m going to make the next week, Blog Sparring Week.

Let the parallels between the EHR and the ATM, and between patients safely visiting the hospital and flying in a plane stop here. I find it interesting that humans natural gravitate towards drawing comparisons on past experience. It’s a lot like how the federal government based the model for Regional Extensions Centers (RECs) on the model for US agriculture, which was intended to disperse new info to the family farm. Alike agriculture, the goal is to ensure that HIT is reaching the family physician and providing advice in terms of selection and implementation. Yes, it’s true that there are lessons to be learned from other industries, but as Keith Boone of at the Healthcare Standards blog recently pointed out, it must be done thoughtfully.

Recently, Brad Waugh, CEO of Navinet, brought up another Healthcare IT analogy – that of Air Travel and Interoperability – on the Navinet Blog:

The patient in the National Journal article, after being sold a flight departing months past his desired travel date, after he is required to fax in a consent form, and after he must call a separate company to handle his baggage, informs the customer service representative that in a modern system, he would be sold “a safe round-trip journey, instead a series of separate procedures. It would have back-office personnel using modern IT systems to coordinate my journey behind the scenes. The systems and personnel would talk to each other automatically. At the press of a button, once I entered a password, they would be able to look up my travel history. We’d do most of this stuff online.” He’s describing the way most industries operate today, from air travel to banking to freight transportation, all of which are able to successfully communicate between systems, companies and types of data.

While it’s true we often wish that the healthcare industry was as efficient and safe as the aviation industry, the fact of the matter is, patient safety is harder and will require more effort as Jeff Terry, Managing Principal, Clinical Operations, asserted on the GE Healthcare Quality & Safety blog.

Why is patient safety harder? You be the judge:

1. On any given day in the United States, there are about 800,000 inpatients and many more outpatients. By contrast there are about 30,000 flights per day.
2. The major US airlines fly about 25 different types of planes. By contrast, the ICD-10 lists 12,420 diseases. Each plane, like each disease, requires different protocols to manage.
3. There are 2.5M nurses compared to 200,000 pilots

And that brings us to the recently asserted Boone’s Law, first published on Keith’s aforementioned blog:

Boone’s Law

It’s very similar to Godwin’s law, but related specifically to Health IT.  In any sufficiently long discussion of Healthcare IT, the probability of a comparison being made to the financial sector approaches unity. Keith’s corollary is that that in any sufficiently long discussion of patient safety, the probability of a comparison being made to the aviation industry also approaches unity.

Key points:

1. Transaction payload – Single pieces of data are not being transmitted in the payload with healthcare. Conversely, financial transactions however are very small (include account holder identity info, merchant identity info, and a transaction amount.
2. Business model – in financial transactions, there’s a payment model already built in, who would pay for it in healthcare transactions and why?
3. Regulation, Trust and Security – The financial industry deals with audit trails, logging and security, but again, back to point #1, single pieces of data aren’t in the payload, there are instead hundreds or thousands – especially with imaging studies.

I’ll leave off the debate with an article I read while taking the train home last evening –  “Point to Ponder” written by Greg Gillespie, Editor in Chief, Health Data Management.

Aviation experts quoted in a Wall Street Journal article predict the accident will result in a shake-up of pilot training over concerns pilots have abdicated too much responsibility to computer aids and, when those aids malfunction, can’t handle emergencies because of rusty piloting skills.

Not sure anyone would argue the health care industry is in any immediate danger of being over-automated, but the question of whether automation serves the user, or vice versa, is an important one. Industry gurus typically point to aviation as a model for medical reform, and there is absolutely no question that automation has increased aviation safety. But automation shouldn’t lead us to a point where a pilot stops being a “real” pilot, or a clinician a “real” clinician.

Well put Greg. As much as computers aid our decisions, we should never completely remove or undervalue the human element.

Tags: Air Travel, ATM, EHR, Financial, Healthcare IT, HIPAA, Integration, Interoperability, Patient Safety, REC, Regional Extension Center, Security

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

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