Complete Guide: Efficient Radiology PACS Setup and SIMRS Integration

Modern hospitals face complex challenges in managing patient data, especially in the radiology department. The ever-increasing volume of medical images, from X-rays, CT scans, to MRIs, requires a robust system for storage, access, and distribution. Without a Picture Archiving and Communication System (PACS) integrated with the Hospital Management Information System (SIMRS), medical staff are often hindered by manual processes, data loss, and long wait times. This not only impacts operational efficiency but also the quality of patient care and potential financial losses due to inefficiency. This article will guide you in depth on how to build and integrate radiology PACS with your SIMRS. We will discuss everything from solution selection, system architecture, data communication standards such as DICOM and HL7/FHIR, to concrete implementation examples with runnable code. The main goal is to empower hospital IT Managers, clinic owners, and decision-makers to implement solutions that are not only functional but also scalable and compliant with the latest industry standards.

Basic Concepts of PACS and Benefits of Integration with SIMRS

PACS is a medical imaging system that provides economical storage and easy access to images from various modalities (CT, MRI, US, X-ray, etc.). Modern PACS not only manages images but also patient metadata, radiology reports, and department workflows. Its main components include imaging modalities, communication networks (LAN/WAN), PACS servers for storage and database management, and diagnostic workstations. PACS servers generally use a client-server architecture, with relational databases such as PostgreSQL 16 or MySQL 8.0 for image and metadata indexing, and object storage such as Ceph or even local file systems for the DICOM image data itself. The main benefits of PACS are eliminating physical film, reducing operational costs, speeding up image access, and improving collaboration among doctors.

Integrating PACS with SIMRS is a crucial step to create a cohesive health information ecosystem. Without integration, patient information such as demographics, medical history, and examination orders must be manually entered into PACS, increasing the risk of errors and redundancy. Integration allows SIMRS to automatically send radiology examination orders to PACS (for example, via HL7 ADT/ORM messages), and PACS sends examination status or links to images back to SIMRS. This creates a seamless workflow: the doctor creates an order in SIMRS, the order is forwarded to PACS, the radiology technician performs the examination, the image is archived in PACS, the radiologist reads the image and creates a report in PACS, then the report is sent back to SIMRS to be accessed by the referring doctor.

Data communication standards are the backbone of this integration. DICOM (Digital Imaging and Communications in Medicine) is the global standard for handling, storing, printing, and transmitting information in medical imaging. Each radiology image is a DICOM object that contains not only image pixels but also patient metadata headers, examination type, modality, and many other relevant information. PACS communicates with imaging modalities and diagnostic workstations using the DICOM protocol. Meanwhile, for integration with SIMRS, the commonly used standards are HL7 (Health Level Seven) version 2.x or the more modern FHIR (Fast Healthcare Interoperability Resources) Release 4 or 5. HL7 v2.x is a long-standing and widely used messaging standard for exchanging administrative and clinical data, while FHIR offers a more modern and flexible RESTful API-based approach, ideal for web and mobile applications.

For example, when a doctor in SIMRS creates an abdominal CT Scan order for a patient named "Budi Santoso", SIMRS will generate an HL7 ORM (Order Management) message or FHIR ServiceRequest resource. This message is then sent to PACS. PACS will receive the message, create a new worklist entry, and when the radiology technician selects the order on the CT modality, the modality will query PACS to get patient and examination details (DICOM Worklist SCP). After image acquisition is complete, the image will be sent to PACS (DICOM Store SCP). After the radiologist reads and creates a report, the report can be sent back to SIMRS as an HL7 ORU (Observation Result) message or FHIR DiagnosticReport resource. This is a complete cycle that illustrates how essential good integration is for operational efficiency and data security.

Architecture and Technical Implementation of Integration

The PACS-SIMRS integration architecture generally involves several key components: SIMRS as the central patient management system, PACS as the image management system, and a middleware or integration engine as the communication bridge. This middleware is very important for transforming data between systems that may use different standards or formats. Examples of popular middleware include Mirth Connect (now NextGen Connect) which is Java-based, or custom solutions built using frameworks such as Node.js (with Express.js and TypeScript) or Laravel (PHP 8.2+). For the database, PostgreSQL 16.x is a highly recommended choice due to its stability, performance, and enterprise-grade features.

