PACS Integration for Research: Architecture, Privacy and Workflow

PACS integration for research means connecting the picture archiving and communication system that holds clinical images to the systems researchers actually work in: the EHR, the RIS, electronic data capture, de-identification tools and analysis environments. Done well, it gets the right images to the right study team, stripped of identifiers, without USB sticks or manual exports. This guide explains how the pieces fit, which standards matter, how to protect privacy, and how to plan the work.

TL;DR

• A research PACS is usually not one product. It is a set of cooperating applications that store and retrieve images through a common interface, kept separate from the clinical record.
• Orders, images and reports travel between EHR, RIS and PACS over HL7 and DICOM, and FHIR and DICOMweb increasingly handle web-native exchange.
• De-identification, IRB-approved access and audit trails belong in the design from day one, not as a final step.
• Most trial pain comes from images and study data living in separate systems. Closing that gap removes manual detours, errors and delays.
• We at KoHealth Labs pair laboratory and radiology data with EMR integration and regulatory-aligned delivery for research teams.

What a research PACS is and how it differs from a clinical PACS

A clinical PACS exists to support patient care: radiologists read studies, report them and send results back to the ordering physician. A research PACS serves a different master. Investigators need to query many studies, group them by protocol, remove identifiers and export them to analysis tools.

A research PACS, as described in RadioGraphics, combines the advantages of the clinical and research models of data access while avoiding the disadvantages of each. The authors describe it as independent applications that store and retrieve data in a common database rather than one monolithic program. Their argument is practical: no single application can satisfy the varied and fast-changing needs of imaging research, so the focus should be interoperability among existing systems through a unified interface.

Institutions put this into practice in different ways:

• The Research Imaging Core at Brigham and Women’s Hospital maintains a Research PACS that mirrors the clinical PACS functions while keeping research subject data separate from the clinical medical record number system, from scheduling through image acquisition and data management, in line with IRB protocols.
• UT Southwestern in Dallas runs a HIPAA-compliant PACS for clinical and preclinical research imaging that can apply customized de-identification to images acquired in clinical trials.

The common thread is separation. Research data sits in its own environment, with its own identifiers, fed from the clinical side through controlled channels.

How PACS connects to the EHR, RIS and research systems

Before you can design a research connection, it helps to see the clinical flow it taps into. A review of imaging informatics concepts walks through it:

1. A physician places an imaging order in the EMR.
2. HL7 messages carry the order to the RIS.
3. The RIS sends order details to the scanner through the DICOM Modality Worklist.
4. The modality sends images to the PACS using DICOM transactions.
5. The radiologist’s report returns to the RIS and EMR through HL7.

The Society for Imaging Informatics in Medicine covers the same loop, including VNAs and data warehouses, in its webinar How Clinical Data Moves. It stresses that infrastructure design affects data integrity, workflow reliability, analytics capability and AI readiness.

Research integrations branch off this loop at several points:

Emory’s radiology informatics group offers a concrete example. Its published pipeline pulls EHR data into a local database and refreshes labs, orders and medications every 30 minutes through REST APIs. A separate framework moves DICOM images from PACS to research environments on demand, and data is deleted nightly from the research cluster after processing.

The ACR’s AI-LAB reference architecture shows the same idea for machine learning. It describes a connected workflow layer that moves images and metadata between an AI environment and PACS, RIS, VNA, EMR and DICOM routers.

Standards that make integration work

Multi-vendor environments only work when everyone speaks the same languages. A technical guide on integrating lab and imaging systems with the EHR lists the layers high-performing architectures combine:

• HL7 v2 for registration, orders and results.
• HL7 FHIR resources such as ServiceRequest, Observation, DiagnosticReport and ImagingStudy for modern API exchange.
• DICOM for image transport and storage, plus DICOMweb for REST-style, web-native access.
• IHE profiles such as Scheduled Workflow, Invoke Image Display and ATNA, which make multi-vendor projects more predictable and testable.

Which messaging approach fits your study is its own decision. Our walkthrough of HL7 versus FHIR tradeoffs and hybrid patterns explains when each wins and how teams combine them.

