EHR connections, cloud, engines, and standards. Top to bottom of a healthcare integration stack.
We've built interfaces to 30+ EHRs. Beyond the major commercial platforms (Epic, Cerner, Meditech, athenahealth, NextGen, Allscripts/Veradigm), the work has spanned ambulatory systems, specialty EHRs, and a long tail of legacy products. The protocols are mostly the same across them. The differences live in vendor-specific quirks, security models, and what's actually achievable in a given customer's deployment.
Diridium served as principal architect and developer of an RPM marketplace platform: a multi-tenant integration system handling enrollment, clinical, and billing data that today serves 500+ healthcare organizations on a single codebase.
Healthcare integration runs somewhere, and the somewhere matters. ePHI handling, VPN connectivity to provider networks, encryption posture, and HIPAA-aligned architecture aren't features you add at the end. We've designed and run integration infrastructure on AWS, Azure, and on-prem, and can advise on the tradeoffs from experience rather than vendor slide decks.
Deployments are scripted, not clicked. The runbook is yours when we leave.
The security side is publicly verifiable: open-source CIS Level 1 benchmark automation for Windows Server and Linux (RHEL, Ubuntu) on github.com/pacmano1. The same controls we deploy on engagement infrastructure.
The integration engine is the middleware that translates between protocols, routes messages, and keeps the data flowing. The three engines we work with cover most of what's deployed in healthcare today: the Open Integration Engine (open-source, what we recommend most often for new deployments), Mirth Connect (the commercial NextGen product, what most teams already have), and BridgeLink (an open-source fork of the Mirth codebase, maintained by Innovar Healthcare).
The work spans engine selection, installation, channel design, legacy migration, HA configuration, and ongoing operations. Diridium sits on the OIE steering committee, is a listed maintainer, and has authored three plugins featured on the project home page (Cache Manager, Channel & Code Template History, Source Code Search). We co-sponsored the OIE TLS plugin with NovaMap Health and are a listed commercial support vendor. Paul is also among the top community contributors on Mirth Connect's forums.
There's no one way healthcare data moves. Old HL7 v2 ADT feeds, modern FHIR APIs, SMART on FHIR for app authorization, IHE profiles for cross-community exchange, Direct Messaging for provider-to-provider, and the occasional weird proprietary REST API. We work in all of them.
Most of the new work right now is FHIR. CMS Interoperability mandates have pushed payers and providers onto FHIR R4 endpoints, and SMART on FHIR is the authorization layer when third-party apps need access to an EHR. We build the gateways, the OAuth flows, and the patient-app integrations to match.
Most healthcare BI work runs on data that someone has to make presentable first. That's our part of the job: designing the pipelines, data models, and extracts that feed analytics tools downstream. We help pick the warehouse, define what's worth reporting, and occasionally prototype a Tableau view to show the team what's possible.
We're not a Tableau or Jaspersoft implementation shop. The work that comes before those tools, getting the data shaped, clean, and arriving on schedule, is the part we own.