The integration process begins with understanding the clinical workflow. For example, when a patient registers in the SIMRS, their demographic information (ADT A04/A08 in HL7 v2.5.1) must be synchronized to the PACS. When a doctor creates a radiology examination request (ORM O01), this data must be sent to the PACS to populate the DICOM Modality Worklist (DMWL). After the examination is completed and the images are archived in the PACS, the examination status (e.g., "COMPLETED") must be sent back to the SIMRS. Finally, the radiology report (ORU R01 or FHIR DiagnosticReport) created in the PACS or RIS (Radiology Information System) must be sent to the SIMRS so that it can be accessed by the referring physician.

For DICOM communication, most PACS provide DICOM AEs (Application Entities) for Store (SCU/SCP), Query/Retrieve (SCU/SCP), and Worklist (SCP). You may need to configure the correct AE Title, IP Address, and Port on the modalities and PACS. For example, a Siemens Somatom Definition AS modality might be configured to send images to a PACS with the AE Title "PACS_ARCHIVE" at IP 192.168.1.100 port 104. On the SIMRS or middleware side, DICOM libraries such as DCMTK (C++), fo-dicom (.NET), or dcmjs (JavaScript) can be used to interact directly with the PACS if needed, although generally PACS provide higher-level APIs.

For HL7 v2.5.1 integration, you will need an HL7 listener on the middleware or SIMRS side that can receive messages via MLLP (Minimal Lower Layer Protocol) over TCP/IP. HL7 messages are typically sent via port 2575 or 2576. HL7 parsers such as HAPI FHIR (version 6.8.x for Java) or hl7.js (Node.js) are essential for parsing and validating the message structure. For FHIR R4/R5, integration involves RESTful API calls (GET, POST, PUT) to the FHIR Server. You can use HAPI FHIR Server, or build a custom FHIR endpoint with a framework such as Laravel 11.x connected to a PostgreSQL 16.x database, using a package such as laravel-fhir.

It is important to note that the implementation must consider data security aspects (HIPAA/PMK No. 24 of 2022) and performance. The use of secure connections (TLS/SSL) for data transmission between systems, encryption of sensitive data at rest, and strong authentication/authorization mechanisms are mandatory. Performance testing with high data volumes and failure scenarios should also not be overlooked. Ensure that your system can handle thousands of transactions per day without significant performance degradation, with an average response time of under 500 ms for critical transactions.

Example Code for HL7 and FHIR Integration Implementation

To demonstrate the integration, we will look at an example of how a SIMRS can send a radiology examination order to the PACS via middleware (using HL7) and how the radiology report can be accessed via FHIR.

First, let's look at an example of how the SIMRS sends an HL7 ORM O01 (Order Management) message to the middleware. This message contains patient information and details of the radiology examination order. The middleware will receive this message, parse it, and then forward it to the PACS or RIS.

MSH|^~&||SIMRS_APP|PACS_GATEWAY|PACS_APP|20231027103000||ORM^O01|MSG0001|P|2.5.1|||AL|AL||8859/1PID|||12345678^^^SIMRS^PI||SANTOSO^BUDI^^^MR||19800101|M|||JL. MERDEKA NO.10^^JAKARTA^DKI^10100^IDN||(021)1234567|||M|||9876543210PV1||O|RADIOLOGI^CT SCAN|||||DR.ANITA^ANITA^^^^MD|||||||||R01|||||||||||||||||||||||||20231027100000ORC|NW|ORD12345^SIMRS|||||||20231027102900|DR.ANITA^ANITA|||||RADIOLOGI||||||||OBR|1|ORD12345^SIMRS|EXAM789^PACS|CTABD^CT SCAN ABDOMEN^L999|||20231027103000|||||||||||||||||||F|||||||||

The HL7 message above is a standard representation of an order.

• MSH (Message Header) defines the message characteristics such as sender, receiver, and HL7 version (2.5.1).
• PID (Patient Identification) contains the patient's demographic data, including patient ID, name, date of birth, gender, and address.
• PV1 (Patient Visit) contains information about the patient visit, such as the service unit and the attending physician.
• ORC (Common Order) is the control segment for the order, indicating the order status (NW for New Order) and timestamp.
• OBR (Observation Request) details the requested examination, including the order ID, examination code (CTABD), and description.