The same guide frames the goal well: the point is closing the diagnostic loop, so an order placed in the EHR is executed in the departmental system and the result returns to the patient record with correct identity, context, terminology, security and auditability. For research, add one more requirement: every study must also be traceable to a study subject without exposing the patient.

A useful standards habit is to write down, for each interface, three things: the message or object type, the identifier that links records, and who owns correcting an error. Teams that do this early rarely discover mismatched patient IDs during database lock.

Privacy, consent and de-identification

Images carry identifiers in two places: the pixel data (burned-in annotations) and the DICOM header. Both need a plan. De-identification is also the step where research value is most easily lost, so it deserves careful design. We cover the details in how to de-identify DICOM files without losing research value and the regulatory side in two HIPAA paths for data de-identification.

Several published designs show where the controls can sit:

• A gatekeeper in front of the research archive. The open-source Research Information System from Norway uses a gatekeeper component as the only way data enters the research PACS. Studies are forwarded from a scanner or clinical PACS, a transfer is requested, and data is pseudonymized before it moves on.
• Approval-gated retrieval. Columbia’s Flywheel imaging service retrieves images from PACS and VNA with standard and custom de-identification profiles. Users need an approved IRB protocol and an approved request listing accession numbers.
• Self-service export. AWS’s research-pacs-on-aws sample targets the old one-time manual export on a USB stick or shared drive, which carries privacy and compliance risk. It offers a portal to browse, query and export DICOM to cloud storage, with de-identification rules defined in a configuration file.
• Built into the trial system. A German proposal for PACS-integrated data capture links an EDC system, a PACS and a DICOM viewer, and protects privacy through automatic de-identification and relabelling with study identifiers.

Where the de-identification happens matters too. A study of de-identification in an XDS environment found three possible locations: at the document source, between source and consumer, or at the consumer. It concluded that the source has more advantages, while doing it at the consumer carries the highest risk of exposing patient identity.

A practical access checklist:

• Confirm IRB approval or an exemption determination before any image leaves the clinical environment.
• Use accession numbers or study-subject lists, not open-ended searches, to define what is retrieved.
• Log every query, retrieval and export.
• Keep the key linking study IDs to patients outside the research environment, with a named custodian.
• Test de-identification on a sample, including burned-in text, before running a full batch.

Security of the surrounding infrastructure matters as much as the PACS. If your pipeline feeds analysis or AI tools, enterprise AI security practices are worth reviewing alongside your HIPAA safeguards.

Common challenges and how to avoid them

The most cited problem in trials is that images and study data live apart. The German EDC and PACS paper notes that electronic data capture systems lack a structured way to manage DICOM data or connect to a PACS, and that manual detours in trial workflows lead to errors, delays and costs.

Other patterns show up repeatedly:

• Identity mismatches. The EHR, RIS and PACS may hold different patient identifiers or name formats. Reconcile them before research linkage, not after.
• Inconsistent metadata. Series descriptions and protocol names vary across scanners and sites. Without normalization, cohort queries miss studies.
• Over-aggressive de-identification. Removing too many header fields can erase acquisition parameters that analysis depends on. Define a keep-list per study.
• Unmonitored quality. Images that arrive are not necessarily usable. Our guide to radiology data QC for research teams covers automated checks and audit scripts.
• Late imaging decisions. If imaging is added after the protocol is final, integration becomes a patch. See our trial designer’s guide to integrated radiology.

Extending PACS itself is also an option. One PACS-based processing tool uses scripts layered on the standard DICOM Query/Retrieve scheme to decrypt, convert, anonymize and process data, then publish results back to the PACS. That is useful proof that you can add research functions without replacing the clinical system.

A step-by-step plan for a research PACS integration

