Healthcare · Managed platform (Mirth / Rhapsody)

Integration Engine

Your HL7 and FHIR interfaces built, monitored and kept running on Mirth or Rhapsody

Overview

What you are buying

Moraph licenses, implements and runs your clinical integration engine on Mirth Connect or Rhapsody, the engines that move HL7 v2 messages, FHIR resources and documents between your EHR, labs, radiology, billing and partners. We build and test each interface, watch the message flows around the clock, and work queued and failed messages with your teams. Your organization decides which data flows where; every interface change is reviewed, approved and recorded.

The problem it solves

Hospitals and health systems depend on dozens or hundreds of interfaces, many built years ago by people who have since moved on. When an ADT feed stops or a lab result fails to file, the first sign is often a clinician asking where the result is. Interface knowledge lives in a few heads, changes are made directly in production, and nobody can say quickly which systems receive which patient data. Meanwhile, FHIR APIs and new partner connections keep being added on top.

  • Interface failures are noticed by clinicians before they are noticed by IT
  • Mappings and routing rules are undocumented and depend on a few people
  • Changes go straight to production without a tested, approved release
  • It is hard to show which systems and partners receive which PHI

Who uses it

  • Hospitals and health systems running Mirth Connect or Rhapsody, or planning to
  • Integration and interface teams who are short of people or after-hours cover
  • CIOs and IT directors who need a dependable record of every interface
  • Privacy and security officers who must account for where PHI flows
  • Health information exchanges, labs and physician groups connecting to hospital systems

Requirements it supports

HIPAA Privacy Rule (45 CFR Part 160 and Part 164, Subpart E)HIPAA Security Rule (45 CFR Part 164, Subpart C)HIPAA transaction and code set standards (45 CFR Part 162)21st Century Cures Act information blocking rule (45 CFR Part 171)CMS Interoperability and Patient Access final rule (CMS-9115-F)Confidentiality of Substance Use Disorder Patient Records (42 CFR Part 2)

The product supports these requirements; meeting them remains your organization’s responsibility.

Responsibilities

Who is responsible for what

NextGen Healthcare (for Mirth Connect) or Rhapsody provides the engine software, Moraph builds and runs your interfaces on it, and your organization owns the connected systems, the data and every decision about where it goes.

AreaMoraphNextGen Healthcare or RhapsodyYour organization
LicensingResells the engine licence and support and tracks renewals with youSets licence terms, editions and support entitlementsAgrees scope and signs the order
Engine hosting and availabilityOperates the engine servers in Moraph cloud or your environment by agreement, and monitors their healthSupplies the software and fixes product defects under its own support termsProvides network paths and firewall rules to connected systems, and runs any on-premises hosts not operated by Moraph
Interface buildDesigns, builds and tests channels, mappings and routes to an agreed specificationProvides the engine, connectors and development toolsApproves specifications and provides test systems and sample messages
Access to the engineManages engine user accounts and roles through your identity providerProvides the engine's user and role modelApproves who may view message content
Monitoring and alertsWatches queues, errors and connection status around the clock and triages alertsProvides the engine's dashboards, logging and alerting featuresReceives escalations and decides clinical or operational impact
Message errorsInvestigates failed messages, corrects interface faults and reprocesses messages once the fix is agreedNo roleCorrects source data in the sending system and confirms clinical follow-up
Incident responseRestores service on the integration layer and coordinates with system ownersResolves engine defects reported through supportLeads incidents affecting patient care and makes any breach determinations and notifications
ChangesDeploys interface changes through a reviewed, tested release processPublishes engine releasesApproves changes and production releases
Engine upgrades and patchesPlans and applies engine, Java and operating system updates and regression-tests interfacesPublishes versions, security fixes and support timelinesAgrees maintenance windows
Connected systemsBuilds against the interfaces each system exposesNo roleOwns the EHR, lab, radiology and other systems and their vendors' interface work

See how it works

A short walkthrough

