Patient data is a core asset to the healthcare organization. Yet it is often the case that data is not well maintained. Errors accumulate over time. Staff are often too busy to fix errors at the time of discovery. In the article Ten Things You Should Know When Embarking on Data Migration, the first two items are 1) Know your data and 2) Maintain your System and Your Data. Unfortunately, too often, data is not ready to migrate without some repair. The degree of repair needed may be unknown. The cost and time to discover and remedy data problems can be large.

Data quality is essential to a successful product transition. The challenges to adopt a new PACS, VNA, and connected IT are better understood than those of data quality. The latter is often overlooked. Planning and selection of vendors and products tends to be the primary focus. Pitfalls surrounding data fidelity and portability can be difficult to anticipate. Sometimes, data issues stem from the business need that necessitates the migration, such as in the case of an acquisition or merger. Poor metadata quality interferes with efficient data retrieval and hence to the workflow that depends on the data. Downstream costs can be high.

Fortunately, data remedies can be affordable in conjunction with the migration. The list below lists some problem scenarios:

Patient identity. Even ignoring operator and data entry errors, patient identity problems emerge. Patient identification was relatively simple with a single issuer of patient identifiers. The DICOM “Issuer of Patient ID” was not needed, and it is typically absent. Today, migrations update and reconcile patients from multiple sites and patient identity schemes. Using data such as HL7 ADT, ORU, and ORM RIS, patient merges and demographics corrections can reconcile patient studies and consistent with connected information systems.

Broken links. Products vary in how they link images, reports, and orders. Some depend on a single Study Instance UID or the Accession Number. These data dependencies can interfere with convenient access to the full set of images, reports, and related objects such as Presentation State and Key Objects. Remedies include merging all DICOM Studies to the order.

Missing context metadata. In the past, studies entered the archive of a single PACS. With the trend toward sharing and collaboration, today’s solutions serve more than a single specialty, department, or even institution. Provenance and context identifiers that were once unimportant are now critical in routine workflow of a more connected environment.

Nonconformant data is often recognized only after a product change. Some systems have more tolerance for DICOM Standard deviations than others. Examples include tag values that are overlength or stray from DICOM value representation constraints that originate from “bad actors” connected to the PACS.

Unwanted data. Migration is a good time to dispose of accumulated test images that clutter the archive. Retired products may leave behind data that no current product can interpret. Raw formats intended for research is proprietary, even when in a “private” DICOM SOP Storage Class. The lack of clinical need or a compatible product can justify excluding these from the scope of migration. Imported exams from other institutions may be outside retention policy. Purging studies outside retention policy saves storage and may ease data maintenance.

Proprietary dependencies. Archives now serve a growing scope of clinical specialties and data types beyond the core set of image types of early DICOM. DICOM and IHE integration profiles have expanded to accommodate this need. However, data in the archive is often in a proprietary, non-DICOM form such as: presentation state, annotations, key images, digital breast tomosynthesis, tech notes, reports, and other unstructured data. If not converted to a DICOM compatible format this data becomes unusable in replacement systems. See item 3 Beware of Dependencies on Proprietary Features in Ten Things You Should Know When Embarking on Data Migration.

Inconsistent product behavior. Because today’s product mix is more varied, vulnerability to product interoperability increases. Some DICOM implementations choose to use portions of DICOM standard that other products do not support. Product users may use certain features in ways not intended for product interoperability. As products change, data becomes vulnerable to compatibility problems, not necessarily because of deviations with standards, rather because product and workflow changes put new requirements on the data. Past assumptions are no longer valid.

For example, DICOM Presentation State has been used to correct image laterality by overwriting the laterality marker in the image with a text box with correct laterality. This annotation may obscure the incorrect laterality on some viewers, but other viewers may leave the text box transparent. Ambiguous laterality potentially affects patient safety. Even though the viewer can legitimately claim to comply with DICOM, annotation placement and size, may need modifications to be acceptable.

The migration project should include a validation plan to detect such problems. Acceptable display behavior is achievable with appropriate transformations. Use a migration vendor experienced with fixing these problems.

Workflow optimization strongly influences product selection. Normalizing study descriptions, procedure codes, and physician identity are a common need. Features such hanging protocols, display Presentation State windowing, annotations, and visualization features depend on normalized metadata. For example, viewers key on metadata values such as the Series and Study Description to choose the image display protocol that is optimal to the user’s clinical task.

Future dependencies. It is likely that your institution has plans for new products and capabilities that raise the bar on data requirements. Enterprise sharing with IHE Integration Profiles, data segmentation for privacy, and analytics are examples. Augmenting metadata during the migration may be cheaper than doing so later

If your migration project involves any of these scenarios, use a migration vendor who is experienced with them. Choose a vendor that uses established processes consistent with FDA Quality System Regulation and ISO Quality Standards. These emphasize planning, risk management, and validation.

Validate migrated data for usability on the replacement systems and with intended workflow. The plan should specify the sampling methodology to all modalities, data types, and transformation types with attention to site-specific needs. The site should provide input on risk and clinical need to ensure that the sample set is appropriate. Data types include images of each specialty, modality, presentation state, annotations, key objects, and reports. Qualified site staff must evaluate the equivalence of data for viewing, automatic prior retrieval, and other queries used in workflow. Validation should include each type of viewer in the product environment. The customer should evaluate the vendor’s validation plan to understand requirements and schedule.

Improving Data Quality can achieve goals of: compatibility with new products;u202fplannedu202fworkflow optimizations; expand access to more usersu202fwithin the enterprise to an enlargingu202fscope of data,u202fwhileu202fpreparing for new products and features based on emerging standards. The data migration project can be a convenient time to do this affordably.

Author Doug Sluis, PhD is a consultant on Quality & Interoperability for Laitek Inc. His experience includes software development, systems engineering, test automation, interoperability, industry standards for electronic medical records, and quality and regulatory compliance. Doug has spent decades developing and applying Standards (DICOM, IHE, coding systems) to enhance products and clinical information continuity within clinical workflow.