1. Define the research questions and data needs. List modalities, sequences, timepoints and the clinical or lab data that must link to each image.
2. Map the systems. Document the EHR, RIS, PACS, VNA, EDC and analysis environments, their vendors, versions and supported interfaces (HL7, FHIR, DICOM, DICOMweb).
3. Choose the integration pattern. Prospective trials often forward from the scanner or PACS through a gatekeeper. Retrospective studies usually query by accession number.
4. Design identity and de-identification. Decide on study IDs, the linking key, header keep-lists and handling of burned-in text, and where de-identification runs.
5. Set governance. Align with the IRB, privacy officer and security team on who may request, approve, retrieve and export data.
6. Build and test with sample data. Check message flow end to end, including error cases such as duplicate studies or corrected reports.
7. Add quality control and monitoring. Automate checks on completeness, header consistency and image quality.
8. Document for audit. Keep interface specifications, configuration, access logs and change history ready for sponsors and regulators.

Plan for timelines by testing early. Interface work with hospital IT often takes longer than the research team expects, so involve IT in step 1, not step 5.

Perspective: why we treat imaging and lab data as one stream

We see the same pattern in nearly every research conversation: the images are in one place, the lab results in another, and a coordinator spends hours reconciling them. That manual reconciliation is where errors and delays begin.

Our approach is to treat laboratory and imaging data as a single, analysis-ready stream. We designed our services around integrated laboratory diagnostics and radiology, with EMR integration, courier specimen pickup, a provider portal and regulatory-aligned data delivery, so study teams are not stitching together separate vendors.

We also believe privacy belongs at the front of the pipeline. De-identification, access control and quality checks are easier to get right when they are designed with the data flow, and that is how we work with CROs, sponsors and research sites.

The science in this field keeps moving, and that is encouraging. Standards like FHIR and DICOMweb are making connected research more achievable for teams of every size, and we want to help you use them well.

Kohealth Labs

How KoHealth Labs supports integrated research data

If your study needs laboratory results and imaging delivered together, we can help. Our services span lab testing across 100+ biomarkers, genomics and imaging, with bundled lab and radiology data designed for clinical research, plus onboarding and training for your team.

See our integrated clinical diagnostics for CROs and pharma to learn what we test, or start from kohealthlabs.com to talk with us about your protocol.

FAQ

Is a research PACS a separate system from the clinical PACS?

Usually it is a separate environment fed from the clinical PACS. Institutions such as Brigham and Women’s keep research subject data apart from the clinical record while mirroring clinical PACS functions. This protects patients and lets researchers use study identifiers instead of medical record numbers.

Which standards should I ask for in a PACS integration?

Expect DICOM for images, HL7 v2 for orders and results, and FHIR for API-based exchange. DICOMweb helps with web-native access, and IHE profiles make multi-vendor projects easier to test. Your study design determines which you need first.

Where should de-identification happen?

Published work on XDS environments favors de-identifying at the source, before images travel to the consumer. Many institutions also use a gatekeeper that pseudonymizes data before it reaches the research archive. Whichever you choose, test it on sample studies, including burned-in text.

Do researchers need IRB approval to get images from PACS?

Academic centers such as Columbia require an approved IRB protocol and a request listing study accession numbers before retrieval. Your own institution’s IRB and privacy officer set the rules for your study, so involve them before any export.

Can I use a retrieval pipeline for AI research on PACS data?

Yes, many teams do. The ACR AI-LAB architecture describes moving images and metadata between PACS and AI environments. If you are designing the data layer, retrieval pipeline design offers one perspective on structuring access to large document stores.

Sources

• Informatics in Radiology: Development of a Research PACS
• Brigham Research Imaging Core, Mass General Brigham
• PAAICI: Radiology, UT Southwestern
• A Review of Core Concepts of Imaging Informatics
• How Clinical Data Moves, SIIM webinar
• Radiology clinical trials pipeline, Emory School of Medicine
• AI-LAB Reference Architecture, ACR
• Integrating LIMS, RIS, and PACS With EHR Systems
• Research Information System, MMIV
• Flywheel Service, Columbia CIMBID
• research-pacs-on-aws
• DICOM for Clinical Research: PACS-Integrated Electronic Data Capture
• Image De-Identification Methods for Clinical Research in the XDS Environment
• Extending PACS Functionality
• Securing AI at the Enterprise Level
• RAG Pipeline: How to Build One

For more information about our diagnostic testing, clinical research laboratory services, or partnership opportunities, visit https://kohealthlabs.com or contact KoHealth Labs at (469) 792-8439 and ask for Amy Patterson.