Archive for the 'TouchWorks EHR' Category

Announcing Free Galen EHR and Analytics Webcasts

Galen Healthcare Solutions will be hosting a series of free webcasts covering the Allscripts EHR database and Allscripts Analytics application.

The purpose of the EHR webcasts is to give a detailed view into the underlying database schemas as well as useful queries for the Patient and Order/Results tables. For Analytics we will be covering a basic overview of the Analytics applications as well as detailed examples using Worksheets and Crosstabs. 

These will be structured in a similar format to university courses – the three classes will be at 100 (intro) levels.  The list of the webcasts and their times may be found below.

 

Allscripts EHR – Patient: Overview of the Patient tables as they relate to the Allscripts EHR Database. This course will cover basic concepts related to Patient tables, as well as useful queries, views and general best practice techniques. 

  • Wednesday, June 2nd, 2010 at 2:00pm EST

Allscripts EHR – Order/Results: Overview of the Order/Results tables as they relate to the Allscripts EHR Database. This course will cover basic concepts related to Order/Results tables, as well as useful queries, views and general best practice techniques. 

  • Wednesday July 7th, 2010 at 2:00pm EST

Allscripts Analytics: Overview of the Allscipts Analytics application. This course will cover basic concepts related to general functionality of the Allcripts Analytics applications, including example Worksheet and Crosstab problems as well as general best practice techniques. 

  • Wednesday August 11th, 2010 at 2:00pm EST

To attend, please contact Dave Boerner, Dave.Boerner@galenhealthcare.com . You must be an existing Allscripts Enterprise EHR client to attend.

We also offer training courses and reporting services for the Allscripts Enterprise EHR database, ETL database, Analytics and the ConnectR  database.  Please contact sales@galenhealthcare.com for more information regarding these courses and our reporting services.

