The InterSystems IRIS for Health product does not enable TLS/SSL encryption by default, so information sent over the network is in clear text.

View CSAF Summary Successful exploitation of this vulnerability could allow an attacker to view transmitted data and use that data to log into the device. The following versions of InterSystems Corporation InterSystems IRIS for Health are affected: InterSystems IRIS for Health 2026.2.0.221, 2026.1.0.235, 2025.3.0.226 (CVE-2026-111594, CVE-2026-111594, CVE-2026-111594) CVSS Vendor Equipment v3 8.1 InterSystems Corporation InterSystems IRIS for Health 1 Vulnerability Cleartext Transmission of Sensitive Information Background Critical Infrastructure Sectors: Healthcare and Public Health Countries/Areas Deployed: Worldwide Company Headquarters Location: United States Vulnerabilities CVE-2026-111594 InterSystems IRIS for Health has TLS/SSL encryption turned off by default, which may enable an attacker to view transmitted data and use that data to log into the device. Read More 3 Affected Products InterSystems Corporation InterSystems IRIS for Health: 2026.2.0.221 Product Status: known_affected Remediations Mitigation InterSystems recommends users configure IRIS superserver to require SSL/TLS: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ROARS_gsecuring_checklist Note that there are three settings: "Disabled", which means that client communications do not use TLS. "Enabled", which means that client communications may use TLS (but they also may not) and "Required", which forces all client communications to use TLS. Mitigation InterSystems documentation explains how to configure the server to require TLS: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_manage_superserver Mitigation For more information about how to configure a system to mitigate this vulnerability, contact InterSystems at their world wide response center: https://wrc.intersystems.com (login required) InterSystems Corporation InterSystems IRIS for Health: 2026.1.0.235 Product Status: known_affected Remediations Mitigation InterSystems recommends users configure IRIS superserver to require SSL/TLS: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ROARS_gsecuring_checklist Note that there are three settings: "Disabled", which means that client communications do not use TLS. "Enabled", which means that client communications may use TLS (but they also may not) and "Required", which forces all client communications to use TLS. Mitigation InterSystems documentation explains how to configure the server to require TLS: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_manage_superserver Mitigation For more information about how to configure a system to mitigate this vulnerability, contact InterSystems at their world wide response center: https://wrc.intersystems.com (login required) InterSystems Corporation InterSystems IRIS for Health: 2025.3.0.226 Product Status: known_affected Remediations Mitigation InterSystems recommends users configure IRIS superserver to require SSL/TLS: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ROARS_gsecuring_checklist Note that there are three settings: "Disabled", which means that client communications do not use TLS. "Enabled", which means that client communications may use TLS (but they also may not) and "Required", which forces all client communications to use TLS. Mitigation InterSystems documentation explains how to configure the server to require TLS: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_manage_superserver Mitigation For more information about how to configure a system to mitigate this vulnerability, contact InterSystems at their world wide response center: https://wrc.intersystems.com (login required) Additional Metrics Relevant CWE: CWE-319 Cleartext Transmission of Sensitive Information CVSS Version Base Score Base Severity Vector String 3.1 8.1 HIGH CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 4.0 9.2 CRITICAL CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N View CVE Details Acknowledgments Abhinav Agarwal reported this vulnerability to CISA and InterSystems Corporation. Recommended Practices CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities. Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet . Locate control system networks and remote devices behind firewalls and isolating them from business networks. When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures. CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics . Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies . CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets . Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies . Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents. CISA also recommends users take the following measures to protect themselves from social engineering attacks: Do not click web links or open attachments in unsolicited email messages. Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams. Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks. No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. Revision History Initial Release Date: 2026-10-22 Date Revision Summary 2026-10-22 1 Initial Publication Legal Notice and Terms of Use