The middleware that receives this message will parse each segment and field, validate the data, and then map this information into a format that the PACS can understand (for example, populating the Modality Worklist or creating a new database entry).

Next, let's look at how the SIMRS or another clinical application can retrieve the radiology report using FHIR. Suppose the report has been created in the PACS/RIS and archived as a DiagnosticReport resource on the FHIR Server.

// Example GET request to retrieve DiagnosticReport by patient ID// Using HAPI FHIR Client (Java) or cURL// Assume FHIR Server is running at http://localhost:8080/fhir// And the patient ID in FHIR is 'patient-budi-santoso'// With cURL:curl -X GET "http://localhost:8080/fhir/DiagnosticReport?subject=Patient/patient-budi-santoso&_sort=-date&_count=1" 
     -H "Accept: application/fhir+json"// With HAPI FHIR Client (Java):// IGenericClient client = new FhirContext(FhirVersionEnum.R4).newRestfulGenericClient("http://localhost:8080/fhir");// Bundle bundle = client.search()//     .forResource(DiagnosticReport.class)//     .where(DiagnosticReport.SUBJECT.hasId("Patient/patient-budi-santoso"))//     .sort().descending(DiagnosticReport.DATE)//     .count(1)//     .returnBundle(Bundle.class)//     .execute();// if (bundle.hasEntry()) {//     DiagnosticReport report = (DiagnosticReport) bundle.getEntryFirstRep().getResource();//     System.out.println("Radiology Report: " + report.getText().getDivAsString());// }

The cURL request above will retrieve the latest DiagnosticReport for the patient with ID patient-budi-santoso. The _sort=-date parameter sorts the results in descending order by date, and _count=1 limits the results to only one latest report. The response will be a FHIR JSON Bundle containing a DiagnosticReport resource with report details, including the result narrative (in DiagnosticReport.text.div), image references (in DiagnosticReport.media), and status. Using FHIR greatly facilitates integration with modern applications because it leverages the common RESTful web standards. This implementation ensures that doctors or medical staff can access radiology examination results in real-time from the SIMRS without needing to log in separately to the PACS system.

Example Payload, Error Handling, and Troubleshooting

Understanding the payload format and how to handle errors is key to successful integration. Let's look at an example FHIR DiagnosticReport payload representing a radiology report, followed by error scenarios and their handling.