Administrative ICD9 Diagnoses to Clinical Medcin Problem Conversion

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.

    A Pragmatic AE-EHR Audit Environment

    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.

    EHR Database Architecture and Reporting Workshop

    Galen will be hosting another in Enterprise reporting workshop this coming March.  This has been a popular course, so please sign up early!

    What: A three-day course for report writers, DBAs and those in healthcare informatics on the Allscripts Enterprise EHR database.
    When
    : March 1 – 3, 2010
    Where: Boston, MA
    Price: $2,500


    The Galen Database Architecture and Reporting Workshop has furthered our understanding of the Allscripts Enterprise EHR database.  The clear presentation and substantial hands-on time helped us to greatly accelerate our production of customized reports.  And, the data dictionary documentation alone is invaluable.
    – Chris Hyde, DBA, Albuquerque Health Partners

    The attached announcement includes additional information regarding the course and suggested audience (report writers, DBAs, etc).

    Please contact Mike Dow to register, or if you have any questions – mike.dow@galenhealthcare.com


    Estimated Effort to Exhibit Meaningful Use

    There is quite a bit of buzz in the healthcare IT community surrounding the ONCHIT/CMS release of the Meaningful Use Interim Final Rule and the  and the EHR certification requirements. The author of HISTalk kindly spent his New Year’s Eve poring over the documents to provide an excel worksheet summary of the actual criteria and thresholds and the author of the Medical Software Advice blog did a great job of outlining definition, features and measurement with his blog entry.  I thought I would take it a step further and provide some meaningful information to CFOs and PMs by taking a stab at quantifying the effort involved with each measure. First some background information and disclaimers:

    • This estimated effort is based on 50 physician multi-specialty organization.
    • It is intended to give a ballpark of effort involved and the numbers serve as estimates only.
    • It does not necessarily scale linearly with number of providers or specialties.
    • The effort only addresses four categories of effort – implementation, technical, interface and training.
    • Categories of effort not addressed include project management, systems configuration and deployment, networking configuration and deployment, hardware (including desktop) deployment, and helpdesk and on-going support.

    The meaningful use matrix with effort broken-out can be found on the Galen Healthcare Solutions Wiki.

    Now that we have presented the effort involved, let’s delve into how EHR deployments – specifically  AE-EHR deployements – are typically phased:

    Phase I: Base, Document, Scan and Dictate

    Description: Provide a baseline level of EHR functionality to all users. Real-time access to physician schedules, transcribed and scanned documents, facilitation of dictation.  Data conversions, Scanned charts and documents, Base Deployment. This approach typically appeals to all providers regardless of technical aptitude and would not require significant workflow changes

    Advantages: Clinical information access internal and external to the clinic, reduced level of change for physicians through the use of dictate, realized benefits of decreased errors and re-work.

    Interfaces:

    • Registration & Scheduling
      • Real-time inbound registration and scheduling feed from practice management system.
      • Initial bulk-load of existing active patients and appointments
    • Transcription
      • Real-time inbound transcription interface from transcription system.

    *Phase II: Rx+, Note, Forms, Results

    Description: Add medication management, structured note and results

    Advantages: Ability to collect structured information facilitating use of panel queries. Additionally, formulary compliance, and prescription faxing/e-prescribing to pharmacies and ability to capture results as discrete data elements

    Interfaces:

    • Results
      • Real-time inbound results interface from lab system.

    *Phase III: Order, Charge

    Description: Facilitates charge capture and order transmission.

    Advantages: Completes the access to centralized patient data and further enhances the quality of care and service to patients.

    Interfaces:

    • Orders
      • Real-time outbound order interface to lab system
    • Charge
      • Real-time outbound charge interface to the practice management system.

    *Phase II and III can be combined based upon the organization requirements

    In conclusion, one of the biggest questions that lingers for me is how the data is to be relayed to the government such that organizations can be evaluated as to whether or not they meet the thresholds to receive the incentives. Custom reporting comes to mind as precedent has been set here, specifically with PQRI and Medicare HCC. Galen Healthcare Solutions certainly can provide custom reporting specific to organizations needs in order to communicate meaningful use. Another solution is Allscripts Clinical Quality Solution powered by TeamPraxis. In the meantime, we wait for the rule to be finalized and anticipate announcement of how the meaningful use data is to be relayed.

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

    Legacy Data Conversion: Fuzzy Patient Matching to the EHR

    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.”

    SSIS Fuzzy Lookup

    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.

    Allscripts Enterprise EHR Carbon Copy Feature

    Allscripts Enterprise EHR Custom Reporting

    The requests for reports that we get runs the gamut. Most of the time, clients are looking to modify the existing canned reports that Allscripts offers with the Allscripts Enterprise Electronic Health Record (AE-EHR). Other times, clients envision a custom report that is unlike any of those currently offered and is unique to their particular organization. And still further, some organizations wish to fulfill reporting metrics to receive monetary incentives from initiatives such as the Physician Quality Reporting Initiatives (PQRI) and P4P (Pay for Performance) .  Given the commonalities in the requests we receive, with our reporting solutions store, we have attempted to pick the most popular reports requested from clients and offer them via on-demand payment, download and installation.

    We also receive a substantial amount of inquiries from clients as to what exactly goes into customizing existing reports and creating new reports. Clients are often curious as to what types of skill sets are needed. These organizations may feel that they are better suited to have their own personnel develop custom reports. For instance, the organization may have performed an return on investment (ROI) analysis and determined it makes the most financial sense to train their own staff to supply the multitude of administrative and “print” reports they require in the coming future.

    That said, let’s get to answering the question of what goes into developing custom reports for the AE-EHR:

    1. AE-EHR Clinical Database Stored Procedures: These are used to extract data out of the database to render in the report. The stored procedures can be thought of as a “middle-man” between the database and the Crystal Report. More information on the basics of stored procedures can be found via the following link.
    2. Crystal Reports: Most AE-EHR reports are developed using Crystal Reports. Crystal controls the how the data extracted from the stored procedures renders in the final report. Crystal offers functionality for pivot tables, summary of data fields, grouping, custom formulas, suppression based upon data values, etc. For more information on Crystal reports tutorials, follow this link .
    3. Insert Scripts:  There are several places that reports can be installed within the context of the application’s user interface (UI) – these are called “Calling Points.” Reports can be printed from the administrative workplace, and also added to the UI for the traditional “print documents” – immunization or results “calling point” for instance.

    AEEHR Custom Reporting

    The most important ingredient to custom AE-EHR report recipes comes in the experience – specifically knowledge of the database schema. Knowing what tables to pull from, how tables are related, and what functions, stored procedures and existing custom reports can be utilized so as to not re-invent the wheel. Knowledge of advanced SQL querying is invaluable as well. If you would like to learn more, Galen is offering free EHR Reporting webcasts.

    Let us know if we may assist your organization in developing and delivering custom AE-EHR reports. In addition to the reporting solutions store, we also offer training courses and reporting services for the Allscripts Enterprise EHR database, ETL database, Analytics and the ConnectR  database.  Please contact sales@galenhealthcare.com for more information regarding these courses and our reporting services.

    Troubleshooting Healthcare IT Problems

    The name of the game in Healthcare IT is problem-solving. As such, I find this is where my own background in engineering benefits me in that I  was taught to take a methodical approach in troubleshooting and root-causing technical issues, fully documenting findings and results. That said I would be remiss if I did not mention some invaluable tools which aid technical issue investigation:

    A Healthcare IT professional’s tools of the trade (must-haves):

    In addition to the technical component of the job, an equally-important component is communication. I’ve found that utilizing the proper communication channels can drastically reduce problem-solving time and effort. As Dr. Halamka alludes to in his blog yesterday, a good rule is if more than 3 rounds of emails go back and forth about an issue, it’s time to pick up the phone or have a meeting.

    The first step in investigating an issue starts with having the proper background information provided by the client. Utilization of an issue submission form is invaluable to document all items surrounding the issue. With incomplete background information, the Healthcare IT professional is forced to solicit more information from the client – forcing unnecessary additional communication and driving up the time-to-resolution.

    Once background information has been assimilated and an email thread has been opened, if the issue cannot be resolved in more than 3 rounds of emails as alluded to above, a conference call should be scheduled. The components and outcomes for a successful healthcare IT technical troubleshooting conference call are as follows:

    • Well formulated problem statement and documentation provided to all parties on the call
    • Issue submittal form to include short description, full description, screen shots, steps to reproduce, onset, frequency, users/devices affected, etc.
    • Skeleton Agenda
    • Ensure that the right representatives are on the phone (RIS analyst, Lab HL7 interface analyst, etc)
    • Vet issues related to the different “layers”
      • Application Analysts
      • PC/Desktop Techs
      • Network Analysts
      • Server Techs
      • Server Architects
      • Storage Architects
      • OS Architects
      • DB Architects
      • Application Architects
    • Action items for representatives if the problem is not resolved
    • Eliminate misinterpretation via oral communication
      • Representative 1: “This is what we are expecting”
      • Representative 2: “Really? Wow, we never expected that.”
      • Representative 3: “We never would have interpreted the spec to mean that”

    And finally, for a great article addressing troubleshooting complex IT problems, please see Dr. Halamka’s blog article posted in December of last year.

    Please contact sales@galenhealthcare.com and visit our website for more information regarding our technical service offerings.

    Announcing Galen EHR Reporting Webcasts

    Galen Healthcare Solutions will be hosting the second series of free webcasts covering Allscripts EHR Reporting.  The purpose of these webcasts is to provide insight into reporting options within your EHR database.  We will cover approaches to reporting, database structure, and hands-on querying of the EHR database.

    These will be structured in a similar format to university courses – the initial three classes will be at 100, 300 and 500 levels.  The list of the webcasts and their times may be found below.

    100 Series – Introduction to the Allscripts EHR Database: Overview of the database, patient demographics and dictionary linking.

    • Wednesday, December 2nd, 2009 at 2:00pm EST

    300 Series – v11 Order and Results: querying configuration and patient data.

    • Wednesday, January 13th, 2010 at 2:00pm EST

    500 Series – Advanced ConnectR Architecture and Querying

    • Wednesday, February 3rd, 2010 at 2:00pm EST

    To attend, please contact Mike Dow, mike.dow@galenhealthcare.com.  You must be an existing Allscripts Enterprise EHR client to attend.

    We also offer training courses and reporting services for the Allscripts Enterprise EHR database, ETL database, Analytics and the ConnectR  database.  Please contact sales@galenhealthcare.com for more information regarding these courses and our reporting services.

    « Previous PageNext Page »