Caché or Ensemble Is Still in Production
No maintenance releases are planned after 31 March 2027, and InterSystems describes later corrections as discretionary and best effort. Start with an inventory of instances, versions and operating systems.
For InterSystems healthcare teams
Plan a Caché to IRIS migration or an InterSystems Ensemble migration to IRIS, IRIS for Health or Health Connect, with an assessment of versions, custom code, interfaces, licensing and cutover risk. InterSystems plans no Caché or Ensemble maintenance releases after 31 March 2027; its announcement does not set an end date for product support, so confirm your support terms and migration options with InterSystems.
Independent healthcare engineering. Scope, access and specialist roles agreed before delivery.
When teams bring us in
Health systems, HIEs, laboratories and healthcare software vendors running Caché, Ensemble, HealthShare Health Connect or IRIS for Health.
No maintenance releases are planned after 31 March 2027, and InterSystems describes later corrections as discretionary and best effort. Start with an inventory of instances, versions and operating systems.
Business services, processes, operations, data transformations and adapters need a target on IRIS, Health Connect or IRIS for Health, or a rebuild on another engine, with the same message behavior.
IRIS for Health adds a FHIR repository, SMART on FHIR and bulk FHIR, and Health Connect also offers FHIR capabilities. Licensing, profiles and mappings decide what your application can actually expose.
What you can scope
Choose the workstream that addresses your current dependency. Each starts with a reviewable output.
Inventory instances, versions, operating systems, databases, namespaces, productions, custom ObjectScript, CSP and ZEN pages, scheduled tasks and outside connections. Identify macOS or unsupported platforms early.
Decide between IRIS, IRIS for Health and Health Connect for each workload around your productions, routing, transformations, error handling and FHIR needs. List the features and entitlements each InterSystems quote must include before you sign.
Identify the HealthShare products and versions in use, connected systems, patient identity and consent needs, and the work requested. A Health Connect interface project and a HealthShare shared-record project need different scope and acceptance criteria.
Confirm whether an in-place conversion is supported for each source version, operating system and target product, then convert a copy in a test environment following the current InterSystems migration guide. Record code that uses removed or changed features and every manual step.
Fix incompatible code, move development from Studio to VS Code with the ObjectScript extension, place source under Git and update production settings, credentials and certificates.
Rebuild or update ADT, ORM, ORU, SIU, MDM and DFT interfaces and FHIR mappings against each trading partner’s actual specification, with identifiers, terminology and acknowledgements checked.
Replay captured messages and queries into an isolated copy and compare outputs. Where they apply, test web gateway configuration, client drivers, external libraries, scheduled tasks, certificates, backup restore and failover before cutover. Agree who monitors, who responds to incidents and who raises product issues with InterSystems; product support stays under your InterSystems agreement.
Technical fit
HL7 v2, FHIR R4, X12, CDA and REST/SOAP as used by your productions; actual interfaces and versions are confirmed during assessment.
Business services receive messages, business processes route and apply logic, and business operations send them on. Data transformations (DTL) and business process logic (BPL) carry most of the mapping and need line-by-line review during migration.
Review ObjectScript classes, routines and globals for removed or changed features. Embedded Python, generally available since IRIS 2021.2, can be used for new components where your team prefers Python.
Choose Extended Maintenance or Continuous Delivery releases by the features you need, supported platforms and upgrade cadence, and confirm the maintenance policy for the selected release with InterSystems.
Access and licensing. Confirm the target product, required features and license key with your InterSystems account team before conversion, including test, production and recovery environments. Environment access and connected-system permissions must be agreed before delivery. Vendor and infrastructure fees are separate from engineering scope.
Systems and standards
Supported product features are a starting point. Your system specifications, enabled interfaces and permissions determine the implementation.
Registration, encounter, scheduling, orders and results through the interfaces enabled by each EHR and application owner.
HealthShare and regional exchange feeds, patient identity, consent and document exchange, assessed against each participant’s agreement.
Orders, results and reports. Image transport and DICOM requirements are assessed separately from an HL7 feed.
Agreed X12 transactions, FHIR R4 APIs and product data models, with identity, provenance and receiving-system validation.
Migration and controlled change
We assess whether an in-place conversion is supported for your source version, operating system and target product. Whatever the route, every instance, production and custom component must be tested against behavior, data and connected systems before cutover.
Record versions, platforms, namespaces, databases, productions, custom code, scheduled tasks, certificates and outside connections. Separate active workloads from retired ones.
Instance-to-target inventory and a dependency register.Confirm IRIS, IRIS for Health or Health Connect per workload, and the target-product license key and environment entitlements with InterSystems, before conversion.
Target design and an approved license plan.Run the conversion on a copy, never on production first. Replay captured messages and queries and compare outputs, ACK and NAK behavior, ordering and errors.
Test conversion record and signed-off acceptance criteria.Define the window, decision owners and rollback triggers. Decide in advance how data written after cutover would be reconciled and how duplicate messages would be prevented.
Cutover checklist, rollback plan and reconciliation rules.Watch queues, errors and downstream acceptance after release, resolve exceptions and transfer operating knowledge to named support owners.
Monitoring baseline, incident runbooks and handover record.Commercial scope
Ask for separate assumptions and fees for assessment, implementation, third-party products and ongoing support.
Agree the inputs, fee and review date first. The output names each instance and its proposed target, compatibility issues, licensing questions, test coverage, responsibilities and cutover dependencies, with an estimate that states its assumptions and exclusions.
Agree a conversion or interface milestone with tested code, acceptance evidence and handover.
If you need an InterSystems developer, define the ObjectScript, production, testing and operations skills first. Review the proposed specialist’s relevant work, availability and responsibilities before engagement.
InterSystems ObjectScript specialists may be engaged according to project scope. We confirm the delivery team, platform access and responsibilities before committing to implementation.
Delivery and acceptance
Agree the output, owner and acceptance evidence for each stage. Patient-data handling and production access require your approved process.
Evidence and capability
Nirmitee works across healthcare products, HL7, FHIR, APIs and clinical workflows. Review the public engineering below, then ask for evidence relevant to your specific InterSystems scope.
Review code, documentation and supported versions. These are adjacent engineering references, not proof of a production InterSystems migration.
Inspect the Mirth integration cookbook Inspect the headless EHR/FHIR repositoryConfirm the proposed specialist’s experience, availability and responsibilities before engagement. This page does not claim official vendor partnership, certified staff or completed InterSystems projects.
Read the published Mirth hospital integration case study This case study concerns Mirth, not InterSystems. Ask for supporting evidence relevant to your project.Before you commit
InterSystems has said no Caché or Ensemble maintenance releases are planned after 31 March 2027. It has not announced an end date for product support and describes later corrections as discretionary and best effort. Confirm your own support agreement with InterSystems.
InterSystems supports in-place migration for supported configurations. Confirm the route and any intermediate upgrades against the current InterSystems migration guide for your source version, operating system and target product. Test a copy first, verify backup and restore, and agree reconciliation and rollback rules before production conversion.
Health Connect is the integration engine and also offers FHIR capabilities. IRIS for Health adds a FHIR repository and healthcare tools and includes Health Connect features. IRIS is the general data platform with its own interoperability features. The right choice depends on your workloads and the exact features and entitlements in each quote.
Yes. Ensemble interfaces can be rebuilt on engines such as Mirth Connect, Rhapsody or Corepoint, and Caché databases can move to a relational database, usually with application changes. We compare the effort of both paths from your inventory before recommending one.
Nirmitee is an independent healthcare integration services company and does not resell InterSystems licenses. This page does not claim InterSystems partnership or certification. Specialist availability and evidence are confirmed for your project.
Cost depends on the number of instances and environments, data volume, custom ObjectScript, CSP or ZEN pages, interface behavior and the target product. Operating system changes, high availability, disaster recovery and client-library updates add work, and licensing, infrastructure and third-party testing are priced separately. Elapsed time also depends on access approval, license confirmation, partner test windows and change approval. We do not publish a universal price or duration; the assessment separates engineering effort from these dependencies.
A product choice does not establish organizational compliance. Access controls, encryption, logging, retention, contracts and procedures must be designed and reviewed for your deployment with your compliance team.
Share product names and versions, operating systems, approximate instance and interface counts, connected systems and your target date. Use high-level descriptions only in the enquiry form, and arrange an approved channel before sharing protected data or credentials.
A specific next step
Share your environment, interface count, standards, migration plans and support requirements. We’ll review the context and propose a delivery model and the specialist roles required.
The first enquiry scopes the next step. Assessment deliverables, fees, staffing and dates are agreed before project work starts.
Prepare with the integration scoping guideVendor documentation informs product terminology. Installed versions, entitlements and support terms need project-specific confirmation.
InterSystems and other product names belong to their respective owners. Nirmitee provides independent engineering services.
Explore healthcare interoperability services