From the January 2017 issue of HealthCare Business News magazine
One method used was to prefix (or suffix) values with a string to uniquely represent the source facility. For example, the Patient ID value “12345” became “GH12345” when migrated from General Hospital’s PACS. This prefixing of patient ID values can be largely avoided if the destination system uses the DICOM attribute Issuer of Patient ID value (populated with the assigning authority value from the original ADT source) to keep each patient record managed within its own domain. The use of this attribute is still not supported in many PACS and even some VNAs, unfortunately.
The link between EMR and imaging records
In an enterprise where the EMR is expected to index and be aware of all of a patient’s records, including those stored in imaging systems, coercing the attribute values within imaging records without also updating or linking the values in the EMR can create issues when trying to access the records from the EMR, or its embedded RIS module.
Also, in many cases, the procedure information, which is often persisted in the DICOM attribute Study Description, was not updated as part of the migration, resulting in some PACS features that depend on the body part and other procedure-specific information to experience issues. Two common examples of PACS features that depend on this information are the rules that determine which of a patient’s prior exams are relevant for comparison with the current exam during diagnostic review, and display protocols (aka hanging protocols) that define the automatic layout and
placement of imaging data on the screen.
If the imaging archive (PACS or VNA) sends study content notifications for the migrated data to the EMR so that it can provide users with a link to the enterprise viewer (or PACS client), a variety of challenges may need to be solved.
First, some EMR configurations will not accept unsolicited results, and the study content notification (typically based on a modified HL7 ORU message) will appear as a form of result and cause an exception. In these cases there are two common approaches when migrating the data: an order using the accession number value from each study to be migrated is added to the EMR (often done as a bulk operation); or the study data must be updated with accession number values from the EMR. For EMR configurations that do accept unsolicited results, there are still other potential issues.
As the study content notification will include information on the performed procedure, which is often extracted from the DICOM attribute Study Description, the value presented within the EMR may differ from those used for exams that are ordered from the EMR. This inconsistency of descriptions can cause some user confusion or limit their ability to know which exam to open and view. As the values presented are extracted from DICOM data that was historically managed by a system other than the EMR, and may have been migrated more than once, or imported to the source system without any reconciliation to consistent values, what is presented can be quite different or limited.