Illustrative screens of how Moraph runs the service, with fictional sample data. They are not screens of Mirth / Rhapsody itself, which belongs to its vendor.

  1. Step 1

    Onboarding tracker

    During onboarding, Moraph tracks each interface's discovery, migration and cutover with an owner on each side.

    InterfaceMoraph ownerClient ownerStatus
    ADT to lab systemIntegration engineerLab systems analystDone
    Lab results to EHRIntegration engineerEHR analystIn test
    Radiology orders to RISIntegration engineerRadiology analystIn test
    Charges to billingIntegration engineerRevenue cycle analystWaiting on sample messages
    Results to Example Physician Group (fictional)Integration engineerPrivacy officerAwaiting PHI approval
    During onboarding, Moraph tracks each interface's discovery, migration and cutover with an owner on each side.
  2. Step 2

    Interface record

    Each interface has one record: what it carries, who owns each end, what it is approved for and how it is watched.

    IF-0142 · Lab results to EHR

    Source
    Laboratory information system
    Destination
    EHR
    Message types
    ORU^R01
    Business owner
    Lab systems analyst
    PHI carried
    Patient identifiers, results
    Importance
    Critical

    Monitoring thresholds

    • Alert if no messages for 15 minutes during daytime hours
    • Alert if more than 5 messages fail in an hour
    • Alert if the queue holds more than 200 messages
    Each interface has one record: what it carries, who owns each end, what it is approved for and how it is watched.
  3. Step 3

    Change request

    A change reaches production only after testing and your recorded approval.

    CR-2231 · Add new result code mapping to IF-0142

    1. Request raised for new test codesLab systems analyst
    2. Mapping updated in developmentMoraph integration engineer
    3. Tested with 40 sample messages; results attachedMoraph integration engineer
    4. Peer review completedMoraph senior engineer
    5. Readiness confirmed for EHREHR analyst
    6. Change approved for Tuesday windowInterface owner
    7. Deployed; first live messages checkedMoraph integration engineer
    A change reaches production only after testing and your recorded approval.
  4. Step 4

    Alert triage

    When an interface goes quiet or messages fail, Moraph triages, fixes what is in the engine and brings in the system owner for the rest.

    No messages on radiology orders interface

    1. Silence alert raised on IF-0157Monitoring
    2. Connection to RIS found refusedMoraph integration engineer
    3. Radiology analyst and service desk notifiedMoraph integration engineer
    4. RIS listener restarted by radiology teamRadiology analyst
    5. Queued orders delivered; delivery confirmedMoraph integration engineer
    6. Added to monthly service reviewMoraph integration engineer
    When an interface goes quiet or messages fail, Moraph triages, fixes what is in the engine and brings in the system owner for the rest.
  5. Step 5

    Failed message queue

    Failed messages are worked to an outcome, with source-data fixes sent back to the system that owns them.

    MessageInterfaceErrorCauseStatus
    MSG-884120Lab results to EHRUnknown patient identifierSource dataWith lab analyst
    MSG-884133Charges to billingInvalid charge codeMappingFixed; reprocessed
    MSG-884151ADT to lab systemMissing visit numberSource dataCorrected; reprocessed
    MSG-884167Results to Example HIE (fictional)Connection timeoutNetworkDelivered on retry
    Failed messages are worked to an outcome, with source-data fixes sent back to the system that owns them.
  6. Step 6

    Monthly service review

    Each month Moraph and your interface owner review volumes, incidents, changes and what is coming next.

    Monthly service review · Example Regional Health (fictional)

    Interfaces in service
    84
    Messages processed
    6.2 million
    Incidents
    3, all resolved
    Changes deployed
    11
    Open requests
    7

    Agenda items

    • Recurring patient identifier errors from lab system
    • Engine security update planned for next window
    • Two new partner feeds awaiting PHI approval
    Each month Moraph and your interface owner review volumes, incidents, changes and what is coming next.

Workflows

