Custom RIS software development
A radiology information system (RIS) manages the administrative and logistical side of imaging: the request, scheduling by modality and time slot, the technologist's worklist and the report. Appfront builds software for radiology departments and imaging institutes. Usually that is not a complete RIS, but a module or integration around the existing package, at the point where your process deviates from what the vendor supplies. Where a standard package is the better fit, we'll say so.
What a RIS does, and where it stops
The RIS is the administrative and logistical system of radiology. A request arrives from the hospital information system (ZIS) or EHR, receives an accession number, is scheduled on a device and time slot, appears on the technologist's worklist and ends in an authorised report. The PACS manages the images themselves and the viewer in which the radiologist reviews them. They are separate systems with separate contracts. In the Netherlands the RIS is often a module within the EHR, for example in HiX from ChipSoft, or a standalone package from a vendor such as NEXUS.
This page is about software for the radiology process: scheduling, worklists, integrations and reporting. If you are looking for broader software for a care organisation, such as a client portal or a register outside radiology, see building care software. If your software performs a clinical function itself, such as image analysis, the Medical Devices Regulation applies and you should look at medical device software. Software around the RIS usually falls outside that scope, but the line is a fine one.
The RIS: process and administration
Orders, scheduling, accession numbers, worklists and the reporting flow. Everything around the examination, except the images themselves.
The PACS: the images
Storage, distribution and presentation of DICOM images, with the diagnostic viewer. The PACS knows nothing about scheduling.
The hospital information system (ZIS) or EHR: the patient
Identity and the request itself. Supplies the order to the RIS and receives the report back via HL7 messages.
Where things go wrong in practice
The questions departments bring to us rarely concern a missing feature, but rather the points where process and system come apart.
Scheduling multiple scarce resources at once
Scheduling a radiology appointment is not a single choice but a set of conditions that must all be satisfied at the same time. The examination requires a specific modality and sometimes a specific device within it, because a protocol cannot run on every MRI scanner. It requires a time slot that suits the type of examination: an MRI usually occupies the scanner for half an hour or longer, a chest X-ray is finished in a few minutes, and the same examination with contrast takes longer than without. Sometimes the patient needs preparation, such as fasting or a laboratory result that must be available first. And for some examinations, a person with the appropriate authorisation must be available, for example for contrast administration or an intervention.
A schedule is only valid when the scanner, time slot, staff and preparation all line up at once. Software that treats these as separate fields pushes the puzzle onto the planner, who then keeps a separate overview alongside it. That overview becomes the real scheduling system.
No-shows and emergencies disrupt every schedule
No radiology schedule survives the day intact. A patient doesn't turn up, an urgent case from the ED needs squeezing in, a machine breaks down, or an examination overruns because the images aren't good enough. A system that only plans ahead but can't reschedule is practically useless. Seeing which slots have freed up, knowing who can cover, and contacting a patient without a round of phone calls is at least as valuable as the schedule itself. In an emergency, it must be immediately clear what later in the day will be affected.
The modality worklist is not a technical detail
The connection between the RIS and the modality runs via the DICOM modality worklist. The device queries the RIS with a C-FIND and receives the scheduled examinations back: patient details, accession number and the description of the procedure. The technologist selects the patient from that list, and the data flows unchanged into the images.
If the integration fails, nothing changes in the waiting room: the patient is in front of the machine and the examination goes ahead. The technologist then types the details into the console by hand, and that is where the damage occurs. A mistyped patient number, an accession number off by a single digit or a different spelling of a name results in images attached administratively to the wrong patient. The PACS accepts those images without question; the error only surfaces when the report cannot be linked to them, and sometimes not at all.
Correcting this afterwards is laborious and compromises the integrity of the record. The worklist is not simply a list: it is where the identity of the examination is established. The IHE profile Scheduled Workflow describes how that chain should run, from order through worklist to storage in the PACS.
Reporting is the bottleneck, not imaging
Turnaround time is mostly determined by how long an image waits for assessment. A worklist that shows examinations in order of arrival leaves the radiologist to search for what is urgent. Prioritisation then happens by instinct, or by whoever phones the hardest.
Prioritising requires more than copying an urgency flag from the request. It depends on the combination of clinical urgency, the waiting department, the subspecialty of the radiologist available, whether the examination follows up earlier imaging, and whether a deadline is at risk of lapsing. The gain often lies not in a cleverer algorithm but in visibility: what has been open too long, and how does incoming volume compare with reporting capacity? The Dutch Society of Radiology points out in its guidance on capacity planning that radiology is often underrepresented in hospital-wide capacity agreements.
The honest trade-off: don't build a complete RIS
We build custom software, yet our advice here is: don't build a complete RIS. The process is highly standardised, the packages are deeply intertwined with PACS vendors and with the HIS or EHR, and there is no competitive advantage in a bespoke version of something that works the same everywhere. You would also be bringing in the management and continuity of a core system, in an environment where your auditor will check it.
An off-the-shelf package is the better choice when your process broadly follows the usual pattern, when you want the chain kept with a single supplier, and when you have no organisation to carry functional management. That applies to most departments, and it is no sign of weakness.
Custom development earns its keep at the edges: where your package stops, or where you deliberately work differently. Such add-ons are smaller and carry less risk, and you can switch them off without radiology grinding to a halt.
Situations in which custom development does make sense
- No appointment module that suits your patient group
- Two systems without an integration the vendor will build
- Management information the RIS doesn't produce in the format you need
- A missing registration for quality, research or dose
- A referral route that differs from the standard model
- An essential feature that isn't on the roadmap
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Where custom development around the RIS is worthwhile
Four solutions come up most often. They don't replace the RIS, but they complement it.
An appointment module for patients
Patients can book or reschedule themselves, but only within the department's rules: slots tied to the examination type, with the correct preparation instructions. If an appointment is cancelled, the slot is released immediately.
An integration between systems that don't know each other
A referring practice, an independent institute or a research database outside your chain. We build the integration on the HL7 and DICOM services your vendors support, with logging that shows when a message fails to arrive.
Management information on turnaround times and capacity
Waiting time per examination type, utilisation per scanner, overrun, no-shows and the time to an authorised report. Built on what the RIS and PACS already record, so every figure remains traceable.
A registration the package doesn't support
Dose data to check against diagnostic reference levels, a quality or complication register, or a dataset for research. The information is often there, but not in the form you need to submit it.
Standards, norms and integrations
In radiology, orders and reports travel over HL7 v2. A request arrives as an ORM or OMI message, the report goes back as an ORU message, and the accession number in the OBR segment keeps the order, procedure, images and report linked together. Towards the scanners, the standard is DICOM: the modality worklist for scheduled examinations, Modality Performed Procedure Step for reporting that an examination has started or finished, and storage commitment for handing over to the PACS.
In the Netherlands, NEN 7510 is the sector standard for information security in healthcare; since December 2024 it has appeared as NEN 7510-1:2024 and NEN 7510-2:2024. NEN 7513 covers logging of file access. Under the Electronic Data Exchange in Healthcare Act, image availability is becoming mandatory step by step: images and reports must be digitally available to the next treating clinician, with NEN 7541 as the implementation standard.
If your software goes further than storing and searching, for example by prioritising examinations on clinical grounds, the Medical Devices Regulation becomes relevant. Ask that question at the outset: see our page on medical device software.
Frequently asked questions about RIS software
The RIS manages the process and administration: the order from the HIS or EHR, scheduling by modality and time slot, the accession number, the status of the procedure and the report. The PACS manages the images themselves and the viewer in which the radiologist reads them. They are connected via HL7 and DICOM, but remain separate systems.
Usually not. The domain is highly standardised, the packages are deeply integrated with PACS vendors and with the HIS or EHR, and a department gains little from a bespoke version of something that works the same everywhere. What does pay off is custom work around the existing RIS: a scheduling module, a missing integration, management information or a record the package doesn't support.
That is the starting point for almost every assignment. Orders and reports usually travel via HL7 v2, where ORM or OMI messages carry the request and ORU messages return the report, with the accession number in the OBR segment as the key. Towards the devices, the standard is DICOM: modality worklist, Modality Performed Procedure Step and storage commitment.
That depends on what the software does. Storing, forwarding, archiving and searching fall outside Regulation (EU) 2017/745. Once software goes further, for example by prioritising studies on clinical grounds, qualification as a medical device comes into play. If a healthcare organisation builds a device for its own use, the in-house exemption of Article 5(5) applies.
Radiology data is special category personal data. NEN 7510 is the sector standard for information security in healthcare; in December 2024 NEN 7510-1:2024 and NEN 7510-2:2024 were published, aligned with ISO/IEC 27001:2023. Certification against the previous version remains possible under accreditation until 20 February 2027. NEN 7513 covers logging of file access.
You own the source code, the documentation and the environment. We document interfaces, message formats and configuration so that another party can take over. This matters even more here: your RIS and PACS vendors have their own release calendars, and the layer around them has to stay maintainable.
Related services
Building healthcare software
Bespoke software for healthcare organisations beyond radiology: portals, intake and treatment processes, scheduling and registrations, subject to the same NEN 7510 requirements.
Developing medical device software
For software that performs a clinical function itself and therefore qualifies as a medical device under Regulation (EU) 2017/745, including the documentation obligations.
Discuss your RIS question
Tell us which part of the radiology process is stuck: scheduling, the worklist, the reporting flow or after-the-fact accountability. We will first check whether your current package can solve it. If not, we will outline which layer around it is worthwhile and what that requires in terms of management.