Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

Issue:

A recent issue came up with one of our clients in that interfaced patient appointments from their Practice Management system were not making it in a timely manner to the EHR. The client witnessed that appointment messages built up in the interface queue and there was a delay in processing the messages. The client desired a resolution that would assist in speed up of the processing of the messages such that appointments booked in PM would render in the EHR quickly without a disruption to workflow.

Investigation:

Enter the ConnectR Toolbelt “Transaction Processing Time” report:

This report extracts transaction count, minimum, average, and maximum ConnectR processing time per hour. Using the report, the following analysis was conducted.

Findings:

Based on the aforementioned analysis, it was determined that in the clients Live Reg/Sched system target, blocked messages were being logged. Having blocked messages logged can be invaluable when first designing and developing interfaces. However, as evidenced in the analysis, it can lead to performance degradation as the system requires much less processing time when messages are not logged.

Outcome:

Logging of blocked messages in the Live Reg/Sched target was disabled on 6/30/2010 and as witnessed in the analysis spreadsheet the number of transactions decreased by roughly 70% and peak transaction processing time decreased by roughly 90%.

Tags: Allscripts Enterprise EHR, Business Intelligence, ConnectR, ConnectR Toolbelt, Integration, Interfaces, Meaningful Use, SQL Server Reporting Services

Drawing on our past experience and expertise with data conversions, we recently assisted one of our clients with a conversion of administrative ICD9 diagnostic data extracted from their Practice Management system to clinical Medcin-based  problem data within the EHR. The project ultimately saved a tremendous amount of data entry time. Upon completion of the data-conversion, clinicians were then able to review the problem list in “Past Medical History” section of the patient chart within the EHR and categorize by either choosing to make the problem “active” or mark redundant or resolved problems as “Entered in Error”.

As with any data conversion, one must be cautious in terms of negative implications. For instance, administrative data has its limitations, and an example or where the process can go wrong is the highly-publicized case of e-Patient Dave.  Ultimately, problem conversions can be useful, but the data needs to be reviewed, and almost treated as suspect.  The value in the conversion is saving the entry of the problems that are accurate – say 80-90%.  Any that are incorrect, will be reviewed with the patient and can easily be marked EIE.

Statistics:

• 1,007,238 problems were loaded to the EHR for 205,831 patients via the interface engine, taking about 11 hours to process totally.
• PM Extract file statistics:
  • Total matchups of ICD9s to patients: 5,405,874
  • Total Unique ICD9s: 8346
  • ICD9s that only match up with 1 patient:1295
  • ICD9s that match up with 100 or more patients: 2027

Approach and Components:

• Master approved “ICD9” list provided by client
• Extract of ICD9 data from PM system provided by PM vendor
• Automated macro that attempts to match ICD9 to Medcin. Potential matches include the following:
  • 1 to 1
  • One to many (20 or less)
  • One to many (20 plus)
  • One to none
  • Each of the different flavors of matches were marked with an annotation (highlighted via an asterisk) to identify to clinicians the logic that was used in importing the problems:

• Once the translation was finalized, it was loaded into the interface engine and mapping logic loaded problems into the patient chart in the EHR via the API (existing stored procedure).

Known Issues Mitigated:

• Due to incorrect logic, some ICD9s were linked to patient profiles improperly. To mitigate this, a script was run to mark these problems as “entered in error”
• Problems were loaded to the “Past Medical History” section of the patient chart with a status of active. However, given this status, it didn’t facilitate providers to easily change the problem to be an active problem linked to a note.

Lessons Learned:

• Execute a proof-of-concept and as with any technical project, get clinician feedback. The client had a pilot group of 5 clinicians to vet out issues and bless the data before the live conversion was run.
• Do NOT use spreadsheets to track the cross-walk between administrative ICD9 diagnoses and clinical Medcin problems. Rather utilize a staging DB to serve as a single repository in developing ICD9 to Medcin translations. Also, the data from flat-file export from PM can be loaded into a staging environment via SSIS such that it can be analyzed and summarized while facilitating persistence.
• Make sure to tie the problem conversion load to a specific provider, that way if side effects or issues are identified after the fact, there is a clear way to identify which problems were loaded in the conversion via the provider they are tied to. The interface log should also have a record of this, but most organizations set the retention time to 90 days.
• Workflow validation – ensure that the workflow to move problems from PMH to Active will not be a barrier to use.

If your organization is looking for assistance in data conversion, please contact sales@galenhealthcare.com and visit our website for more information regarding our technical service offerings.

Tags: Allscripts, Allscripts Enterprise EHR, Data Conversion, ICD9, Interfaces, Medcin, Problem Conversion, TouchWorks Problem

Business Need/Problem Statement

Some of our clients have recently expressed the desire for a limited, read-only view in to the AE-EHR to extend access to audit entities. For instance, the requirements of one organization included a limited patient-access read-only environment to be in compliance with FDA Research Part 11 restrictions for clinical trials. Another organization needed it for insurance audit purposes. And still again, others desired to provide an extended environment to allow hospitalists, ED physicians, and critical care physicians access to selective patient charts.

