Migrating to InterSystems HealthShare Connect Cloud

Why organisations migrate to HealthShare Connect Cloud

Most integration programmes do not fail because the engine cannot route messages. They fail because the platform becomes hard to operate: unclear ownership, inconsistent standards, fragile deployments, limited monitoring, and slow change. HSCC is attractive when you want a more repeatable, governed integration service that supports multiple programmes across PAS/EMR, lab, radiology, patient administration, and national services.

• Operational resilience: reduce the “single integration server” risk and improve recoverability.
• Standardisation: shared patterns for HL7 v2, REST, FHIR, file exchange, and transformation.
• Delivery velocity with control: safer releases via tested packages and controlled promotion paths.
• Visibility: consistent monitoring, alerting, and auditability across the estate.

What changes in the cloud (and what does not)

The payloads are the same: HL7 v2, X12-style files, APIs, FHIR resources, PDFs, and clinical documents. The difference is how you operate. In a cloud-managed integration model, you must be deliberate about environments, deployment pipelines, observability, credential management, and production access.

Target architecture: how HSCC typically sits in a provider ecosystem

In NZ provider environments, the integration layer sits between PAS/EMR (often TrakCare), departmental systems (LIS, RIS/PACS, pharmacy, theatres), identity services, and external parties (primary care, national services, private providers, and vendors). HSCC becomes the standard integration runtime where new interfaces are built and legacy ones are progressively migrated.

• Ingestion: HL7 v2 (ADT/ORM/ORU), REST APIs, SFTP/file drops, vendor feeds.
• Routing and transformation: mapping, enrichment, validation, terminology/value-set alignment.
• Edge security: certificates, mutual TLS, IP allowlists, token flows where applicable.
• Observability: message tracing, error queues, dashboards, and operational runbooks.

Migration approach that survives reality

A workable migration plan is a set of repeatable decisions. The biggest mistake is starting with “how many interfaces do we have?” and ending up in an endless inventory exercise. Start with the migration strategy, then do the inventory in service of that strategy.

1) Stabilise and rationalise first

• Decommission unused feeds and duplicate routes.
• Collapse multiple near-identical interfaces into a single pattern where safe.
• Define canonical formats and mapping standards for your environment.

2) Choose your cutover pattern

• Dual-run with comparison: run old and new in parallel and compare outputs before switching.
• Edge cutover: switch one integration boundary at a time (eg LIS boundary, then RIS, then national).
• Big-bang (rare): only when dependencies are low and rollback is truly achievable.

3) Build a migration factory

Treat the work as a factory: standard templates, consistent naming, automated tests, repeatable packaging, and a clear definition of “done”. This is how you migrate dozens (or hundreds) of integrations without burning out your team.

4) Prove production operations early

• Define monitoring thresholds and alert routing.
• Write runbooks for common failure modes (network, certificates, downstream outages).
• Agree escalation and ownership across IT and clinical operations.

Risk controls CIOs expect (and auditors will ask for)

Integration risk is clinical risk. A mature HSCC programme bakes controls into delivery and operations.

• Traceability: who changed what, when, and why.
• Segregation of duties: controlled production access and approval paths.
• Testing: regression coverage for high-risk flows (ADT, orders, results, billing).
• Fallback: clear rollback or containment approach for each cutover wave.
• Data protection: PHI handling standards and audit logs aligned to policy.

Where programmes get stuck

In every country we have worked across, the blockers look familiar. The technology is rarely the constraint.

• Ownership gaps: no single accountable integration owner across domains.
• Interface sprawl: years of tactical fixes with no rationalisation plan.
• Certificate and identity complexity: unmanaged secrets and brittle trust chains.
• Environment drift: differences between test and production that only show up during cutover.
• Vendor coordination: unclear boundary contracts and delayed partner readiness.

What it looks like when you use a NZ InterSystems implementation partner

Most providers do not want to become an integration product company. They want dependable integration capability with clear ownership. A partner-led HSCC migration typically focuses on removing operational burden while leaving you with a sustainable operating model.

The goal is simple: faster migration, fewer production incidents, and a platform your team can run without heroics.