CISA has added six new vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. ICSMA-26-295-01 - InterSystems Corporation InterSystems IRIS for Health ICSA-26-295-01 - Kiloview E3 NDI Encoder ICSA-26-295-02 - Siemens Industrial Edge App Publisher ICSA-26-295-03 - Siemens Software Center ICSA-26-295-04 - Siemens Capital Embedded AR Classic ICSA-26-295-05 - Siemens SENTRON 3NA COM Fuse ICSA-26-295-06 - Siemens PSS(R)SINCAL ICSA-26-295-07 - Siemens SIMATIC IPCs ICSA-26-295-08 - Siemens APOGEE, TALON and Desigo PXC/PXM Products ICSA-26-295-09 - Siemens Industrial Edge Device Kit ICSA-26-295-10 - Siemens SIMATIC S7 Webserver API ICSA-26-295-11 - Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP ICSA-26-295-12 - Siemens RUGGEDCOM CROSSBOW ICSA-26-295-13 - Siemens WinCC ICSA-26-295-14 - Siemens SIMATIC S7 PLCs Web Server ICSA-26-295-15 - Siemens RUGGEDCOM CROSSBOW Station Access Controller ICSA-26-295-16 - Siemens SIMATIC S7-1500 TM MFP ICSA-26-295-17 - Siemens Industrial Edge Devices ICSA-26-295-18 - Siemens RUGGEDCOM APE1808 Devices ICSA-26-274-06 - Meari IoT Cloud Platform OpenAPI Service (Update A) These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog that meet the specified criteria . Aware of an exploited vulnerability not currently listed in the KEV Catalog? Submit it for potential addition through CISA’s KEV Nomination Form . Potential KEV additions must have a CVE ID, evidence of exploitation, and clear mitigation guidance.

ICS Advisory Project The ICS Advisory Project is an open-source project that provides the Critical Infrastructure Security Agency (CISA) ICS Advisories, visualized as a Dashboard and in Comma-Separat...

Connecting community care and mental health records in Birmingham removes critical blind spots for 80,000 service users.

