Infrastructure before devices
A test study reached the archive, attached to the right encounter, and surfaced in the record.
This is the phase that inverts the standard sequence, and it is the reason this playbook is worth reading.
The dependency chain runs in one direction and does not negotiate. Workflow architecture determines whether images reach an archive. Archived images determine whether documentation can reference a stored study. Documentation determines whether a claim is defensible. Claims determine whether the program has a financial record. The financial record determines whether the program survives its second budget cycle. Quality assurance requires a retrievable sample, which requires the archive, which requires the workflow.
Break the chain at the front and every downstream capability degrades. This is why devices come last in this phase rather than first.
Encounter-based and order-based workflow
Get this distinction right before anything else, because it drives every technical decision that follows.
Order-based imaging workflow is the radiology model. An order exists, it generates a worklist entry with a specific study description, the study is performed against that order, and the result posts back. Point-of-care ultrasound in some settings fits this model and should use it.
Encounter-based imaging workflow is the model most POCUS actually requires. A clinician at the bedside decides during an encounter that imaging will answer a question, performs the study immediately, and interprets it themselves. There is no pre-existing order. The worklist is generated dynamically from patient registration or admission data, study descriptors start generic, and the report is what confers specificity on the exam after the fact.
That last point has consequences that are easy to miss. In encounter-based workflow the electronic health record result drives what the exam actually was. Documentation is not a description of the study. Documentation is the study's identity in the record. Every downstream capability, billing included, depends on it.
Most enterprise programs need both models running simultaneously across different departments, which is a design requirement rather than a compromise.
The workflow manager decision
A POCUS workflow manager routes imaging data to the enterprise archive via DICOM while transmitting reports to the EHR, and supports quality assurance by making studies findable and attributable. Workflow automation, with or without dedicated software, has been shown to increase both revenue and documentation compliance.
It also adds real cost and real complexity. Licensing, integration labor, infrastructure, and ongoing support are all substantial, and some existing enterprise imaging platforms already provide part of the needed capability. The honest decision is between a dedicated workflow manager and extending an existing enterprise imaging platform, and it depends on what you already have rather than on what is best in the abstract.
What is not optional is that some system must handle these functions.
Worklist management. The ability to filter, update, and remove patient entries from the DICOM modality worklist matters enormously in high-volume departments. A worklist that reflects every registration event in a busy emergency department will overwhelm the device and make patient selection error-prone. Nimble addition and timely removal is a functional requirement, not a preference.
Patient association. Standardized demographic capture across every device, automated where possible. Barcode scanning of patient wristbands to populate patient and encounter information removes the most common source of reconciliation failure. Manual entry at the device is inefficient and produces errors that surface weeks later as unmatched studies.
Provider attribution. Provider identity is not a required DICOM field, and in practice the step where a clinician enters their identifier at the device is skipped or performed incorrectly with enough frequency to corrupt the data. Badge scanning solves it. Report-side selection is a workable alternative. Deciding not to capture it at all is a decision to run quality assurance without knowing who scanned.
Signature and attestation. The electronic signature identifying the interpreter is critical metadata required for the EHR to post the result. In any teaching environment, or any environment with clinicians not yet privileged, the workflow must support a preliminary report from the trainee with a required final signature from a privileged provider. This is the attestation model radiology already runs, and building it later is far harder than building it now.
Storage architecture
Where possible, an enterprise image archive, whether PACS or VNA, should serve as the final centralized repository for POCUS data regardless of originating device or format. Departmental or device-local storage recreates the fragmentation the program exists to solve, and it makes retrieval, sharing, and long-term retention a per-department problem.
Decide on-premises versus cloud deliberately. On-premises offers greater control over data and infrastructure at higher upfront cost and longer implementation. Cloud offers faster deployment and scalability with exposure during network outages and a different long-term cost profile. Align the choice with existing IT strategy rather than with the preference of whichever vendor is in the room.
Retention policy has to be settled with legal before go-live, including the training exam question from Phase 1. Where training studies are considered part of the medical record, retention is subject to organizational policy and jurisdictional requirements.
Interoperability and standards
There is a standards profile written for exactly this problem and it is worth naming. IHE's Encounter-Based Imaging Workflow profile, with its point-of-care ultrasound extensions, specifies how an unordered, encounter-driven study gets identified, stored, and reconciled to the correct patient and encounter. That is the orphaned study problem described above, addressed by a published profile rather than by a custom build. Ask whether your candidate systems conform to it.
Standardize DICOM and HL7 or FHIR interoperability settings across devices and systems. Note that FHIR R4 remains the production baseline that regulation and most implementations assume, so specify a version rather than leaving it open. A standardized integration approach is what allows the program to expand without each clinical group rebuilding the same connections. The absence of that standardization is why imaging data so often sits outside the infrastructure that coordinates everything else in the record, and it is a problem the health system inherits rather than one the vendor solves.
All devices in scope need network connectivity, the ability to query a DICOM modality worklist, and the ability to store to a DICOM repository. Devices that cannot do all three are not program-eligible, which is a Phase 0 finding that becomes a Phase 3 constraint.
Security
Devices join a managed IT infrastructure with strong encryption and network segmentation protecting patient health information. Involve enterprise IT and imaging informatics in device selection rather than after it, enforce strong authentication, disable unused features, commit to a patching cadence, and secure the archive against unauthorized access. Portable systems depend on secure wireless. Fixed systems can use wired infrastructure. Both have to meet the same standard.
Infection prevention and clinical engineering
Reprocessing protocol by device type and by application, approved by infection prevention before deployment. Handheld devices used across multiple patients in rapid succession present a different problem than a cart-based unit in a fixed location, and the protocol has to be practical enough that clinicians follow it.
Clinical engineering connects devices to the network, maintains the inventory, and owns replacement processes for both planned refresh and unplanned failure. Build the maintenance budget line during this phase rather than discovering it in year two.
In the practice setting. The integrated package decision
Everything above assumes infrastructure that a primary care group, specialist practice, or multi-site clinic organization does not have. There is no PACS to route to, no imaging informatics team to build the interface, no medical staff office to run privileging, and often no internal revenue cycle capability beyond a practice management system and a billing service.
For these organizations the phase does not disappear. It changes form. The requirements identified in Phase 2 still have to be met. The question is who meets them, and the answer is a vendor selection decision rather than an internal build. That single decision sets the timeline to billable revenue more than any other choice the practice will make.
The five components
A practice needs all five. Missing any one of them stalls the program, and the stall is usually discovered after devices have arrived.
| Component | What it must cover | Consequence when it is missing |
|---|---|---|
| Device | Clinical applications on the Phase 2 map, transducers matched to those applications, reprocessing practical in an exam room | Wrong transducer configuration for the actual use cases, discovered after purchase |
| Cloud archive | DICOM storage with a business associate agreement, defined retention meeting state requirements, patient-level retrieval, prior study access at the point of read | Studies are not permanently stored or retrievable, which makes them undocumentable and unbillable |
| Revenue cycle enablement | Coding guidance for the specific applications, documentation templates mapped to payer policy, charge submission path, denial management, payer enrollment support where the service is new to the practice | Studies are performed and never billed, or billed and denied with nobody assigned to work the denial |
| Quality assurance support | A review mechanism the practice can actually staff, external over-read where internal expertise does not exist, documented findings and actions | No defensible competency record, which is an exposure at credentialing, at audit, and after any adverse event |
| Training and competency validation | Initial training on the applications in scope, a defined pass standard, ongoing validation, documentation the practice can produce on request | Clinicians scan without documented competency, which affects both liability and payer credentialing |
Add a sixth if the practice runs an EHR that must receive results, which is nearly all of them. Ask specifically how results and images reach the chart, whether that is an interface, a portal link, a PDF, or a manual step, and who builds it.
Why the package decision drives the timeline
An assembled solution from a single vendor, or from a vendor with named integration partners, can reach first billable study in a matter of weeks. A component-by-component assembly by a practice without informatics staff routinely takes six months or more, and the delay is rarely in the clinical work. It is in the archive contract, the interface build, the coding setup, and the discovery that the billing service has never submitted an ultrasound claim for this practice before.
That is an argument for buying a package. It is not an argument for buying any package. The failure mode specific to this setting is a bundle that looks complete and is not, most commonly one that provides device and archive while describing revenue cycle support that turns out to be a coding reference document and a webinar.
Contract terms that matter more here
A practice has less leverage and more exposure than a health system, which makes a small number of terms disproportionately important.
Data ownership and exit. Who owns the images. What happens to them at termination. Whether the practice can export the full archive in standard DICOM format, at what cost, and within what timeframe. Get this in writing before signing, because the alternative is discovering at renewal that leaving means abandoning the record.
Pricing structure. Per-study, per-provider, per-site, or subscription. Per-study pricing aligns cost to revenue and is generally safer for a practice with uncertain volume. Subscription pricing rewards volume the practice may not reach in year one. Model both against the Phase 2 volume estimate rather than against the vendor's.
What revenue cycle support actually includes. Whether it covers claim submission or only documentation guidance. Whether denials are worked, by whom, and to what threshold. Whether payer enrollment or credentialing support is included. Whether any of it survives the first year.
Business associate agreement and security posture. Non-negotiable, and worth having reviewed by counsel even at the cost of a delay.
Uptime and retrieval commitment. What happens when the archive is unavailable and a study is needed. What the retrieval time commitment is for an older study requested during an audit or a records request.
The tradeoff to name honestly
A bundled package trades integration burden for vendor concentration. The practice gets to a billable study faster and accepts that changing any component later means renegotiating or replacing most of them. That is often the right trade for an organization without informatics capacity, and it should be made deliberately with the exit terms understood, rather than discovered as a constraint two years in.
Device selection, deliberately last
A note on where this recommendation comes from. The pre-deployment literature treats device selection and workflow solution selection as an interdependent process whose sequence varies by organization, observing that device standardization drives workflow selection in some systems while enterprise imaging architecture drives device selection in others. That is an accurate description of practice and it deliberately declines to prescribe an order.
This playbook prescribes one. Put architecture first. The reason is not that the other sequence cannot work, it is that the other sequence only works when the organization already has mature enterprise imaging infrastructure and the discipline to constrain device choice to what that infrastructure supports. Organizations with that maturity do not need this playbook. Organizations without it will find that a device decision made first becomes a constraint on every architectural decision after it, and the constraint is discovered rather than chosen.
With that said, device selection now becomes a productive conversation, and it is a fit-to-architecture decision rather than a feature comparison.
Three device categories serve different purposes. Cart-based machines offer full imaging capability with mobility within a department or clinic. Hand-carried laptop-sized devices trade some capability for portability across settings. Pocket-sized devices offer maximum portability for focused examination and screening, generally requiring a paired mobile application. Most enterprise programs need a mix, distributed by use case rather than standardized for procurement convenience.
The selection criteria that matter at this point are compatibility with the workflow solution, DICOM conformance including modality worklist query, network and security compliance, transducer configuration matched to the clinical applications each department actually performs, reprocessing compatibility with the approved protocol, and total cost including transducers, disposables, software licensing, and maintenance.
Clinical stakeholders determine use cases and unit counts for their own areas. That input is necessary. It is not the same as clinical stakeholders selecting devices in isolation from the architecture, which is what happens when Phase 3 runs in the wrong order.
What to require from your vendor
Interoperability commitments in contract language rather than in a datasheet, specifying DICOM conformance, modality worklist behavior, and archive compatibility. Structured output rather than images and unstructured reports only, because coded findings are what allow imaging data to participate in anything downstream and unstructured output guarantees it will not.
No proprietary lock on the archive. If images can only be retrieved through the vendor's viewer, or if migrating to a different platform requires their cooperation on terms unspecified today, that is a lock and it should be priced as one.
Explicit statement of which integration work is included in the purchase and which is billable professional services, with an estimate for the latter. A named integration engineer. Written confirmation of what the device does when the network is unavailable, because that scenario will occur.
For any AI capability offered at this stage, ask what the device produces beyond the image. A measurement written into a report is a different asset than a coded, structured finding that can populate a registry, feed a risk model, or support a quality measure. The distinction determines whether the program's data is an output or an asset.
Failure mode
Devices arrive before storage is live. Scanning begins because clinicians have tools and patients have needs. Images do not persist, documentation cannot reference stored studies, nothing is billable, and the program's first six months produce no evidence that it worked. Retrofitting archive integration after clinical adoption means changing workflow for people who have already learned a different one, which is materially harder than teaching it correctly the first time.
The severity of this failure is easy to underestimate because it is invisible. The scans happen. Patients benefit. The clinicians are satisfied. And the program has no record, no revenue, no quality sample, and nothing to defend in the budget conversation.
Gate criteria
This is the second genuine dependency. The workstream is done when a test study from a representative device reaches the archive, associates to the correct patient and encounter, surfaces in the EHR, and can be retrieved by someone other than the person who performed it, with retention policy approved by legal, reprocessing protocol approved by infection prevention, and security approval documented. Production device deployment at scale should wait for it, because devices that arrive before storage is live generate scans that never persist.
In the practice setting, the same gate applies with the archive being the vendor's cloud rather than your own. Add three items. The business associate agreement is executed. The export and exit terms are in writing. And the revenue cycle component has been tested end to end, meaning a real study has produced a real claim, which is covered in Phase 5 and should be piloted before full deployment rather than after.