Approach

One of the more popular approaches has been to segment out a separate read-only organization in the Allscripts Enterprise Electronic Health Record (AE-EHR). The AE-EHR handles organizations quite nicely and facilitates an approach of segmenting out entities – the following Galen Wiki article covers a scripted means of deploying a new organization in v10 AE-EHR.

Once the organization has been created, patients can then be “bulk-loaded” to the organization via SQL scripts. New AE-EHR users can then be created and associated to this organization. Finally, to setup the read-only portion, security gates can be implemented.

Extendability

An additional requirement of one of our clients included an approach that offered the capability to dynamically add/remove patients to the “Audit” organization real-time. We facilitated this via creation of a file-based interface from ConnectR to the AE-EHR. The interface accepted its input from a well defined flat-file (comma-delimited, including MRN, Action – Add or Remove, and OrganizationID) and utilized that data to add/remove patients to the org via a custom stored procedures – the de facto application programming interface (API) to the AE-EHR clinical database.

And still further, another client requested that the audit/read-only entities (users of the system) be granted the ability to create tasks . For example, the client desired a specific, high priority task, identifiable as originating from the audit/read-only entity – in this case hospitalists which could be assigned to the patient’s PCP. In this case, the clients’ hospitalists could communicate high priority continuity of care tasks, which require prompt reaction, to the PCP at discharge. However, the PCPs should not be able to task back to the hospitalists, and this can be achieved by setting the EnableOrgFilterFlag preference in the AE-EHR.

If your organization needs assistance in setting up a audit environment to provide limited, read-only access to the AE-EHR, please contact sales@galenhealthcare.com and visit our website for more information regarding our technical and professional service offerings.

Tags: Allscripts Enterprise EHR, Audit, EHR, EHR Implementation, Extendability, Interfaces, Read-Only, Tasking

One of the many challenges in interfacing to the Electronic Healthcare Record is patient identification and matching. Results and documents from outside systems need to link to the correct patient record. This is especially profound in data conversion initiatives. Given the scenario of an organization converting to utilize an EHR, aside from the plethora of documents being scanned in and associated with the chart as well as “bulk loads”  from the practice management system, there are could also be several data silos which need to feed data into the EHR.

We encountered one such scenario with one of our clients. Our client had been processing and loading flat-files from its legacy systems into the EHR. The client loaded approximately 15 years of legacy data (equating to millions of records). In the import process, the client had followed a strict patient matching criteria and received a patient matching error rate of approximately 5% which may be considered a reasonable matching rate.

However, the client’s help desk was getting a multitude of calls reporting missing legacy system records in the EHR (suspected to be in the 5% that did not make the conversion). The issue working against the client was a drop-dead date upon which these legacy systems were being deprecated and thus the clinicians would no-longer have a “fall-back” plan to access the records – the repercussions of which were potential patient care issues.

As such, Galen was engaged to analyze the records that did not meet the strict patient matching criteria , determine which records could be successfully loaded to the EHR under relaxed patient matching rules, and describe the impact of relaxing the patient matching. In the analysis that followed, it was recognized that in the data set that erred due to patient matching errors, identifier fields (namely first name, last name, DOB, MRN, Other Number1 and Other Number2) exhibited typos and inconsistencies. Enter Microsoft SQL Server Integration Studio’s (SSIS) Fuzzy Lookup Transformation. For those unfamiliar with fuzzy logic, it is “the process of reaching conclusions based on information and facts that are not 100 percent certain.”

The underlying algorithm to the Fuzzy Matching transformation is the SOUNDEX function:

• In the late nineteenth century, United States census officials faced a dilemma. During the process of counting the huddled masses, our public servants created a huge paperwork trail that the law required them to preserve for future historians. With amazing forethought, they realized that people searching for records might not know the exact spelling of their ancestor’s name. Was it Smith or Smythe? Chapple, Chapel or Chapelle?

• To ease these searches, census officials turned to the Soundex phonetic filing system. This system uses a simple phonetic algorithm to reduce each name to a four character alphanumeric code. The first letter of the code corresponds to the first letter of the last name. The remainder of the code consists of three digits derived from the syllables of the word.

• Largely unused outside of the halls of government and genealogy, the Soundex system is making a comeback in modern databases. Database developers have long struggled with the problem of matching words that might not look alike, but actually sound alike.

Thus to reclaim some of the records that erred in matching to a patient chart in the EHR, the Fuzzy Matching transformation was utilized. Flat-files output from legacy data silos were input, pre-processed and then fed to the transformation. Given previous studies, the matching criterion utilized was as follows:  Match on LastName and FirstName Similarity Threshold >.8 AND DOB matches exactly AND one of three (MRN, OtherNumber, OtherNumber2) cross-referenced match exactly. The end result was reclamation of close to 25% of those legacy system patient records that originally failed patient matching.

If your organization is looking for assistance in data conversion, please contact sales@galenhealthcare.com and visit our website for more information regarding our technical service offerings.

Tags: Allscripts Enterprise EHR, Data Conversion, Database, Integration, Patient Matching, Technical, TouchWorks