## **TL;DR** We connected InterSystems Reports, powered by Logi Report from insightsoftware (Designer + Server), to a production InterSystems IRIS instance to deliver branded, scheduled PDF and Excel reports built on IRIS SQL views. This article is the walkthrough we would have liked to have on day one: least-privilege IRIS setup, a reliable JDBC configuration, SQL views as the contract between IRIS and the reporting layer, and branding centralized in CSS plus a template report. Our main takeaway on the tooling itself is that although report files can be edited as code, the Designer UI should be your default — reserve direct file editing for features you already understand deeply. Each step includes the tips that made the setup repeatable for us. ## **Who This Article Is For** This guide is for IRIS developers and integration engineers who need to expose IRIS data — in our case,, healthcare remittance data — through a third-party reporting tool, and who want the connectivity, modeling, and templating decisions laid out before they start. ## **A Note on Our Approach: Code Editing vs. the Designer** **InterSystems Reports store their reports, catalogs, and stylesheets as editable files, so everything you can do in the Designer, you can also do in a text editor. So, we deliberately pushed on that to find the limits.** For a team that prefers version-controlled, scriptable workflows, this is genuinely appealing, so we explored it: editing report XML directly and maintaining our styling as a hand-written CSS file. The conclusion we came to is worth stating up front, because it shapes every recommendation that follows: > **Opt for the Designer UI by default.** Outside of it, behavior is harder to predict: the Designer maintains internal invariants and relationships between attributes that are not obvious from reading a file. Also, a hand-edited file can be structurally valid yet behave differently from one the Designer produced. Keep direct file editing for the pieces you already understand deeply. ## **What We Were Building** **The goal was scheduled: brand-consistent client reports generated directly from IRIS production data, with no intermediate data warehouse.** Our source data was EDI remittance content (835 / Electronic Remittance Advice) already persisted in IRIS. Our clients needed periodic operational reports — a payer routing summary with a claim-level detail tab and a remittance register — delivered on a schedule rather than run ad hoc from a portal. Layer | What we used | Role ---|---|--- Data platform | InterSystems IRIS | Source of truth; SQL views as the reporting contract, Connectivity | InterSystems JDBC driver | Single connection point for the report server, Report authoring | InterSystems Report Designer | Layout, parameters, grouping, summaries, Delivery | InterSystems Report Server (Windows VM) | Scheduling, PDF/Excel export, distribution, The architecture is deliberately thin: IRIS does the querying, while the reporting tool handles presentation and delivery. Every design decision below originates from the need to keep that separation clean. ### **Why InterSystems Report and Not Power BI or Tableau** **We evaluated Power BI and Tableau alongside InterSystems Report, and chose InterSystems Report mainly because it added the least infrastructure to an environment that IRIS already had.** Four points that influenced our choice: * **First-class IRIS support:** InterSystems Reports is powered by Logi Report (formerly JReport from insightsoftware) and officially supported by InterSystems IRIS and IRIS for Health. Because of this, the connection path is fully documented and supported, saving us from having to prove it out ourselves. * **No second database engine:** Since every tool requires space to store its configuration, catalog, and scheduling state, the InterSystems Reports Server keeps track of its configuration in a system database maintained by an InterSystems IRIS instance. This means that the same instance can act as both the data source and the system database. The alternatives need their own separate engine, which means additional licensing and extra things to back up and patch. * **Delivery was simple to stand up:** Scheduled generation and distribution shipped with the report server, and could run on the same VM as everything else. Alternatively, getting comparable unattended delivery working on the other options involved noticeably more moving parts. * **Lowest total cost for our footprint** (once the extra database and hosting for the alternatives were calculated). Power BI and Tableau are stronger for interactive, self-service exploration. Our requirement, however, was the opposite — pixel-controlled, branded documents produced on a schedule — which is exactly where a banded, page-oriented report tool fits best. ## **Step 1: Granting the Reporting User Least-Privilege Access in IRIS** **Since the reports read from a production instance, we needed to grant the smallest set of privileges that would still let a report run — nothing more.** This turned out to be a short list, which was worth setting up deliberately rather than starting extensive trimming later. The minimum that worked for us included the following: 1. **A dedicated user** exploited only by the report server'sconnection pool without interactive or Management Portal usage. 2. **One role** holding read access to the `%DB_<resource>` of the database behind the namespace. 3. `SELECT`**on the specific views the reports consume** , rather than on the whole schema, so new tables added later are not automatically exposed. 4. **The**`%Service_SQL`**service that is enabled** for that user, which is the SuperServer/JDBC path the report server uses. That is all a report needs: no `%All`, no `%Development`, no write privileges anywhere. > **Tip:** the database resource name is not necessarily derived from the namespace name — a namespace called `REPORTING` can sit on a database whose resource has an entirely different name. Look up the actual resource in the Management Portal (System Administration → Configuration → Namespaces, then check the database behind it) and grant permissions on that exact `%DB_*` name. Confirming it up front is the difference between a five-minute setup and a puzzling `Access Denied Error`. ### **The JDBC detail worth writing on a sticky note:** Use the loopback **IP address** , not the hostname: # Reliable jdbc:IRIS://127.0.0.1:1972/MYNAMESPACE # Can fail depending on host resolution order jdbc:IRIS://localhost:1972/MYNAMESPACE Driver class: `com.intersystems.jdbc.IRISDriver` The reason matters: On a dual-stack Windows host, `localhost` can resolve to the IPv6 loopback (`::1`) while the SuperServer is listening on IPv4, so the connection attempt never reaches the listener. The symptom looks like a plain refused connection, with nothing pointing at the address family issues. Specifying `127.0.0.1` removes the ambiguity entirely. **Checklist of things to verify if the connection is hard to troubleshoot:** * SuperServer port reachable (`1972` by default) * Driver JAR on the report server's classpath, matching the Java version in use * Loopback specified as an IP * Reporting role holds the correct `%DB_*` resource * Namespace name spelled exactly as IRIS reports it ## **Step 2: Let SQL Views Be the Contract** **Pointing a reporting tool at views instead of tables or persistent classes was the single most highest-leverage decision we made.** We defined views in IRIS that shape the remittance data into report-ready rows, then had Logi import only those. A simplified version of the pattern is as follows: Class Remit.View.Documents Extends %Persistent [ ClassType = view, SqlTableName = Documents, ViewQuery = { ... } ] { } Why this helped: * **Report layouts stop depending on physical structure.** Storage or class changes stay inside the view. * **Business logic lives in IRIS** , where it can be easily tested with plain SQL, instead of remaining inside report expressions that are harder to inspect. * **Column names become presentation-friendly** only once, rather than being aliased in every report. * **Complex navigation stays server-side.** Correlated subqueries and `->` implicit-join syntax are far easier to reason about in a view than in a report designer's query builder. ## **Step 3: Running the Report Server as a Windows Service** **Install the report server as a Windows service so that scheduled runs survive reboots and logoffs, and if it behaves inconsistently under the service wrapper, reinstall it in interactive mode.** The report server will ship a service utility, and the install command will accept an `-interactive` option: JRService -install -interactive What the option does: Installing with `-interactive` alongside `-install` registers the service in interactive mode, so a Command Prompt window appears when the service starts. Without it, the server runs silently, and its console output is not shown anywhere conveniently. That visibility is the practical value — startup messages, classpath problems, and licensing or port complaints appear as the server emits them, rather than having to be inferred from a service that simply did not come up. If a service-hosted server starts behaving differently than the same server launched from a console, reinstalling this way is a quick, reversible thing to try. The lesson generalizes beyond this product: when a Java-based server behaves differently as a service than it does interactively, look at the registration flags, the service account, and the JVM the service actually resolves before changing anything in the application configuration. Two more environment notes worth setting up deliberately: * **If**`JAVA_HOME`**inheritance gives you trouble, pin the JDK path explicitly.** The service reads its JVM path and Java command line from `NTService.ini` in the install `bin` folder. Set the `JavaVM` parameter to the exact JDK you intend to use, rather than depending on what the service account inherits. The same file is stored where heap size lives, so it is worth knowing regardless. * **Keep the IRIS JDBC JAR in the server's own library folder** so upgrades do not silently orphan it. > **Tip:** A service-hosted server cannot reach mapped network drives because of a JVM limitation. If reports read from or write to a network location, use a UNC path rather than a mapped drive letter. ## **Step 4: Binding Data Inside the Report** **Most "cannot find dataset" errors come from binding the dataset to a nested component instead of the report body container.** Reading the report XML makes this requirement visible: the dataset element must be present on the `ReportBody` container itself. <ReportBody name="Body"> <dataSet name="DS_Documents"/> <!-- tables, banded panels, charts --> </ReportBody> If it appears only on the inner table, the report can fail at pre-initialization before anything renders — an error that reads like a missing resource rather than a placement issue. Two more binding behaviours worth knowing: * `additionalMappingNames`**uses a counted, delimited format** (a count followed by each name in sequence). It is precise and unforgiving: if the count drifts out of step with the list, the failure tends to surface later and less obviously. This is a good example of an attribute to set in the Designer rather than by hand. * **A summary's reset level controls aggregation scope, not the location where the value appears.** A sum placed in a group footer will still total the whole report unless its reset level is set to the grouping field. Wrong-looking totals in the right-looking place almost always mean reset level issues. ### **When you change a view, refresh the metadata:** Adding a column to an IRIS view does not automatically propagate to the report catalog. The column metadata has to be re-imported, and in our environment, a server or connection-pool restart was needed before the new column appeared in running reports. Building "refresh catalog metadata" into our schema-change routine removed a recurring source of confusion where the database and the report clearly disagreed. ## **Step 5: Brand Consistency Without Copy-Paste** **Reusable branding came from two artifacts — a CSS file for tokens and a template report for structure — not from styling each report manually.** Our approach: * **A brand CSS file** defining classes for our palette and type scale, appended to the default stylesheet the report server serves. We can change colors and fonts in one place. * **A template shell report** ccontaining the page header and footer with report title, date period, and run timestamp in the header (address found on the left, page number in the center, and company URL in the right part of the footer). New reports start as copies of the shell. * **Registered custom fonts** referenced consistently by their registered names. Register your TrueType fonts in the report server's `font` directory **and** on every Designer machine. If a font is missing at render time, the output falls back to a substitute and the layout shifts, which is easy to miss until a client points at a PDF that looks slightly off. We initially looked at XSD-based style groups for this, since they promise exactly this kind of centralized styling. However, since that mechanism is deprecated in current versions, we moved to CSS plus the template shell, which turned out to be simpler to review and version anyway. It is worth checking the deprecation status of any styling feature before building a system on it. ## **Step 6: Parameterize for Scheduling, Not for Clicking** **Reports designed for scheduling need parameters with sensible defaults and no reliance on user interaction.** Every report shares the same parameter shape: client, date range, and entity identifier. Because schedules are interchangeable, adding a new client only requires a new schedule rather than a new report. Design implications: * Give every parameter a valid default so an unattended run will never block on input. * Echo the parameter values into the header so a delivered PDF is self-describing. * Prefer date ranges computed relative to run time over hard-coded windows. * Test the scheduled path early since it exercises a different code path than the Designer preview. ## **Common Mistakes** **Pitfalls worth avoiding:** * Granting namespace access without the underlying `%DB_*` database resource. * Editing counted-and-delimited XML attributes by hand. * Assuming a group footer position implies group-level aggregation. * Expecting IRIS schema changes to appear in the report catalog automatically. * Building on a deprecated styling mechanism. ## **Frequently Asked Questions** ### **Q: Do I need a separate reporting database or read replica?** A: Not necessarily. We report directly from production through read-only views and scheduled off-peak runs. If report queries grow heavy, an IRIS mirror or shard is the natural next step. Starting simple, however, avoids creating infrastructure we do not need yet. ### **Q: Why do I get "Access Denied" when my credentials are correct?** A: Most often because the role lacks the `%DB_*` resource for the database behind the namespace. Namespace and resource names are independent. Confirm the resource name in the Management Portal. ### **Q: Why does**`localhost`**fail in my JDBC URL when the instance is running?** A: Because it may resolve to the IPv6 loopback while the listener is bound to IPv4. Use `127.0.0.1` explicitly. ### **Q: Should I edit report files as XML or use the Designer?** A: Use the Designer by default. The files are editable, and reading them is genuinely useful for understanding how a report is wired. However, behavior outside the Designer is less predictable. It maintains invariants between attributes that are not visible in the file. Reserve direct editing for things you already understand deeply. ### **Q: My report shows the wrong totals. Where do I look first?** A: At the summary's reset level. Panel placement affects where a value prints; reset level determines what it aggregates. ### **Q: I added a column to my view, and the report cannot see it. Why?** A: The report catalog caches column metadata. Re-import the view's metadata and, if needed, restart the server or connection pool so running reports pick up the change. ### **Q: How do we keep dozens of reports visually consistent?** A: A CSS file for color and type tokens, plus a template report carrying the page header and footer. Since new reports are copies of the template, structure and branding are inherited rather than rebuilt. ## **Practical Recommendations** If you are starting a similar project, this is the order we recommend you adopt: 1. **Prove connectivity first** with a trivial one-column view before any layout work. 2. **Design the views before the reports.** The view list is your reporting API. 3. **Build the branded template shell second** , so the first real report is already correct. 4. **Externalize color and type into CSS** from day one. 5. **Standardize the parameter signature** across reports. 6. **Test every export format and the scheduled path** before showing anything to a client. 7. **Write down the environment specifics** : driver path, JDK path, font directory, and resource names. In the future, you will need them at an inconvenient moment. ## **Conclusion** Connecting a third-party reporting tool to InterSystems IRIS is mostly a modeling and configuration exercise, not a rendering one. Once the security resources, JDBC details, and view layer are right, the reporting tool does what it is good at, and IRIS keeps doing what it does best. The details that matter are specific and learnable — resource names, host resolution, dataset placement, metadata caching — and each one becomes a checklist item rather than a recurring problem. We recommend spending the first day on the views and the branded template since, with those two in place, every report after the first one is mostly layout. Having tried a few other solutions, what stands out about InterSystems Report is how approachable it makes complex queries in a low-code way. It assumes a baseline understanding of SQL, but beyond that, the deeper concepts (grouping, nested groups, aggregation, and reset scopes) are unusually easy to reason about once you see how they are expressed in the Designer. That combination is what made it a good fit for reports that are structurally rich but need to be maintained by more than one person. A practical tip for getting started: **build a plain table first.** A table shows you exactly what the query returned, so you can confirm that the data is what you expect before any presentation decisions are made. Once the table is right, base everything else (charts, summaries, grouped layouts) on that same verified dataset. It is a much shorter path than debugging a chart that is beautifully drawing the wrong numbers. The one area where we would love to see the product evolve is styling: **a little consolidation there would go a long way.** Today, it is spread across several models: some styling is standard CSS, some uses Logi-specific class and property naming, and some deprecated mechanisms still appear in the UI. This makes it hard to tell which approach is current. There is also no first-class way to save a report's look as a reusable template; the practical workaround is to copy an existing report and build the new one on top of it, which works but means visual standards live in a file rather than in something explicitly designed to be shared. A single, clearly documented styling path plus a native template object would make brand consistency across a report suite considerably easier to achieve and to hand over. Everything we needed was reachable — it just took some exploration to find the right combination, and that is exactly the kind of thing better defaults could solve. The setup has been stable in production, and we are glad to compare notes with anyone building something similar.