The principal workflows

  1. Build

    Each new interface starts as a written specification: source, destination, message types, triggers, mappings and what happens when a message fails. Moraph builds it in a development environment and tests it with your sample messages.

    • Request logged with the business owner and the systems involved
    • Specification agreed, including message types, mappings and error handling
    • Channel or route built in the development environment
    • Tested with sample and edge-case messages, results recorded
    • Specification and test evidence attached to the interface record
  2. Release

    Interfaces move to production through a change request that your change board or interface owner approves, with a planned cutover and a way back.

    • Change request raised with the specification and test results
    • Receiving system owner confirms readiness for live messages
    • Your approver signs off the change and the window
    • Moraph deploys and watches the first live messages
    • Interface inventory and documentation updated
  3. Monitor

    Queues, error counts, connection status and message volumes are watched continuously by Moraph's follow-the-sun operations team, with thresholds set for each interface's importance.

    • Thresholds set per interface for queue depth, errors and silence
    • Alerts routed to the on-shift Moraph integration engineer
    • Alert triaged against the runbook for that interface
    • System owner contacted where the fault is outside the engine
    • Alert closed with cause and action recorded
  4. Resolve

    Failed and queued messages are worked to an outcome. Faults in the interface are fixed by Moraph; faults in source data go back to the sending system's owner, and reprocessing happens only once the fix is agreed.

    • Failed messages grouped by interface and error
    • Cause identified as interface, network or source data
    • Fix applied or source-data correction requested
    • Messages reprocessed with your agreement and delivery confirmed
    • Recurring causes raised at the monthly service review

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Interface owner

Integration manager, interface team lead, director of application services

Owns the integration program on your side: decides what gets built, approves changes and holds Moraph to the agreed service.

Sees

  • The full interface inventory with owners and status
  • Open requests, changes, incidents and their history
  • Monthly service review reports

Does

  • Prioritizes interface requests
  • Approves specifications and production changes
  • Agrees maintenance windows for upgrades
  • Assigns application owners to each interface
  • Chairs the monthly service review

Cannot

  • Make production changes outside the release process
  • Approve access to message content on the privacy officer's behalf
Approvals
Approves specifications, production changes and maintenance windows; urgent changes can be approved by a delegate you name.
Notified about
Changes waiting for approval, incidents affecting important interfaces, and upgrade plans.

Application analyst

EHR analyst, lab systems analyst, radiology systems analyst, revenue cycle systems analyst

Represents a connected system: confirms what it sends and expects, and fixes source data when messages fail because of it.

Sees

  • Interfaces that touch their system
  • Errors and incidents involving their system
  • Specifications and test results for their interfaces

Does

  • Provides sample messages and test accounts
  • Confirms the receiving system is ready for a change
  • Corrects source data and asks for reprocessing
  • Validates test results from their side

Cannot

  • Approve production changes unless named as an approver
  • See message content for interfaces outside their area
Approvals
Their readiness confirmation is required before a change to their system's interfaces is released.
Notified about
Errors caused by their system's data, changes affecting their interfaces, and planned downtime.

Moraph integration engineer

Moraph integration engineer, interface developer, operations engineer

Builds and runs your interfaces on the engine, under your approvals and Moraph's change process.

Sees

  • Engine configuration, channels and routes
  • Message queues, errors and logs needed to diagnose faults
  • The interface inventory and runbooks

Does

  • Builds and tests interfaces in development and test environments
  • Deploys approved changes to production
  • Triages alerts and works failed messages
  • Applies engine and platform updates
  • Keeps documentation and the inventory current

Cannot

  • Deploy to production without an approved change, except emergency fixes under the agreed emergency process
  • Grant engine access to anyone without your approval
  • Change which partners or systems receive PHI without approval
Approvals
Their production changes are approved by your interface owner and peer-reviewed within Moraph before release.
Notified about
Alerts on any monitored interface, approved changes ready to deploy, and vendor security notices.

Privacy or security officer

HIPAA privacy officer, information security officer, compliance officer

Makes sure each data flow has a purpose and an agreement behind it, and that only the right people can see message content.

Sees

  • Which systems and partners receive which PHI
  • Who has access to message content
  • Access reviews and the audit trail

Does

  • Approves new PHI flows to partners
  • Approves roles that can view message content
  • Runs periodic access reviews
  • Leads breach assessments where an interface misroutes data

Cannot

  • Change interfaces or engine configuration
  • Edit the audit trail
Approvals
Approves new external PHI flows and access to message content.
Notified about
New partner connections waiting for approval, misrouting incidents, and access reviews due.

Service desk analyst

IT service desk analyst, clinical applications support

Answers questions such as whether an order or result was sent, without changing anything.

Sees

  • Message status by order, encounter or patient where their role allows
  • Open incidents and their status

