How the Medplum Agent connects lab instruments and HL7 v2 feeds to Medplum
A clinical team with lab analyzers, imaging modalities or a legacy HL7 v2 interface needs those systems to reach Medplum without opening inbound firewall ports. The Medplum Agent is the on-premises component that handles these interfaces, and it uses outbound WebSocket connectivity, so the connection starts from inside your network. The agent covers three interface families: HL7 v2, DICOM and ASTM. Once messages arrive, Bots convert them to FHIR resources inside Medplum, so the agent handles transport and the Bots handle meaning.
The connection model shapes the network review more than the device list does. The agent runs on a host inside your network, opens the outbound session to Medplum and keeps it open. Your security team should document which local endpoints the agent reads from or listens on, which outbound destinations it must reach, and whether any proxy or TLS inspection on egress affects the WebSocket session. Decide early whether one agent serves a whole site or one agent serves each network segment that holds clinical devices. That choice determines how many outbound paths you must approve and how far a single host outage reaches.
The three interface families behave differently in the field, so each one needs its own intake. HL7 v2 feeds usually carry message types such as admissions, orders and results, and their local sending rules often differ from the standard. ASTM is common on laboratory instruments, and the physical or network transport depends on the instrument model and firmware. DICOM depends on how each modality is configured for association and application entity titles. Confirm with Medplum which of these interfaces the agent supports for your device models and interface versions, and ask for the documented limits before you commit to a design. Do not assume that a device which sends HL7 or ASTM output will work without a test.
The agent is a path for ePHI, so the HIPAA Security Rule applies to every system that creates, receives, maintains or transmits it. The technical safeguards in 45 CFR 164.312 require unique user identification, and they treat automatic logoff and encryption as addressable specifications that you must assess and document. For the agent, give each instance its own client identity so that access can be revoked without touching other feeds, and plan how those credentials are stored and rotated. If a vendor or hosting provider handles ePHI on your behalf, a business associate contract under 45 CFR 164.314 must be in place. Ask counsel to confirm the contract terms, because HIPAA has no certification that a platform can hold.
Before the build starts, prepare an inventory with one row per device or feed: the device model and interface version, the network path to the agent, a sample message set from the source system, the Bot that maps it, and the clinical owner who signs off the mapping. Then ask the implementation team to show a test message travelling from the device to a FHIR resource in Medplum. Include a failure test in which the outbound session drops, and ask what the agent does with messages during the outage, how it resumes, and how the audit trail records the gap. Those answers will show whether the design can carry live clinical traffic.
What you need before installing the Medplum Agent
The agent sits between devices on your network and a Medplum environment, so the install depends on four things being settled first: a working Medplum target, a host inside your network, a list of interfaces to connect, and named people who own the outcome. Work through the cards in order, and treat any item you cannot confirm as a blocker for the install date.
A running Medplum environment
The agent forwards messages and results into Medplum, so a reachable Medplum environment must exist before installation starts. Medplum can be self-hosted, including through its Community option, or used as a hosted service on one of its listed plans. Check the Medplum pricing page for the plan or license that covers your agent use and expected volume, and confirm the terms in writing with Medplum. Record the base URL and the client identity the agent will use to authenticate.
An on-premises host with outbound access
The agent runs on a machine inside the clinical network, close enough to reach lab analyzers, imaging modalities and HL7 v2 sources. Its connection to Medplum is initiated from the host, so the host needs permission to reach the required destinations through your firewall and any proxy. Ask Medplum for the exact destination hostnames, ports and protocols, and confirm whether any inbound rule is needed before your network team files change requests. Plan for a host that receives patches and accurate time synchronization, since it will run continuously.
An inventory of devices and interfaces
List every instrument, imaging device and interface feed that will connect, with make, model, firmware version, message type and data direction. HL7 v2 feeds, DICOM modalities and ASTM instruments use different transports and message conventions, so the agent configuration and any Bot transformation depend on this list. Confirm with Medplum which protocols and message versions the agent supports, and flag any device whose vendor cannot document its output format. Ask each device owner for a sample message file, since an actual sample is the fastest way to find encoding or segment differences.
Named clinical and IT owners
Assign one clinical owner who can confirm what each device result means, which orders and patients it touches, and who signs off on go-live testing. Assign one IT owner who controls the host, network changes, agent credentials and patching. Name a backup for each role, because interface problems often surface outside working hours. Write each owner into the project plan with explicit decision rights, including who can pause a feed when results look wrong.
Supported operating systems and install packages
The agent is distributed as install packages for specific operating systems, and supported versions change over time. Before you schedule anything, confirm with Medplum which operating systems, versions and package formats are supported, and whether the agent needs a particular runtime on the host. Confirm where the packages come from, how updates are delivered, and whether your change process allows that channel. Record the answers in the install runbook so the host build matches the vendor requirements.
Agreements and shared compliance duties
Device interfaces carry electronic protected health information, so the HIPAA Security Rule applies to covered entities and to their business associates. When a vendor handles that data, a business associate contract must require the vendor to meet the Security Rule and to report security incidents. Medplum lists standard BAA and MSA agreements on its paid cloud plans, and its compliance documentation describes compliance as a shared responsibility. There is no HIPAA certification to request, so ask Medplum for the signed agreement and the evidence behind its claims, and assign your own team the controls for the host, credentials and device network.
How outbound WebSocket connectivity keeps devices behind your firewall
The Medplum Agent works from the inside out. The agent runs on a host in your local network and opens an outbound WebSocket connection to Medplum, so the lab instruments, imaging modalities and HL7 v2 interface engines it serves do not need inbound exposure to the internet or to Medplum. For a security or network team, that is the core decision this model supports: the agent host initiates every session, and the firewall rules are written around that single direction of traffic. Before you rely on this, read the agent documentation to confirm the exact hostnames, ports and protocol details it uses, and record them in your change request so the rules match the documented behavior.
For the network team, the change is concentrated in outbound rules, proxy handling and connection monitoring. You will need an egress rule that allows only the agent host to reach the Medplum endpoints it documents, with no broad outbound allowance for the device segment. If your site sends web traffic through an HTTP proxy, confirm that the agent supports your proxy configuration and that proxy authentication works with a long-lived WebSocket session. Proxies and load balancers often enforce idle timeouts, so test whether the session survives quiet periods and how the agent reconnects after a drop. Monitor connection state and reconnection events, and alert when the agent stays disconnected long enough to affect clinical workflows.
TLS inspection needs a specific check. Many enterprise firewalls and proxies decrypt outbound HTTPS and re-sign certificates with an internal authority. A WebSocket upgrade can fail under inspection, or the agent can refuse a certificate it does not trust. Validate the behavior in your own network with a test agent before cut-over, including the connection, reconnection and a sample message flow. If inspection breaks the session, decide whether to exempt the Medplum endpoints from inspection or to add your internal authority to the agent's trust store, and record that decision with your security team, because it changes what your monitoring can see.
Outbound connectivity does not remove the rest of the security work. The agent still needs a local path to each device, whether serial, TCP or a vendor-specific connection, so the device segment must be reachable from the agent host and segmented from the rest of the network. The agent host itself needs operating system patching, least-privilege service accounts, restricted interactive logins and disk protection, because it holds the path into both the device segment and Medplum. Certificate management also remains yours: confirm how the agent authenticates to Medplum, who owns the credentials, and how renewal and rotation are scheduled and tested before expiry.
Configuring the Medplum Agent in sequence
This sequence takes the agent from an unconfigured host to a verified interface that delivers device and HL7 v2 messages into Medplum. Each step closes with a check you can record, so any failure is isolated to one layer before the next is added. Install options, exact commands and configuration keys should be confirmed against the current Medplum self-hosting and agent documentation before work starts.
Confirm the Medplum project and identity
The integration owner confirms which Medplum project will receive the device data, which environment it belongs to, and who approves its access. Medplum supports client credentials for server-to-server access, so the agent is usually given its own identity instead of a personal user login. Record the project, the identity name and the resources it may write. This step is done when the identity exists in the intended project, authenticates successfully, and its permissions are limited to the resources the interfaces need.
Choose and install the agent
The platform team selects the host on the network segment where the instruments, imaging modalities and HL7 v2 senders can reach it. They then choose the install option that the current Medplum agent documentation supports for that operating system, and run the install steps from that documentation. Confirm the exact commands, service account and file locations there before running anything. The step is done when the agent runs as a service under a dedicated account and starts again after a host restart.
Establish the outbound connection
The agent opens an outbound WebSocket connection from the host to Medplum, so the integration does not need an inbound listener exposed to the internet. The network team confirms the egress rules, proxy settings and certificate trust the host needs, and records them with the change ticket. Check the connection status reported by Medplum or the agent logs. The step is done when the status shows connected, and the agent reconnects after a deliberate network interruption in a test window.
Register each device and endpoint
For every instrument, imaging modality and HL7 v2 feed, the integration team records the device name, interface type, message direction, character encoding, sending application identifiers and the Bot or resource that will handle its messages. DICOM and ASTM settings depend on the device, so confirm each one with the device vendor and the current agent documentation. The step is done when each endpoint appears as registered under the agent with its configuration saved and reviewed by a second person.
Send a test message per interface
From each interface in turn, the clinical owner sends an agreed test message: an HL7 v2 message from the sending system, a DICOM study from the modality or an ASTM result from the instrument. Use synthetic or agreed test records only, unless your privacy and governance approvals allow otherwise. The step is done when the agent logs each message as received and parsed, and its error count for the test is zero. Record the message identifiers so each test can be traced later.
Confirm messages reach Medplum
The integration team checks that each test message produced the expected output in the Medplum project, including the FHIR resources created by any Bot that transforms the message. The clinical owner reviews the mapping for each field against the agreed specification. An audit entry should also record the agent's activity for each message. The step is done when every test record is visible in the project, the mapping is signed off, and the audit entries match the test log.
How HL7 v2, DICOM and ASTM messages map to FHIR resources
This table lists each interface family, the source messages or data elements it carries, the FHIR resources they may populate, who owns the mapping, and how it is validated. Read it as a responsibility map: the team defines the actual mappings from its own interface specifications and test samples. The main takeaway is that device identifiers, patient matching and code system choices need sign-off from clinical and data governance staff before any Bot goes live.
| Interface family | Source message or data element | Target FHIR resource | Mapping owner and validation step |
|---|---|---|---|
| HL7 v2 patient and visit messages | Patient identity and encounter segments from the source system | Patient and encounter-related resources, selected per site | Integration team with clinical informatics. Validate against sample messages and confirm matching rules with data governance. |
| HL7 v2 order messages | Order and request segments sent from the ordering system | Request-type resources, confirmed against the site's interface specification | Integration team with the ordering system owner. Replay recorded order samples and check every required field is populated. |
| HL7 v2 result messages | Observation segments carrying lab or clinical results | Observation and report resources, defined per result type | Lab informatics with integration engineers. Compare transformed results with source values, units and reference ranges on test samples. |
| DICOM modality and study data | Study, series and instance attributes from imaging devices | Imaging-related resources, such as an imaging study resource, to confirm per site | Imaging IT with radiology. Test against sample DICOM objects and confirm patient and accession identifiers survive transformation. |
| DICOM device metadata | Modality station and device identifiers in DICOM attributes | Device resource | Biomedical engineering with data governance. Device identifiers require written sign-off before production use. |
| ASTM instrument results | Result and patient records from laboratory analyzers | Observation and diagnostic report resources, defined per instrument | Laboratory instrument team with clinical staff. Validate with instrument output files, units and flagged or out-of-range values. |
| ASTM instrument identifiers | Analyzer serial, model and quality control records | Device resource and quality control observations, per site | Laboratory instrument team with biomedical engineering. Confirm each analyzer maps to one approved device record. |
| All families: patient matching | Patient identifiers and demographics from each feed | Patient resource and identifier entries | Data governance owns the matching rules. Test duplicate, partial and mismatched identifier cases before cutover. |
| All families: code systems | Local test, device and result codes from each source | Coding elements on every target resource | Clinical terminology lead signs off code system choices. Verify coded values against the agreed code list using test samples. |
Using Medplum Bots to convert device and HL7 messages into FHIR
Medplum Bots are the server-side logic that converts incoming device and HL7 v2 messages into FHIR resources, so the mapping work sits in code your team can test, version and review. Most of the effort is not writing the Bot itself. It is deriving the mapping from each interface's specification and from the messages the instrument, imaging device or legacy system actually sends. Before any build starts, collect a representative set of sample messages from each sending system, including messages from the vendor's documented message profile and examples from live traffic that you are permitted to use. Those samples become the test fixtures for every Bot. Plan for malformed and partial messages from the start. HL7 v2 senders often omit optional segments, repeat fields in ways the profile does not describe, or use local codes. ASTM and device output can arrive with truncated records or unexpected delimiters. For each case, decide whether the Bot maps what it can and flags the gaps, stores the original message unchanged, or rejects the message entirely. Keep the raw message accessible for audit and for replay after a mapping fix. Confirm with the interface owner which fields are mandatory for downstream clinical use, because that decision determines how strict the validation must be.
Treat Bot code like any other production software. Keep it in version control, tag each release, and record which Bot version processed which message. When an interface changes, such as a new message version from a laboratory system or a firmware update on an instrument, the team should be able to deploy the new mapping alongside the old one, replay a set of archived messages against it, and compare the output before switching traffic. Test data should never include live patient records in a non-production environment unless your governance and business associate arrangements allow it. Medplum server upgrades and Bot changes are separate activities, so confirm in the Medplum documentation that the Bot runtime and HL7 components in your target version behave as your tests expect.
Decide in advance which failures are retried and which go to manual review. A transient failure, such as a database or network outage between the agent and the server, usually warrants automatic retry with a bounded number of attempts. A deterministic failure, such as a message that fails validation because a required identifier is missing, will fail again on every retry and should move to a review queue with the raw message and the reason attached. Name the people who own that queue, the response times they commit to, and how corrected messages are re-submitted. Review volume is often the best early indicator that a mapping assumption is wrong. When requesting a quote, ask the implementation partner to list the interfaces in scope, the message types and versions for each, the number of mapping rules expected per interface, and how retry and review behavior will be tested. Specific Bot runtime limits, timeout settings and deployment steps should be confirmed in the Medplum documentation for the version you plan to run, and your team should validate them against your own message volumes before go-live.
Securing agent connections, credentials and clinical data in transit
The agent sits between clinical devices and Medplum, so each control protects a different link in one chain: who the agent is, what it may access, how data moves, and where its secrets live. Confirm each setting against your deployed configuration and chosen identity option, because these controls depend on choices made during installation.
Dedicated agent identity
Give the agent its own Medplum identity rather than reusing a clinician's login or a shared service account. Medplum documents client credentials for server-to-server access, which suits an agent that runs unattended. Confirm that the client serves this agent only, that its scope matches the interfaces it handles, and that a departing staff member or a rebuilt host cannot leave the credential usable. Record a named owner for each identity so revocation has someone accountable.
Least-privilege access policies
Access policies in Medplum determine which resource types the agent identity can read and write. Scope the policy to the message and observation types the agent submits, and deny administrative resources such as project settings and other clients. Test the policy with every real message flow, including Bot-driven transforms, because a policy that allows a manual import may still block a Bot write. Review the policy each time an interface is added or retired.
MFA for human administrators
Administrators who create clients, change access policies or review audit trails hold the highest-impact accounts in this integration. Medplum supports multi-factor authentication, and external identity providers can handle workforce sign-in. Require MFA for every human account with administrative rights, and confirm whether your identity option enforces it in Medplum or at the identity provider. Keep the agent's machine identity out of this flow, since client credentials do not involve an interactive login.
Encryption of connections
Encrypt each hop the agent uses: the outbound connection to Medplum, the API calls it makes, and the links between the agent and each instrument or imaging modality. Outbound WebSocket connectivity keeps inbound ports closed at the clinical network edge, but it does not protect traffic on the local device segment. Confirm the TLS versions and certificate validation in the agent configuration, and check whether each device link supports TLS or needs an isolated segment or secured tunnel.
Host hardening and egress control
The agent server handles protected health information in memory and on disk, so manage it as a clinical system. Apply your operating system hardening baseline, remove unused services, restrict administrative access to named accounts, and patch on a schedule your change process approves. Add an outbound allowlist so the host reaches only the Medplum endpoint, time sources and update channels you have approved. Test the agent release you deploy, and track the security patch targets Medplum publishes for its own server.
Secret storage and rotation
Client secrets and any credentials for device or database access should not sit in configuration files readable by general users. Store them in a secrets manager or a host-protected store with file permissions limited to the agent's service account, and confirm that logs and crash dumps do not echo them. Define a rotation procedure before go-live, including how the agent is reconfigured without interrupting interfaces, and confirm how revoked credentials appear in audit trails.
Why device messages fail to arrive and how to fix them
This table lists the failures teams most often hit when HL7 v2, DICOM or ASTM messages from a device do not reach Medplum, with the likely cause and a first fix for each. Work through the symptoms in order, starting with connectivity, because later checks depend on the agent being connected. Confirm log file locations, service commands and configuration keys in the Medplum Agent documentation before you change anything in production.
| Symptom | Likely cause | Fix |
|---|---|---|
| Agent cannot establish the outbound connection | Proxy settings or firewall rules block the outbound WebSocket connection to Medplum | Allow outbound WebSocket traffic from the agent host, set proxy details in the agent configuration, then review the agent logs |
| Device sends but nothing appears in Medplum | Endpoint not registered in Medplum, or interface settings such as port, message type or character set differ from the device | Register the endpoint, match the device's port and message settings exactly, then send one test message while watching the agent log |
| Messages arrive but fail transformation | Sample data includes segments, fields or codes that the Bot logic does not handle | Capture the failing message, add handling for the uncovered segment or code, and retest against the full sample set |
| Duplicate or out-of-order results | No idempotency key or sequencing rule, so resends and retries create repeat or stale resources | Derive a stable identifier from the message control ID or order number, and define how late-arriving results update existing records |
| Expired or rotated credentials | Client credentials or agent tokens were rotated or expired, so the agent is rejected when it connects | Check credential expiry dates, reissue the agent credentials, update the agent configuration and restart the agent service as documented |
| Time skew or character encoding problems | Agent host clock drifts from the server, causing timestamp or token rejection, or the device sends a character set the agent does not expect | Sync the host clock with a time service, confirm the device's character encoding, and test with accented characters in a sample message |
What HIPAA requires for device data and what Medplum provides
The HIPAA Security Rule applies to covered entities, meaning health plans, health care clearinghouses and covered health care providers, and to their business associates, for all electronic protected health information they create, receive, maintain or transmit (45 CFR 164.302). An HL7 v2 order, a DICOM image or an ASTM result from a lab analyzer is ePHI as soon as it carries patient identifiers, so the interface traffic handled by the Medplum Agent is in scope even though no clinician opens it in a browser. Before the first device is connected, your compliance lead should map each interface, every host running the agent, and every system that stores messages, including logs and retry queues on the agent host.
The technical safeguards in 45 CFR 164.312 are the controls most directly tied to the agent. Unique user identification is required, so each person and each service that can reach the Medplum server should have an identity of its own. The agent should authenticate with a dedicated client credential instead of a shared administrator login. The emergency access procedure is also required, which means a documented way to reach interface data when the normal path fails, such as during a device or network outage at a laboratory. Automatic logoff and encryption are addressable, so you must decide whether each applies and document the reason for any decision. For the agent, confirm that the outbound WebSocket connection uses TLS, that disks holding PostgreSQL data and the agent host are encrypted, and that interactive Medplum sessions time out.
A business associate contract under 45 CFR 164.314(a)(2)(i) must require the vendor to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents to you. Medplum states that its paid cloud plans include standard BAA and MSA agreements, so a hosted deployment has a contractual path that you should confirm for your plan before signing. Self-hosting changes the picture. If your own infrastructure runs the server, the agent and the database, your organization carries the hosting risk, and any cloud provider that stores or processes ePHI needs its own agreement. Ask DeployOpen whether a business associate agreement is needed for the work you scope, and what it would cover.
Compliance is a shared responsibility between Medplum and its customers, as Medplum's compliance documentation states, and HIPAA has no certification. HHS has said that no Security Rule standard requires an entity to certify compliance and that private certifications do not prevent HHS from later finding a violation. Treat any vendor claim of HIPAA certification with caution and ask for the specific evidence behind it. Audit trails are the evidence your team must collect and review. Confirm which events the Medplum server and the agent record, such as message receipt, Bot execution, agent connections and configuration changes, then set a retention period and review cadence with your privacy officer. DeployOpen prepares this evidence and documents the controls, but it does not issue audit reports. An independent auditor or your own compliance function makes that determination.
Questions buyers ask before hiring outside help for Medplum Agent integrations
What drives the cost of a Medplum Agent integration project?
The main cost drivers are the number of device interfaces in scope, the complexity of mapping HL7 v2, DICOM or ASTM content to FHIR, the testing each sender requires, and your Medplum hosting choice. Medplum's pricing page lists hosted plans of Free, Production at $2,000 per month, Premium at $6,000 per month and a custom-priced Enterprise plan, and it lists self-hosting as a free Community option or a custom-priced Enterprise Self-Hosted option. Those platform fees are paid to Medplum and are separate from the implementation work, which is paid to a partner or your own staff. Recurring costs include the platform subscription, hosting, agent maintenance and upgrades. Ask every quote to separate one-time build work from recurring run work.
How long does a Medplum Agent integration take?
Duration depends mainly on how many interfaces are in scope, how many message types each one sends, and how quickly your team can supply samples and sign-offs. Installing the agent is often a smaller share of the work than mapping messages to FHIR resources and testing against each device or sender, including error cases. Upgrade planning can also add time. Medplum's upgrading guide says self-hosted servers must move through each minor version in sequence, and post-deploy data migrations can run for hours or days on large datasets. DeployOpen does not publish a standard timeline. The duration for your project is agreed in writing during scoping, based on the interface list and the inputs your team provides.
What must our team provide before an agent integration starts?
Your team should provide four inputs. First, a device and interface inventory listing make, model, firmware version, protocol and message direction for each source. Second, sample messages or files from each sender, including malformed or unusual cases, with protected health information removed or handled under your HIPAA policies. Third, network approvals for the outbound connection from the agent host to Medplum, covering firewall rules, proxy settings and DNS. Fourth, clinical sign-off from the laboratory, imaging or clinical owners, who confirm code mappings, result statuses and units. Ask the partner to list each input with an owner and a due date in the statement of work.
Can our internal team build a Medplum Agent integration without outside help?
A capable internal team can build one, provided it has engineers who understand the interface standards in use, FHIR data modeling, Node.js and TypeScript for Bots, and Linux or container operations. The harder question is capacity. The work includes device testing, clinical validation, security review and documentation, and these tasks often compete with day-to-day operations. Before deciding, compare your skills against the interface list, confirm that your team can reach the devices and test environments, and plan for support after go-live. Medplum's documentation and open-source repository give your engineers a starting point. An outside partner can take on build, testing or runbook work while your team keeps ownership of the system and the decisions behind it.
What does a fixed-scope quote for this work cover?
A fixed-scope quote lists what is included and excluded. Most DeployOpen engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. A useful quote names the interfaces, device types and message flows in scope, the Medplum deployment target, the mapping and Bot deliverables, the test cases and acceptance criteria, the documentation, and the handover. It should also state the assumptions about inventory, samples, network approvals and clinical sign-off that your team owns, and explain how late inputs affect the schedule. Ongoing upgrades, support and continuous testing are available as separate retainers, so the quote should show one-time and recurring work apart. Medplum subscription or license fees, where they apply, are not part of implementation work and should be listed separately. Ask which changes would require a new quote.
What are the HIPAA obligations for a Medplum Agent integration?
The HIPAA Security Rule applies to covered entities and their business associates for all electronic protected health information they create, receive, maintain or transmit. An agent that carries HL7 messages or DICOM objects handles ePHI, so its connection, logs and any stored messages fall within scope. The technical safeguards in 45 CFR 164.312 include unique user identification and emergency access procedures, which are required, and automatic logoff and encryption specifications, which are addressable. A partner that handles ePHI needs a business associate contract under 45 CFR 164.314. HHS states that no Security Rule standard requires certifying compliance, so there is no HIPAA certification to buy. Medplum's compliance documentation describes compliance as a shared responsibility. Confirm with your compliance lead which controls you must evidence and which parts Medplum and your partner cover.
What breaks most often in HL7, DICOM and ASTM agent connections?
Most failures come from changes outside the interface design. Common causes include network path changes, expired certificates or credentials, firewall updates, clock drift on devices, and character encoding differences. HL7 v2 senders often populate optional segments and fields differently, so a message that passed testing can fail when a new value appears. DICOM and ASTM devices can change record layouts or transfer behavior after a firmware update. Test error messages and unusual values, not only the expected path, and keep a replay set of samples for regression checks. Monitor agent connectivity and message backlog, and alert on rejected messages. Confirm the acknowledgment behavior of each sender before go-live, and document who responds when a device changes after handover.
How DeployOpen scopes, builds and supports Medplum Agent interfaces
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Medplum Agent for HL7 v2, DICOM and ASTM interfaces, we start from the instruments, imaging devices and message feeds you already run, then build the agent, Bots and audit trail against them in your environment.
How we scope
- The written scope lists each lab instrument, imaging device and HL7 v2 feed, with its message types and direction.
- It records which Agent install option suits each host network, operating system and change-control process you follow.
- Engagements are fixed-scope and agreed in writing before work starts, with ongoing support available as a retainer.
How we build
- We confirm outbound WebSocket connectivity from each site to the Medplum server through your approved firewall rules.
- Bots that map HL7 v2, DICOM and ASTM messages to FHIR are written and tested on sample traffic.
- Audit trail settings, retention and log access are configured and reviewed with your security and compliance team.
How we hand over
- Agreed deliverables can include the installed agent configuration, Bot source, mapping notes and test records.
- Runbooks cover agent restart, certificate and credential rotation, and what to check when a device stops sending.
- Your team receives the documentation and a walkthrough so your staff can run the interfaces day to day.
How we support
- Retainers can cover monitoring of Agent and Bot health, plus patching and upgrades to the Medplum release you run.
- Medplum upgrades run one minor version at a time, so each step is planned, tested and documented.
- Confirm with Medplum which Agent version and security patch windows apply to the release your site runs.