InterSystems is the data Goliath of health care, present in 20 countries and processing two-thirds of all medical records in the United States. But even InterSystems has to evolve to deal with the challenges of health care, including shrinking funds and the vast expansion in the use of data for analytics and AI. In a

InterSystems is the data Goliath of health care, present in 20 countries and processing two-thirds of all medical records in the United States. But even InterSystems has to evolve to deal with the challenges of health care, including shrinking funds and the vast expansion in the use of data for analytics and AI. In a

Adaugeo Healthcare Solutions (AHS) is seeking an Interface Development Manager to lead our small, focused interface development team. This team is responsible for HL7 messaging, FHIR and SMART on FHIR integrations, and clinical data exchange across our three affiliated entities: AHS corporate, Praxis Health (a multi-region clinic network), and Interpath Laboratory (a multi-region lab network spanning Oregon, Washington, and Idaho). Our current interface engine is InterSystems IRIS for Health....

Thailand’s rapidly aging population is adding new urgency to the country’s push toward artificial intelligence-powered healthcare, with health technology specialists warning that AI alone will not transform hospitals unless reliable and interconnected data becomes the foundation of the system. InterSystems Corporation is highlighting interconnected healthcare data and Practical AI as...

Untitled (Track 9 on Free Psychedelic Poster Inside LP) - Intersystems, 1968

Mini-PC mit Core Ultra 9 läuft unter Ubuntu 26.04 LTS stabil. InterSystems erweitert IRIS-Support un

I recently had the privilege of attending the InterSystems Analyst Summit 2025. The event provided a deep dive into InterSystems' strategic vision, advanced technology, and profound impact across critical industries. It was a comprehensive day filled with insights from Intersystems leaders alongside valuable customer presentations. Here’s a recap of the key highlights and what truly stands out about InterSystems. see less