Does

  • Traces a message to confirm delivery
  • Raises incidents with the details the engineer needs
  • Updates the caller when an incident is resolved

Cannot

  • Reprocess or edit messages
  • See full message content unless your privacy officer allows it
Approvals
None; their access is granted by the interface owner and approved by the privacy officer.
Notified about
Status updates on incidents they raised.

Auditor (read-only)

Internal auditor, compliance reviewer, external assessor under temporary access

Reviews how interfaces are controlled without being able to change them.

Sees

  • The interface inventory and PHI flow register
  • Change records with approvals and test evidence
  • Access reviews and the audit trail

Does

  • Reads and exports records within their scope
  • Samples changes for approval evidence

Cannot

  • Change, approve or reprocess anything
  • Keep access after its end date
Approvals
Their access is approved by the interface owner or privacy officer, with a scope and an end date.
Notified about
Nothing by default.

Engine administrator

Your IT administrator, where you keep administrative access

Holds break-glass or shared administrative access on your side where your policies require it.

Sees

  • Engine users, roles and settings
  • The record of permission changes

Does

  • Reviews and removes engine accounts
  • Uses break-glass access under your procedure
  • Runs access reports

Cannot

  • Bypass the change process for routine changes
  • Delete audit records
Approvals
Granting message-content access is approved by the privacy officer.
Notified about
Access reviews due and break-glass use.

Permissions at a glance

ActionIntf ownerApp analystMoraph engPrivacyService deskAuditorAdmin
View interface inventoryView onlyView onlyFullView onlyView onlyView onlyView only
Request a new interfaceFullFullNo accessNo accessNo accessNo accessNo access
Build and test interfacesNo accessNo accessFullNo accessNo accessNo accessNo access
Approve a production changeApprovesNo accessNo accessNo accessNo accessNo accessNo access
Deploy to productionNo accessNo accessFullNo accessNo accessNo accessNo access
Approve a new external PHI flowNo accessNo accessNo accessApprovesNo accessNo accessNo access
Trace message statusView onlyOwn work onlyFullView onlyView onlyNo accessView only
View full message contentNo accessOwn work onlyFullNo accessNo accessNo accessNo access
Reprocess failed messagesApprovesOwn work onlyFullNo accessNo accessNo accessNo access
Grant engine accessNo accessNo accessNo accessApprovesNo accessNo accessFull
View audit trailView onlyNo accessView onlyView onlyNo accessView onlyView only
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Moraph engineers build and deploy, but your organization approves: nobody at Moraph moves a change to production or opens a new PHI flow to a partner without your recorded approval, except emergency fixes under the agreed emergency process, which are reviewed afterwards.
  • Access to full message content is limited to the people who need it to diagnose faults. Service desk staff see status, not content, unless your privacy officer decides otherwise.
  • Engine accounts follow your identity provider's groups, and access reviews list each person's roles for periodic certification by your privacy or security officer.
  • Auditors get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

Interface inventory

Every channel or route recorded with its source, destination, message types, business owner and the PHI it carries.

HL7 v2 messaging

The engine receives, transforms and routes HL7 v2 messages such as ADT, ORM, ORU, SIU, MDM and DFT over MLLP, files and web services.

FHIR interfaces

The engine exposes and consumes FHIR resources, so newer applications and partners can connect alongside existing HL7 v2 feeds.

Mapping and transformation

Code sets, identifiers and message structures translated between systems, with each mapping documented and versioned.

Round-the-clock monitoring

Queue depth, errors, failed connections and unexpected silence on each interface watched by Moraph's operations team.

Error queue management

Failed messages worked to an outcome, with the cause, the fix and any reprocessing recorded.

Controlled releases

Separate development, test and production environments, with every production change approved and recorded.

Runbooks per interface

What each interface does, who owns each end and what to do when it fails, written down rather than remembered.

Message search

Authorized staff can trace a message by patient, encounter or order number to see where it went and when.

Partner connections

Secure connections to labs, HIEs, payers and physician practices set up and documented, with each partner's data scope approved by you.

Upgrade management

Engine, Java and operating system updates planned, regression-tested against your interfaces and applied in agreed windows.

Monthly service review

Volumes, incidents, open changes, recurring errors and upcoming upgrades reviewed with your integration owner each month.

