Written by Technical Team | Last updated 23.07.2026 | 27 minute read
Radiology does not operate as an isolated department. Every imaging examination depends on information moving accurately between multiple systems: the patient must be identified, a clinical request must be received, the examination must be scheduled, the modality must know what to perform, images must reach the correct archive, a radiologist must be able to report them, and the authorised result must return to the clinicians responsible for the patient.
Magentus CRIS, sits at the centre of this process. As a Radiology Information System, it manages the operational and clinical workflow surrounding diagnostic imaging. It is not simply an appointment-booking application or a database of reports. In a properly integrated environment, the RIS acts as the workflow co-ordinator between the hospital’s Electronic Patient Record, Patient Administration System, order communications platform, Picture Archiving and Communication System, imaging modalities and numerous specialist clinical applications.
The quality of a Magentus CRIS integration therefore affects much more than technical connectivity. It determines whether demographic information remains consistent, whether imaging requests are visible to the right teams, whether scanners receive accurate worklists, whether images are associated with the correct examination, and whether reports are delivered without delay. A well-designed integration creates a continuous digital pathway from referral to diagnosis. A weak integration introduces duplicate records, manual transcription, mismatched studies, missing reports and clinical risk.
Understanding how Magentus CRIS integration works requires looking beyond individual interfaces. Each connection forms part of a wider workflow in which systems have distinct responsibilities, identifiers must remain aligned, and every significant change must be communicated. The objective is not merely to make applications exchange messages. It is to ensure that they behave as a coherent clinical ecosystem.
Key point: Successful Magentus CRIS integration is not simply about connecting software. Reliable RIS, PACS and EPR integration must preserve patient identity, order details, accession numbers and examination status across HL7 interfaces, DICOM modality worklists, imaging systems and reporting workflows. When these elements remain aligned, radiology teams can reduce manual data entry, prevent mismatched studies and deliver authorised reports to clinicians more quickly and safely.
Magentus CRIS normally occupies the operational centre of the imaging pathway. The EPR or an electronic requesting system may initiate the process, while the PACS stores and presents the resulting images, but the RIS manages the activities that transform a clinical request into a completed and reported examination. These activities can include referral receipt, vetting, protocol selection, scheduling, patient preparation, attendance, examination status, reporting, verification, communication and performance analysis.
This position is important because radiology workflows contain more state changes than a simple request-and-result exchange suggests. An imaging request may be accepted, rejected, redirected, amended, prioritised, placed on hold or divided into multiple procedures. A scheduled examination may be moved between sites, modalities or resources. A patient may fail to attend, arrive unexpectedly or require a different protocol after clinical review. A study may be partially completed, abandoned or repeated. A preliminary report may later be replaced by an authorised report or supplemented by an addendum. The RIS must represent these events in a controlled way and ensure that relevant systems receive the correct updates.
Responsibility for data should be explicitly defined before integration work begins. In many NHS environments, the Patient Administration System or master patient index is the authoritative source for core demographic information. The requesting system or EPR is responsible for the clinical order. Magentus CRIS becomes authoritative for radiology scheduling, attendance, examination workflow and reporting status. PACS is generally authoritative for the imaging objects it stores, although it depends on identifiers and workflow information supplied by upstream systems.
A typical division of responsibility may resemble the following:
This separation does not mean that information appears in only one application. Patient demographics, order details, accession numbers and examination descriptions must be replicated across several systems. The distinction is that one source should remain authoritative for each type of data. Other systems consume, display and use that information without independently redefining it.
An integration engine is often placed between Magentus CRIS and the surrounding clinical systems. This engine may receive messages, transform values, map local codes, route transactions, manage acknowledgements and retain audit information. It can reduce the number of direct point-to-point connections, particularly where several hospitals, EPRs, PACS platforms or specialist systems are involved. However, an integration engine does not remove the need for clear ownership. Poorly governed middleware can merely distribute inconsistent information more efficiently.
The architecture must also distinguish between clinical data and workflow signals. A patient update is not the same as an imaging order, and an imaging order is not the same as an examination-status notification. Similarly, a final report is not merely a document attachment; it has a patient context, an order relationship, an authorisation status, an author, a timestamp and potentially an addendum history. Reliable integration preserves these meanings rather than reducing every exchange to unstructured text.
The relationship between Magentus CRIS and PACS is one of the most important parts of the radiology architecture. Although the two systems are often discussed together as “RIS/PACS”, they perform different functions. The RIS manages the examination workflow and report lifecycle, while PACS stores, retrieves and displays medical images. Effective integration allows a user to move between these functions without repeatedly searching for the same patient or manually matching an image study to an order.
When a request is accepted and scheduled in Magentus CRIS, the system creates or maintains the identifiers needed to track the examination. One of the most significant is the accession number. This identifier links the radiology order and examination record to the imaging study that will eventually be stored in PACS. The exact rules vary by deployment, but the accession number should be unique within the agreed operational scope and should remain stable throughout the relevant workflow.
Magentus CRIS can make scheduled examination information available to modalities through a DICOM Modality Worklist service or through a worklist component connected to the RIS. Instead of a radiographer manually typing the patient’s name, identifier, examination description and accession number at the scanner console, the modality queries the worklist and presents the scheduled procedures that apply to it. The radiographer selects the correct entry, allowing the modality to populate the image metadata automatically.
This process is essential to data quality. DICOM images do not exist as anonymous pictures. Each image carries metadata describing the patient, study, series, equipment and acquisition. If staff manually enter this information, even a small typographical difference can cause the study to be associated with the wrong patient, appear as an unmatched examination or require intervention by PACS administrators. A worklist-driven process reduces transcription and keeps the image study aligned with the RIS record.
The workflow normally includes several related technical events:
Modality Performed Procedure Step, usually abbreviated to MPPS, can provide information about what happened at the acquisition device. It can indicate that a procedure is in progress, completed or discontinued and can describe the performed series. The extent to which this information drives RIS status varies between implementations. Some organisations rely heavily on modality-generated workflow events, while others require radiographers to complete or validate the examination in Magentus CRIS. The safer design is usually one in which automated signals reduce effort but do not create clinically significant state changes without appropriate validation.
The requested procedure and the performed procedure are not always identical. A request may ask for one examination, but the radiographer or radiologist may determine that a different protocol, additional series or an alternative modality is clinically required. The integration must support this reality without losing traceability. The system should preserve what was originally requested, what was scheduled, what was actually performed and what was reported.
Once the images reach PACS, the reporting workflow depends on tight contextual integration. A radiologist viewing a worklist in Magentus CRIS should be able to open the correct study in PACS without searching again. This is commonly achieved through context launching, shared identifiers or vendor-specific integration. The reverse may also be supported, allowing a radiologist working in PACS to open the corresponding examination or reporting screen in the RIS.
Good context integration must use more than a patient identifier. Opening a patient is not necessarily the same as opening the correct imaging study. A patient may have dozens of historical examinations, multiple studies from the same day or separate imaging events with similar descriptions. Wherever possible, the launch should use the accession number, study identifier or another examination-specific reference so that the radiologist is taken to the intended study.
Prior imaging is also part of the workflow. The RIS may identify previous examinations through the patient record, while PACS provides access to historical images. In multi-site organisations, relevant priors may reside in another PACS, a vendor-neutral archive or an image exchange platform. The integration should allow these studies to be discovered and made available before reporting, rather than forcing clinicians to search separate systems or wait until a discrepancy is noticed.
Reporting often takes place across both Magentus CRIS and PACS. The radiologist views images within PACS but creates the report within the RIS, sometimes using integrated speech recognition. Context must remain synchronised as the radiologist moves through a worklist. When the next examination is selected, the reporting screen, image viewer and any relevant clinical-information pane should all advance to the same case.
This synchronisation becomes more complex when several diagnostic displays, advanced visualisation applications or artificial-intelligence tools are involved. A CT study might be opened simultaneously in the main PACS viewer, a three-dimensional post-processing platform and an AI analysis application. The workflow should prevent one application from remaining on the previous patient while another advances to the next. Visible patient banners and deliberate context validation remain important safeguards even in a highly automated environment.
PACS integration also needs to handle corrections. If patient demographics are amended after images have been acquired, the RIS, PACS and image metadata may no longer agree. Organisations need a controlled reconciliation process capable of updating patient identity while preserving an audit trail. Similarly, if images were acquired under the wrong worklist entry, a formal study-correction workflow is required. Silent database changes or ad hoc edits create risk because they can break the relationship between the images, order and report.
The technical success of RIS–PACS integration should therefore be judged by end-to-end workflow, not simply by whether images can be transmitted. A functioning DICOM connection proves that one application can send data to another. It does not prove that the correct patient was selected, the study matched the correct order, the reporting worklist updated, the examination launched in context or subsequent corrections were propagated safely.
Integration between Magentus CRIS and the EPR begins with patient identity. Before an imaging request can be processed safely, the RIS must know which patient it belongs to. In many organisations, demographic and encounter information is sent from the PAS or EPR using HL7 admission, discharge and transfer messages. Despite the name, ADT messaging covers a broad range of patient-administration events, including registration, demographic amendment, admission, transfer, discharge, patient merge and record correction.
The receiving interface must translate the identifiers and data structures used by the source system into values understood by Magentus CRIS. This involves more than mapping a patient’s name and date of birth. It can include the NHS number, local hospital numbers, identifier assigning authorities, previous identifiers, sex, address, postcode, telephone number, general practitioner, consultant, ward, clinic and encounter details.
Identifier governance is particularly important in organisations operating across multiple hospitals. Two sites may use overlapping number ranges or assign separate local identifiers to the same person. An integration that treats the identifier value without its assigning organisation can incorrectly combine patients or fail to recognise an existing record. For this reason, the interface design should represent both the identifier and the domain that issued it.
Patient merges require special care. A merge normally occurs when duplicate records are discovered and one identifier is retired in favour of another. Magentus CRIS, PACS and connected systems must all understand which record survives and which becomes obsolete. If the RIS merges two records but PACS does not, images may remain distributed across separate patient folders. If PACS merges first without corresponding updates elsewhere, a radiologist could view images under a patient identity that does not match the report.
An imaging pathway usually starts with an electronic request created in the EPR, order communications platform or specialist clinical system. The request should contain enough structured information for radiology to assess and perform the examination. Relevant data may include the requested procedure, clinical question, symptoms, provisional diagnosis, urgency, referrer, responsible consultant, patient location, mobility requirements, infection risks, pregnancy information and answers to modality-specific safety questions.
The incoming request is transformed into a radiology order within Magentus CRIS. Local procedure codes may need to be mapped to RIS examination codes. This mapping is rarely one-to-one across an entire organisation. A broad request such as “MRI knee” may need to be translated according to laterality, contrast requirements, site capabilities and local protocol. Conversely, several highly specific EPR request options may be consolidated into a smaller set of RIS procedures before vetting.
A robust interface preserves the original request as well as the mapped result. Radiology staff need to know what the clinician actually asked for, even when the RIS uses a different internal code. This supports clinical interpretation, dispute resolution, audit and future optimisation of the request catalogue.
After receipt, the request may enter a vetting or justification workflow. A radiologist, radiographer or other authorised practitioner reviews whether the examination is appropriate, determines the protocol, assigns priority and may request additional information. Integration should not assume that every submitted order immediately becomes a scheduled examination. The RIS must be able to communicate meaningful status while preserving the distinction between requested, accepted, vetted and booked.
The EPR may need visibility of these changes. A clinician who submits an urgent request should be able to see whether it has been received, whether further information is required, whether an appointment has been arranged and whether the examination has taken place. This can be achieved through status messages, embedded RIS information, application programming interfaces or EPR workflow components. The exact implementation differs between suppliers, but the principle is consistent: request status should be visible without relying on telephone calls to radiology.
Scheduling data can also flow back to the EPR or patient-facing services. Appointment date, time, location, preparation requirements and contact information may be displayed in the clinical record or used to generate letters, text messages and portal notifications. If an appointment changes, downstream services must receive the updated information rather than continuing to show the original slot.
The integration must account for unscheduled and emergency workflows. A patient arriving from the emergency department may be imaged before a conventional appointment exists. A mobile radiography examination may be requested for a ward patient whose location changes during the process. A trauma case may require several linked imaging procedures created at speed. Interfaces designed only around elective outpatient scheduling often fail when exposed to these real-world scenarios.
Encounter information is valuable because the same patient may be receiving care under several episodes simultaneously. A report for an inpatient examination should return to the current responsible team, while an outpatient study may need to appear in a different pathway. If encounter references are lost, the result may reach the patient record but fail to trigger the correct clinical workflow.
EPR integration also supports access to contextual clinical information. Radiologists may need recent laboratory results, allergies, renal function, medications, previous diagnoses, operative history or relevant clinic notes before determining a protocol or issuing a report. This information may be displayed through an embedded EPR view, a context-sensitive launch or selected data feeds. Replicating the entire EPR within the RIS is neither necessary nor desirable; the aim is to provide timely access to clinically relevant information while maintaining a clear source of truth.
Once reporting is complete, the authorised result must return to the EPR. HL7 result messages are commonly used to transmit the report text and associated metadata. The message should identify the patient, order, examination, reporting clinician, result status and relevant timestamps. It should also distinguish between preliminary, final, corrected and appended reports.
Report lifecycle handling matters because radiology reports can change after initial release. A radiologist may correct a transcription error, add information after reviewing prior imaging or issue an addendum following multidisciplinary discussion. The EPR must not merely store each version as an unrelated document. Users should be able to recognise which version is current, what changed and whether the amendment requires clinical review.
A technically delivered result is not necessarily a clinically communicated result. For routine reports, filing the authorised result in the patient record may satisfy the workflow. For urgent or unexpected findings, additional communication may be required. Magentus CRIS can support documentation of alerts, acknowledgements or direct communication, but organisations must define how these processes interact with EPR tasks, inboxes and escalation mechanisms. The interface should reinforce the clinical policy rather than create the false impression that message delivery alone proves the responsible clinician has acted.
Magentus CRIS rarely connects only to PACS and the main EPR. Modern imaging services rely on a wider set of applications, each addressing a specialised part of the diagnostic pathway. These may include speech-recognition platforms, advanced visualisation tools, dose-management systems, contrast-management applications, patient portals, electronic referral services, artificial-intelligence platforms, image exchange networks, multidisciplinary-team systems and business-intelligence services.
Speech recognition is one of the closest integrations to the reporting workflow. The radiologist selects an examination, reviews the images and dictates the report. The speech-recognition system must receive the correct patient and examination context, place the recognised text into the appropriate report and return control without disrupting the worklist. Templates, macros and structured-reporting components may be driven by procedure type, modality, body region or user preference.
A well-designed integration also separates draft creation from report authorisation. Speech recognition may produce text, but Magentus CRIS manages the report’s formal status, ownership and release. This distinction prevents an incomplete or unverified draft from being treated as a final clinical result.
Artificial-intelligence integration introduces additional workflow decisions. An AI application may analyse images after they reach PACS, prioritise a worklist, produce measurements, highlight suspected abnormalities or generate structured findings. The technical connection may involve DICOM routing, DICOMweb services, application programming interfaces, HL7 messages or a combination of these. However, transferring the image is only the first stage. The organisation must decide how the output will be represented and how clinicians will use it.
An AI result might appear as an overlay, secondary capture, structured report, numerical score, worklist flag or notification. Each form has different implications. A prioritisation score should not be confused with a diagnosis. An overlay should remain linked to the source study. A measurement should state its units and method. A negative AI result should not cause the examination to disappear from human review unless the system has been explicitly designed, validated and governed for that purpose.
The RIS can provide the workflow context that makes AI output useful. It knows which examinations are awaiting reports, which have already been authorised, which service or site owns the case and which radiologist is working on it. Without this context, an AI platform may successfully analyse an image but return the result too late, send it to the wrong queue or create a separate worklist that clinicians must monitor manually.
Dose-management systems receive information about radiation exposure from modalities, PACS or structured DICOM dose objects. Connecting this information with the RIS examination record allows analysis by procedure, scanner, site, operator and patient. It can support optimisation, investigation of unusual exposure and compliance monitoring. Accurate procedure mapping is essential; otherwise, dose values may be grouped under inconsistent names and lose their comparative value.
Contrast-management and injector systems may also require patient, protocol and examination information. They can record contrast agent, volume, concentration, injection rate and adverse events. Where this information returns to the clinical record, units and coding must be precise. Free-text transfer may be easy to implement but limits audit, analytics and automated safety checks.
Image exchange services support referrals, specialist opinions and patient transfers between organisations. Their integration with Magentus CRIS and PACS should maintain the distinction between locally acquired studies and externally received images. An imported study may need to be matched to an existing patient, linked to a referral and made visible as a relevant prior. It should not automatically appear as a locally performed examination or trigger local activity reporting unless the workflow explicitly requires that treatment.
Cross-organisational imaging networks make identity and code governance more difficult. Participating hospitals may use different patient identifiers, procedure catalogues, location codes and reporting conventions. A shared RIS can provide a common workflow layer, but only if local differences are represented deliberately. Forcing every site into superficially identical codes without understanding their operational meaning can create hidden errors.
Integration should therefore use controlled mappings and retain provenance. Users and receiving systems should be able to determine where a request originated, where an examination was performed, which organisation produced the report and which identifiers are local or regional. This becomes especially important when radiologists report remotely across several trusts or when capacity is redistributed across an imaging network.
Multidisciplinary-team systems and cancer pathways may consume reports, key images and examination status. These integrations can reduce manual preparation by identifying relevant studies and making results available to the meeting workflow. Nevertheless, automated selection should be reviewable. A report containing a particular phrase does not necessarily mean that the examination is appropriate for a specific meeting, and an omitted code should not prevent a clinically important case from being considered.
Data warehouses and analytics platforms receive operational information from Magentus CRIS to support waiting-list management, demand forecasting, turnaround-time monitoring, modality utilisation and workforce planning. The extraction must preserve the meaning of timestamps. Request time, vetting time, booking time, attendance time, examination completion, preliminary report and final authorisation represent different stages. Combining them into a generic “date” field undermines performance analysis.
Interfaces with research platforms require additional safeguards. Data may need to be pseudonymised, de-identified or restricted according to an approved protocol. Removing a patient’s name is not sufficient if identifiers remain in DICOM metadata, report text or embedded annotations. The integration design should treat images and reports as potentially identifying clinical records, not as ordinary technical files.
The most reliable Magentus CRIS integrations begin with workflow analysis rather than message configuration. Technical teams should observe how requests are created, vetted, scheduled, performed, corrected, reported and communicated. They should include elective, emergency, inpatient, outpatient, mobile, interventional and multi-site scenarios. An interface that supports the standard pathway but fails during exceptions will generate workarounds precisely where clinical pressure is highest.
A detailed integration specification should define every message, trigger, field, identifier, code set and acknowledgement. It should state which system initiates the transaction, what event causes it, which values are mandatory, how updates are represented and what happens when processing fails. Mapping tables should be version-controlled and owned jointly by technical and clinical stakeholders.
The specification should also define idempotency: how the receiving system behaves when the same event is delivered more than once. Healthcare interfaces frequently retransmit messages after timeouts or connection failures. A repeated order message should not create a second examination, and a repeated result should not create an apparently new report. Stable identifiers and clear update rules allow duplicate transmissions to be processed safely.
Sequence management is equally important. Messages can arrive late or out of order. A demographic amendment may overtake the original registration message, or an examination cancellation may arrive before a delayed scheduling update. The receiving system should not blindly treat the last message received as the most accurate. Timestamps, event types and current workflow state should be considered.
Acknowledgements must be meaningful. A transport-level acknowledgement may confirm that a message reached the destination interface, but it does not prove that the clinical transaction was accepted. A message can be syntactically valid yet fail because the patient is unknown, a procedure code is unmapped or a required identifier is missing. Monitoring should distinguish communication success from application-level processing success.
Error handling should create actionable work rather than burying failures in technical logs. Support teams need to know which patient or examination was affected, what failed, whether the message can be replayed and whether clinical intervention is required. High-severity failures, such as an authorised report not reaching the EPR, should trigger escalation appropriate to the clinical impact.
Interface monitoring should cover volume, latency, rejection rates, queue depth and unusual changes in message patterns. A connection can remain technically online while clinical activity stops flowing. For example, a code-mapping change may cause all requests for one new procedure to fail while other orders continue normally. Monitoring only server availability would not detect the problem.
Testing must be based on complete patient journeys. Unit testing confirms that individual messages are correctly constructed, but integration testing demonstrates that connected applications respond as expected. End-to-end testing should follow an order from the EPR into Magentus CRIS, through scheduling and modality worklist, into PACS, through reporting and back to the EPR.
Test scenarios should include both normal and exceptional events: new patients, demographic changes, merges, cancellations, rebookings, non-attendance, urgent requests, amended orders, changed procedures, aborted examinations, corrected images, preliminary reports, final reports, report addenda and downtime recovery. Multi-site deployments should test transfers between locations and reporting across organisational boundaries.
Clinical users must participate in acceptance testing. An interface can satisfy its technical specification while presenting information in a confusing or unsafe manner. Radiographers can identify worklist descriptions that are difficult to distinguish. Radiologists can assess whether prior studies and clinical questions are visible at the correct moment. Referrers can confirm whether report amendments and urgent-result notifications are understandable.
Performance testing should reflect realistic peaks rather than average activity. Morning scheduling runs, large patient updates, migration loads and service recovery after downtime may create message bursts. Image-related integrations should account for very large studies and slow network links. A workflow that performs well with ten test patients may behave differently when thousands of events are queued.
Downtime design is part of integration, not a separate operational concern. The organisation needs a documented method for requesting, performing and reporting examinations when the EPR, RIS, PACS, network or integration engine is unavailable. It also needs a reconciliation process for restoring electronic records afterwards. Simply replaying every queued message can be unsafe if staff created temporary records or changed schedules during the outage.
Security controls should protect data in transit and restrict system-to-system access. Interfaces should use appropriate network segmentation, authenticated connections, managed service accounts, certificate lifecycles and least-privilege permissions. Logs should provide sufficient information for support without unnecessarily exposing clinical content. Remote support and vendor access should be controlled, time-limited where possible and auditable.
Every significant interaction should be traceable. For a given examination, support teams should be able to determine when the request was sent, when Magentus CRIS accepted it, which accession number was assigned, when the modality retrieved the worklist, when PACS received the images, when the report was authorised and when the EPR accepted the result. This does not require one universal log, but it does require consistent identifiers across systems.
Clinical-safety assurance should consider hazards created by both failure and misleading success. A missing message is dangerous, but so is a message attached to the wrong patient. A visible error may be safer than a silent default. Examples of integration-related hazards include duplicated patients, incorrect procedure mappings, outdated worklists, images associated with the wrong order, report amendments presented as new routine results and urgent findings delivered to an unattended inbox.
In NHS settings, integration changes should be incorporated into the relevant clinical risk-management processes. The supplier’s safety documentation and the deploying organisation’s local safety case have different but connected roles. Local configuration, mapping, workflow decisions, infrastructure and operating procedures can introduce risks that do not exist in the base product.
Change control must continue after go-live. Procedure catalogues evolve, EPRs are upgraded, hospital structures change and new clinical systems are introduced. A small alteration to a code or field can affect several downstream applications. Interface dependencies should therefore be documented, regression tests maintained and releases assessed for clinical as well as technical impact.
The success of Magentus CRIS integration should ultimately be measured through clinical and operational outcomes. Useful indicators include reduced duplicate entry, fewer unmatched studies, faster request processing, improved report turnaround, fewer interface-related incidents and better visibility of the imaging pathway. Technical availability remains important, but a connection that is continuously online while users rely on manual workarounds is not a successful integration.
When Magentus CRIS, PACS, EPR and specialist clinical systems are engineered as one workflow, information follows the patient rather than remaining trapped in individual applications. Requests arrive with the context needed for vetting, modalities receive accurate worklists, images retain reliable identifiers, radiologists move between systems in context, and reports return to the responsible clinical teams with a clear status.
Is Magentus CRIS available as a cloud-based radiology information system?
Yes. Magentus describes Cris as available through cloud-based or desktop deployment. Organisations should confirm hosting, data residency, resilience, remote-access controls and responsibility for upgrades when planning a Magentus CRIS implementation.
What is Magentus Cris version 3?
Cris version 3 is the latest generation of the Magentus radiology information system, launched in 2025 with new web-based applications. Available functionality includes Cris Scheduling through the Cris Launchpad, although modules and upgrade requirements may vary by deployment.
Can Cris Connect link existing RIS and PACS platforms without replacing them?
Yes. Magentus states that Cris Connect can share imaging history, planned appointments and clinical reports between participating sites while retaining their underlying RIS and PACS technology. This can support imaging-network integration without requiring an immediate full system replacement.
What should NHS organisations check about DIDS v2.0 when integrating Magentus CRIS?
NHS diagnostic imaging providers must be able to collect the information required by DIDS v2.0 from 1 April 2026. A Magentus CRIS integration project should therefore confirm the deployed Cris version, mandatory field mappings, data-quality rules, extraction process and responsibility for national submissions.
What Magentus CRIS training and technical support are available?
Magentus provides online product help, training resources through the Magentus Academy and access to service-desk support. Depending on the local support model, users may need to contact their NHS Trust IT team or prime contractor first for Cris installation and configuration issues.
Is your team looking for help with Magentus CRIS integration? Click the button below.
Get in touch