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