Integrations

How it connects to your systems

Connects toHowWhat flows
EHRAdmissions, orders, results, documents, scheduling and charges exchanged with your EHR through its standard HL7 v2 and FHIR interfaces.In and out: ADT, orders, results, documents, scheduling and charge messages.
Laboratory and pathologyOrders to and results from your laboratory information system and reference labs.Out: orders. In: results and specimen status.
Radiology and imagingOrders, results and report status between the EHR, RIS and PACS.Out: orders. In: reports and exam status.
Revenue cycleCharges and patient account updates to your billing and revenue cycle systems.Out: charge and account messages.
Health information exchanges and partnersConnections to HIEs, physician practices and other partners you approve, over secure transport.In and out: the message types and data scope you approve for each partner.
Public health reportingFeeds such as immunization, electronic lab reporting and syndromic surveillance routed to the agencies your organization reports to.Out: the reportable messages your configuration selects.
Single sign-onEngine and console users sign in through your identity provider where the engine supports it.In: user identity and group membership for role assignment.
IT service managementIncidents and change requests raised in, or linked to, your service management tool.In and out: incident and change records and status.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Business associate agreement

Moraph signs a business associate agreement with you, since running the engine involves access to PHI.

Role-based access

Who can view message content, change interfaces or reprocess messages follows their role and is reviewed periodically.

Encrypted transport and storage

Connections use encrypted transport where the connected systems support it, and stored messages are encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.

Complete audit trail

Changes, approvals, reprocessing and access to message content are logged with the person and time.

Tested releases

Moraph's security testing gates every release of its own tooling, and interface changes go through test before production.

Data residency

Where Moraph hosts the engine, data stays in the region you choose: the United States, the United Kingdom or Australia.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Interface health

For interface owner and Moraph engineers

Each interface's status, queue depth, errors and time since its last message.

Break down by
Interface, Connected system, Importance, Status
Delivered as
Live dashboard
Used for
Spotting interfaces that have stopped or are falling behind.

Failed messages

For moraph engineers, application analysts

Messages that failed, why, and whether they were fixed, reprocessed or closed.

Break down by
Interface, Error type, Cause, Outcome
Delivered as
Live dashboard; CSV export
Used for
Working errors to an outcome and finding source-data problems.

Message volumes

For interface owner

Messages processed per interface over time, against the usual pattern.

Break down by
Interface, Message type, Period
Delivered as
Live dashboard; CSV export
Used for
Capacity planning and noticing unusual drops or spikes.

Service management

Incidents

For interface owner and IT leadership

Incidents raised, their cause, impact, time open and actions taken.

Break down by
Interface, Cause, Severity, Period
Delivered as
Monthly report; CSV export
Used for
Reviewing reliability and recurring problems at the service review.

Change log

For interface owner, change board, auditors

Every production change with its request, test evidence, approver and deployment time.

Break down by
Interface, Change type, Approver, Period
Delivered as
Live view; PDF and CSV export
Used for
Evidencing that changes were tested and approved.

Request backlog

For interface owner

Interface requests by stage, from specification to release, with their age.

Break down by
Stage, Requester, Priority
Delivered as
Live view; monthly report
Used for
Setting priorities and planning work.

Monthly service review pack

For interface owner and IT leadership

Volumes, incidents, changes, open risks and planned upgrades for the month.

Break down by
Period, Interface group
Delivered as
PDF; monthly meeting
Used for
Reviewing the service and agreeing next steps.

Privacy and security

PHI flow register

For privacy and security officers

Which systems and external partners receive which PHI, under which approval.

Break down by
Destination, Data category, Approval, Partner
Delivered as
Live view; PDF and CSV export
Used for
Answering where patient data goes and supporting risk analysis.

Access review

For privacy officer and administrators

Each person's engine roles and whether they can view message content.

Break down by
Role, Organization, Last sign-in
Delivered as
On request; CSV export
Used for
Periodic certification of access.

Audit trail extract

For auditors and privacy officer

Who changed, approved, viewed or reprocessed what, and when, for a selected interface or period.

Break down by
Interface, User, Action, Date range
Delivered as
On request; CSV and PDF export
Used for
Answering audit and investigation requests.

Platform

Engine version and patch status

