MiHIN’s Integrated Technology Environment Migration

MiHIN has entered the next phase of our journey, transitioning from processing transactions to enabling transformation of healthcare.

Future-Proofing our Shared Infrastructure

We are actively underway in the migration of our full technical environment, which includes consolidating and integrating all legacy technology and interface engines, to optimize and streamline our processes.

This 18-24 month transition to the Integrated Technology Environment – an AWS platform with a cloud-native integration engine and a FHIR-friendly clinical data repository – will give us better technology with less complexity, positioned to take advantage of FHIR (future technological) transformations.

Next Level Capabilities

This work demands a next level of capabilities, supported by new standards and technologies, that enable the collection, aggregation, and analysis of clinical and non-clinical data from multiple types of data sources.

Application programming interfaces (APIs) that utilize HL7 FHIR®, advanced cloud-native computing platforms, novel technology like Clinical Decision Systems Hooks (CDS Hooks) and the Clinical Quality Language (CQL), and the ready integration of Smart on FHIR applications are all required components of our new environment. 

Additionally, our future-proofed infrastructure and population-based routing are being designed to support robust data exchange for patient centered decision making, care coordination, price transparency, quality & value and compliance.


Migration Milestones

Phase 1

Participant feeds flow directly into the new integrated technology environment and back out to the
customer’s historical interfaces. The client sends to the same connection point and continue to receive data from the same interface engine.

No VPN or Firewall changes  required by customers.

A different type of ACK (an acknowledgement message) is to be received when sending data to MiHIN.

Phase 2

Our new clinical data (FHIR resource) repository, is installed in our development environment. Data flows are being validated.

Phase 3

Designing an upgraded longitudinal record viewer which is natively based on our FHIR repository and aggregates clinical data across our network, accelerating data analytics and meeting Cures Act regulations.



Answers to common questions: 

MiHIN is working to complete the migration process in phases. During implementation, the old system and the new are running in parallel, which eliminates downtime and operational interruptions. Processes running in real-time can keep data continuously migrating and reduce risks.

Why is MiHIN Migrating to an Integrated Technology Environment?
  • To improve data quality
  • To modernize infrastructure
  • To eliminate duplicative legacy systems
  • To increase reliability and responsiveness of scaling services
  • To create the path for required FHIR transformations
  • To bridge existing payer and future provider FHIR environments
  • To provide a cloud native environment that’s optimized, faster, higher performing, and has the highest levels of modern security
What is changing?

We are making the slow, steady migration away from the legacy environments that support some of our current solutions.

While most core functionality will remain, we will be conducting a gaps analysis to understand what we are offering our stakeholders and customers today vs the equivalent functionality we’re expecting to be able to offer with our new environment.

Analysis and findings will be communicated and discussed ongoing.

When is this happening?

We are engaging in a slow and steady migration over the next 18-24 months, which started around September of 2022.

Phase 1 is 97% accomplished as of May 2023.

We are in the early design stages of a new longitudinal record viewer.

What can I expect from MiHIN?

Migration is a complex process. To mitigate impacts and risks, we will be using the following guiding principles:

  • Commitment to communication and transparency
  • Designing for optimal, least stakeholder/client disruptive processes
  • Mitigating risk of downtime happening at wide scale by validating our migration procedure by beginning with a test feed (i.e. using synthetic patient data to test whether the environment is working)
  • Providing opportunities for early adopters to pilot and kick the tires
  • Understanding the best ways/means/time to deploy from our clients’ unique perspectives
  • Lining up with stakeholders’ Smart on FHIR strategy
  • Trainings and change management
What is a test feed?

When a customer initially goes live with a use case, before they start sending real patient data, we set up the interface and establish an active test feed. This enables us to make sure everything is working correctly before we move the customer into production with real patient data.

For many of our clients, the test feed stops getting used after initial testing during onboarding.