Every month we pick a few capabilities and walk through them. What makes it worth the hour is what happens next, when someone in the room knows their own environment better than any slide does.
That happened about twelve minutes in. We had just walked through how to get imaging data out of the platform from an outside system, and an attendee described what his team had already built. Scheduled jobs pull data out on their own, feed a log aggregation system, and track archive, retrieve and route queue depth over time so the team gets an alert when a queue starts backing up. He wanted to know whether there was a designated interface he should be pointing that at instead.
The answer was half yes and half no. For imaging data, yes, and that is exactly what the supported path is for. For what he was actually monitoring, no. Our product manager said so directly on the call: that path returns the imaging record, not the state of the system, so queue depth is a different question. We took it away as a follow-up, which is the more useful outcome anyway.
That is how these sessions work. We bring what we think is useful, and the room tells us where it stops. Here are the three capabilities we walked through.
There is a supported way to ask the platform for imaging data from an outside system, and it is not a query against the database. Which route fits depends on your environment, and your Flight Crew can tell you which one. Whatever sits on the Mach7 side, you build the other side to suit yourself: a script, a command-line tool, a web front end, a reporting tool your team already knows.
The uses people bring us seem unglamorous, and they are constant. Research queries, where someone needs every study of a given procedure type. Daily QA, where the question is which exams have no report, or which reports have no images. A list of studies for a date range. Each of those is a question about the imaging record, which is what the supported path answers.
The limits are worth stating as plainly as the capability, because they are what decide whether this is the right tool for you. The supported path returns the imaging record. It does not report the operational state of the platform.
So if a team has asked you for a scheduled export of imaging data, the supported route is the one that keeps working when internal details change. If what you need is the platform watching itself, this is not the tool, and that is a conversation worth having with us directly.
Information Lifecycle Management, ILM, was the topic that longer-standing customers on the call already knew. It applies changes to many studies in one operation instead of one at a time. Move, copy, purge, compress, route, and update metadata such as an institution name. You can build a rule and schedule it, or build it and run it once by hand for a job that will never repeat. Before it runs, you can preview which studies it is about to touch.
The published version of this sits on our VNA page: manage data across its full lifecycle with rule-based tiering and retention policies, move studies between hot, warm and cold storage automatically, and align retention with your governance and cost goals. ILM turns that sentence into reality.
A good example came up live. Thin slices often have a shorter useful life than the study they belong to. You may not need them for years, but you do need the rest of the study. A rule can find those series and purge only those series, while the study keeps its full retention. The alternative some sites use is storing thin slices in their own segment and letting automated watermark management clear it as it fills. That works, but it gives you less control over what gets deleted and it blurs where a full study begins and ends. Given the choice, keep the study together and use a rule to act on the part of it you want gone.
Two cautions on this front, and the second is particularly important.
The first is the obvious one, and the leader of our service and support organization said it herself on the call: ILM acts at scale, so a wrong selection is wrong at scale. Scope it, test it on a small batch, confirm it did what you expected, then widen it. For anything large, walk it through with your Flight Crew first. That is not a formality. It is a short conversation that costs you very little and occasionally saves a weekend of headaches from unintended consequences.
The second is behavior worth knowing before you write a retention policy at all. A purge on your local archive deregisters the study or object from the database and moves it to a purge folder. The data does not disappear. Permanently deleting what is in that folder is your step, on your schedule. That staging is deliberate, so an aggressive rule against the local archive does not become an unrecoverable one. It also means the disk does not free itself, and your retention policy is only finished once you have decided who owns that folder. Cloud object storage can behave differently. Depending on how yours is configured, a purge there can be a true delete rather than a staged one, so confirm how it behaves before you rely on the purge folder as a safety net.
The third topic describes the problem Mach7 was built to solve, which is probably why it is the one people are most surprised to find they already have.
Any enterprise of significant size ends up with several departments, several PACS, and an archive or two somewhere in the extended enterprise. If you want every system to be able to find and retrieve from every other system, and there is nothing in the middle, then every system has to be configured to know about every other system. You inherit every identifier collision and every difference in how patient ID domains are formatted, in every one of those pairings.
DICOM Q/R Spanning puts the platform in the middle and makes it the front door. A system queries Mach7. Mach7 extends the query to the entities behind it, gathers the responses, and returns one result set. Retrieve requests pass through the same way. The requesting system does not have to know what is back there.
In practice it shows up two ways.
The first is orchestration only. Let’s say you have four PACS and you want them sharing images, but you do not want to move the source of truth. Each one stays the system of record for its own data. You put the platform in the middle, point it at those targets, and nothing migrates.
The second, and more often the real situation, is that Mach7 holds the bulk of the data and is a system of record itself, but not the only one. Some images sit in departments or in systems not yet migrated, and you want them reachable without absorbing them. Here the platform can include itself among the entities it searches. The targets are searched together and the order matters: when a study exists in more than one, the response comes from whichever target sits highest in the order. The local copy wins where there is one, and the outlying systems answer for what only they hold.
Asked how widely this is used, our product manager gave the honest answer, which was that he had not gone through the list. What he did say is that it is a core feature, and that it is the most lightweight way to connect an enterprise: everything has to know about the orchestrator in the middle, rather than everything having to know about everybody else.
There is a simpler way to say that. Federation is not migration. You do not have to move data to make it findable, which means consolidation can happen on a schedule you choose instead of as a precondition.
Three capabilities walked through, and one question we could only half answer. That ratio is about normal, and it is why the session is worth the hour.
If you want something to bring to the next one, the prompt is simple. What does your team maintain by hand, or with something you wrote, that touches the archive? A scheduled extract. A retention job worked through in batches. A set of point-to-point DICOM configurations that grew one archive at a time.
Sometimes there is a supported path and we can point you at it in a couple of minutes. Sometimes there is not, and then we have learned something we needed to know. Both are a good use of the hour.
Your Flight Crew is the place to start. Every customer has one: an Advocate for Customer Experience or a partner director as the account lead, a Flight Controller from the support team, and the product managers who own the roadmap for what you are running. Between sessions, open a ticket at helpdesk.mach7t.com. The tickets that resolve fastest all include the same things: the version, the environment, the actual error text, and screenshots. For critical and system-down issues, call +1.888.876.2247 extension 1.
Our conformance documents are public and ungated at mach7t.com/conformance-statements, including the DICOM, HL7 and IHE integration statements for the platform. If you are working out whether an integration is possible before you ask, start there.
Bring one “can it do this?” to the next session. The thing you have always wondered whether the product could handle. If the answer is yes, we will show you. If it is no, we will say so, and it goes on the list that product actually reads.
Mach7 Enterprise Imaging brings together the Vendor Neutral Archive, the Communication Workflow Engine, the eUnity Enterprise Viewer, and AI enablement, with Flamingo as the next Mach7 offering.
From Pixel to Point of Care.
eUnity is a diagnostic viewer intended to display medical images and associated clinical reports to aid in diagnosis by trained healthcare professionals. Professional and prescription use only. In the United States only, eUnity supports digital pathology whole-slide imaging (WSI) for reference and referral use and is not intended for primary diagnosis. Mammography and digital breast tomosynthesis are not intended for diagnostic interpretation on mobile devices.