For interface owner and security officer

Engine, Java and operating system versions in each environment, with pending updates and vendor support status.

Break down by
Environment, Component, Status
Delivered as
Monthly report
Used for
Planning upgrades and showing that security fixes are applied.

Exports, access and evidence

  • Operational dashboards come from the engine's own monitoring and Moraph's service tooling; service management reports are produced by Moraph for the monthly review.
  • Reports can be exported to CSV, and summary and evidence reports to PDF.
  • Reports respect each viewer's role: application analysts see their own system's interfaces, and message content never appears in reports.
  • Incident and change data can be shared with your service management tool so it sits alongside your other IT reporting.
  • Running and exporting an evidence report is itself recorded in the audit trail.

Deployment

Where and how it runs

Moraph cloud

The engine runs in Moraph's hosted environment in the United States, United Kingdom or Australia region, with secure connections to your systems.

Your data center or cloud account

Where systems must stay on your network, the engine runs in your environment and Moraph operates it by agreement.

Your existing licence

Where you already license Mirth Connect or Rhapsody, Moraph takes over build and operation, subject to the vendor's terms.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Discovery and inventory

We document every existing interface: source, destination, message types, mappings, owners and the PHI it carries. We need access to the current engine and time with your interface and application teams.

Environment setup

Development, test and production environments are set up in Moraph cloud or your environment, with single sign-on, roles and monitoring.

Migration or takeover

Where you are moving engines or versions, interfaces are rebuilt or migrated and tested against sample messages; where you already run the engine, Moraph takes over operation in stages.

Monitoring baseline

Thresholds for queues, errors and silence are agreed per interface, along with who is called for what.

Runbooks and processes

Runbooks, change approval, emergency change and reprocessing rules are written down and agreed with you.

Cutover and handover

Interfaces move in planned groups with the receiving systems' owners on hand, and the service review rhythm begins.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • Moraph is not the vendor. NextGen Healthcare (Mirth Connect) and Rhapsody own their engines, and their own service commitments, support terms, roadmaps and outages apply.
  • Licences are subject to the vendor's terms, which may limit the editions, connectors or environments available to you.
  • Moraph does not operate or change your EHR, lab, radiology or other connected systems; interfaces are limited by what those systems expose, and their vendors' work is arranged by you.
  • Decisions about which data goes to which system or partner, and the agreements behind them, are your organization's.
  • Moraph fixes interface faults but does not correct clinical data in source systems; that stays with the system's owner.
  • Clinical follow-up when a result or order is delayed is your organization's responsibility.
  • Breach assessments and notifications after a misrouting incident remain your organization's responsibility, with Moraph's support.
  • This service manages Mirth Connect and Rhapsody; other integration engines are not included.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. Pick three of your most important interfaces and ask Moraph to document them as they would in discovery
  2. Review a sample runbook and check that your on-call staff could follow it
  3. Walk through a change from request to approved production release
  4. Ask how a silent interface would be noticed and who would be called
  5. Review the PHI flow register format with your privacy officer
  6. Check the responsibilities split against your current vendor and support contracts

Questions

Frequently asked questions

Do we have to choose between Mirth Connect and Rhapsody?

Moraph operates either. Where you already run one, we usually keep it; for a new engine, the choice follows your licensing preferences, scale and the connectors you need, and we discuss it during scoping.

Can Moraph take over interfaces someone else built?

Yes. Discovery documents each existing interface first, and anything that cannot be explained is flagged before Moraph takes responsibility for it.

Who can see patient data in messages?

Only the roles you approve. Moraph engineers see message content when they need it to diagnose a fault, under the business associate agreement, and that access is logged.

What happens outside business hours?

Moraph's operations team works follow-the-sun, so alerts are triaged at any hour and your on-call contacts are called according to the agreed escalation rules.

How is it priced?

The engine licence follows the vendor's terms, and Moraph's implementation and managed service are priced separately, usually by the number and complexity of interfaces. See Working with Moraph for what drives a quotation.

Does this help with information blocking rules?

It can support the exchanges your organization decides to offer, and it records where data flows. Decisions about requests and exceptions under the information blocking rule remain yours.

Next steps

Evaluate Integration Engine

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Integration Engine guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Integration Engine support guide.