{  "resourceType": "DiagnosticReport",  "id": "dr-ct-abdomen-budi",  "meta": {    "profile": ["http://hl7.org/fhir/StructureDefinition/DiagnosticReport"]  },  "status": "final",  "category": [    {      "coding": [        {          "system": "http://terminology.hl7.org/CodeSystem/v2-0074",          "code": "RAD",          "display": "Radiology"        }      ]    }  ],  "code": {    "coding": [      {        "system": "http://loinc.org",        "code": "42985-9",        "display": "CT abdomen"      }    ],    "text": "CT Scan Abdomen"  },  "subject": {    "reference": "Patient/patient-budi-santoso",    "display": "Budi Santoso"  },  "encounter": {    "reference": "Encounter/enc-budi-radiology"  },  "effectiveDateTime": "2023-10-27T11:00:00+07:00",  "issued": "2023-10-27T14:30:00+07:00",  "performer": [    {      "reference": "Practitioner/dr-anita",      "display": "Dr. Anita, Sp.Rad"    }  ],  "resultsInterpreter": [    {      "reference": "Practitioner/dr-anita",      "display": "Dr. Anita, Sp.Rad"    }  ],  "media": [    {      "comment": "CT Abdomen images",      "link": {        "reference": "Media/media-ct-abdomen-budi",        "display": "Link to DICOM image in PACS"      }    }  ],  "conclusion": "No significant abnormalities found in the abdominal organs.",  "conclusionCode": [    {      "coding": [        {          "system": "http://snomed.info/sct",          "code": "399068006",          "display": "Normal finding"        }      ]    }  ],  "text": {    "status": "generated",    "div": "<div xmlns="http://www.w3.org/1999/xhtml"><p><strong>ABDOMEN CT SCAN RESULTS</strong></p><p><em>Patient: Budi Santoso (1980-01-01)</em></p><p>The Abdomen CT Scan examination shows the organs within normal limits. No significant masses, lesions, or organ enlargement were found. There are no signs of effusion or ascites. Impression: Within normal limits.</p><p><em>Radiologist: Dr. Anita, Sp.Rad</em></p></div>"  }}

This FHIR DiagnosticReport payload comprehensively covers all aspects of a radiology report: status (final), category (Radiology), examination code (LOINC 42985-9), subject (Patient/patient-budi-santoso), examination time (effectiveDateTime), issuance time (issued), performing and interpreting physician (performer, resultsInterpreter), link to related images in PACS (media), conclusion (conclusion), and the complete report narrative in HTML format (text.div).

Error Scenarios and Handling: One common error in integration is "DICOM Association Rejected" or "HL7 Message NACK" (Negative Acknowledgement).Error Example: DICOM_ASSOCIATION_REJECTED: AE Title mismatch or unauthorized IP address.Cause: This occurs when a modality or workstation tries to connect to the PACS, but the AE Title sent is not registered in the PACS configuration, or the source IP address is not allowed by the firewall or PACS security configuration.Handling:

1. Verify AE Title: Ensure that the AE Title configured on the modality (for example, "CT_MODALITY1") is exactly the same as the one registered in the PACS. AE Titles are case-sensitive.
2. Check IP Address and Port: Ensure that the IP address of the modality or workstation is allowed in the PACS and is not blocked by the firewall on the network. Also ensure that the DICOM port (standard 104) is open and accessible. Use ping and telnet <PACS_IP> 104 from the modality to test basic connectivity.
3. PACS Log: Check the PACS server log for more detailed error messages. Logs often provide specific information about why the connection was rejected.
4. Security Configuration: Some PACS have a whitelist of IPs or AE Titles. Ensure that all communicating entities are properly registered.

Effective error handling involves detailed logging, retry mechanisms for temporary failures (for example, a brief network disconnection), and automatic notification to IT administrators if persistent errors occur. For HL7, a NACK response (for example, MSA|AE|MSG0001|Error processing message: Invalid Patient ID) indicates a data or validation problem. The sending system must be able to interpret this NACK and trigger a manual or automatic correction process. A robust implementation should include a monitoring dashboard to track transaction status and proactively identify bottlenecks or failures.

Best Practices in PACS-SIMRS Implementation

1. Conduct an In-Depth Needs Analysis: Before starting implementation, map the radiology and SIMRS workflows in detail. Identify all integration points, data exchanged, and performance expectations of each department to ensure that the solution built truly meets operational needs.
2. Choose PACS and SIMRS Solutions Based on Open Standards: Prioritize systems that natively support DICOM, HL7 v2.x, and FHIR R4/R5 standards. This will minimize future integration complexity and ensure interoperability with other systems in the healthcare ecosystem.
3. Use a Robust Integration Engine/Middleware: Consider using middleware such as Mirth Connect or building a custom solution with Node.js/Laravel to manage data transformation and message routing. This middleware acts as an effective enterprise service bus (ESB) for managing messages from various formats.
4. Implement Layered Data Security: Ensure that all communication between systems is encrypted using TLS/SSL. Implement strict authentication and authorization for access to PACS and SIMRS, and comply with patient data privacy regulations such as PMK No. 24 of 2022 concerning Medical Records.
5. Plan for Scalability from the Start: Consider future growth in image data and the number of users. Choose a PACS architecture that can be scaled (scale-up or scale-out) and adequate storage infrastructure, such as S3-based object storage or SAN/NAS with expandable capacity.
6. Involve All Stakeholders: Include radiologists, radiology technicians, referring physicians, IT staff, and management in every stage of the project. Their feedback is invaluable for ensuring that the implemented system is user-friendly and clinically efficient.
7. Perform Comprehensive Testing: Conduct unit, integration, and user acceptance testing (UAT) thoroughly. Test various scenarios, including high data volumes, error scenarios, and disaster recovery to ensure system stability and reliability.
8. Document Configuration and Workflows: Create clear technical documentation on the configuration of PACS, SIMRS, middleware, and integration workflows. This documentation is crucial for maintenance, troubleshooting, and onboarding new staff.
9. Implement Monitoring and Alerting: Set up a monitoring system to track PACS and integration performance, and to detect anomalies or failures. Configure automatic notifications (for example, via email or SMS) to the IT team if critical issues occur.
10. Plan a Backup and Disaster Recovery Strategy: Ensure that DICOM image data and PACS/SIMRS databases are backed up regularly to a separate location. Create a tested disaster recovery plan (DRP) to ensure service continuity in the event of a major system failure.

FAQ

Q1: What is the main difference between PACS and RIS?

A1: PACS (Picture Archiving and Communication System) focuses on medical image management, including storage, access, and distribution of DICOM images. Meanwhile, RIS (Radiology Information System) is an information system that manages the administrative and clinical workflows of the radiology department, such as patient scheduling, registration, result reporting, and billing. The two are often integrated or even combined into a single unified solution for maximum efficiency.

Q2: Do all radiology modalities support DICOM?

A2: Almost all modern medical imaging modalities (CT, MRI, digital X-ray, ultrasound, etc.) produced by major vendors such as Siemens, GE, Philips, and Toshiba already support the DICOM standard. However, it is important to always verify the DICOM conformance statement of each modality to ensure full compatibility with your PACS, especially for features such as DICOM Worklist SCP.

Q3: How important is FHIR in PACS-SIMRS integration today?

A3: FHIR (Fast Healthcare Interoperability Resources) is becoming increasingly important because it offers a modern and flexible RESTful API approach, ideal for integration with web and mobile applications. Although HL7 v2.x is still dominant for traditional message exchange, FHIR provides a more efficient way to access structured clinical data such as radiology reports (DiagnosticReport) and patients (Patient) from SIMRS to PACS or vice versa, supporting broader interoperability and the development of innovative healthcare applications.

Q4: How can patient data security be ensured during integration?

A4: Patient data security is the top priority. Ensure all data transmissions use secure protocols such as HTTPS/TLS for FHIR APIs and VPN/IPsec for HL7 MLLP connections. Sensitive data must be encrypted at rest and in transit. Implement strict role-based access control (RBAC), comprehensive audit trails, and routinely conduct penetration testing to identify and fix potential security vulnerabilities. Compliance with PMK No. 24 of 2022 on Medical Records is also mandatory.

Q5: What is the estimated time required to implement PACS-SIMRS integration?

A5: Implementation time varies greatly depending on the complexity of the existing SIMRS and PACS, the number of modalities to be integrated, and the availability of IT team resources. For a basic implementation, it may take 3-6 months. However, for a more comprehensive integration with advanced features, extensive testing, and customization, it can take 6-12 months or more. Careful planning and good project management are crucial for success.

Q6: What are the common challenges in this integration and how to overcome them?

A6: Common challenges include differences in interpretation of DICOM/HL7/FHIR standards between vendors, network and firewall issues, poor data quality from legacy systems, and resistance to change from staff. Overcoming them requires strong communication with vendors, rigorous interoperability testing, the use of middleware for data standardization, adequate staff training, and proactive management support. The IT team must be prepared to perform in-depth troubleshooting and collaborate closely with all relevant parties.

Integrating radiology PACS with SIMRS is no longer merely an option, but a necessity for modern healthcare facilities that want to improve efficiency, data accuracy, and the quality of patient care. By following this guide, from understanding basic concepts, choosing the right technologies such as PostgreSQL 16 and FHIR R4, to implementing code and error-handling strategies, you can build a robust and interoperable system. Remember that the success of this project depends heavily on careful planning, selecting standards-compliant solutions, and a commitment to data security. If you need further assistance in designing, developing, or implementing a PACS-SIMRS integration solution tailored to the unique needs of your hospital or clinic, do not hesitate to contact Nugroho Setiawan. We are ready to help you achieve operational efficiency and higher healthcare service standards through innovative and proven technology solutions.

This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: SIMRS (Hospital Information System) Clinic Management System SatuSehat Integration. Need a free consultation?