Healthcare IT Glossary

Also: FDA 21 CFR Part 11, Part 11

21 CFR Part 11 is the FDA regulation governing electronic records and electronic signatures in regulated activities, covering clinical trials, medical device manufacturing, and laboratory systems. It demands validated systems, secure computer-generated time-stamped audit trails, record retention, and signature manifestations that bind signer to record. Healthcare IT meets it on LIMS and research-grade builds, not routine clinical integration.

See also Audit LogSecurity Risk AnalysisHIPAA

Full explanation

An accession number is the identifier a RIS assigns to one ordered exam, and it is the join key between the HL7 order, the DICOM study, and the signed report. It rides in DICOM tag (0008,0050) and in an HL7 OBR field whose exact position varies by site. When the two disagree, studies land in the PACS unmatched to any order.

DICOM (0008,0050) AccessionNumber   A2607260012
HL7   OBR-18 (one common mapping)  A2607260012

See also OBR SegmentStudy ReconciliationModality WorklistRIS

Full explanation

Also: Acknowledgment message, MSA

An ACK is the acknowledgment message a receiver returns to confirm what happened to an inbound HL7 v2 message. Its MSA segment carries the acknowledgment code, usually AA accepted, AE application error, or AR rejected, plus MSA-2 echoing the original MSH-10 so the sender can correlate. No ACK handling means silent message loss.

MSH|^~\&|EPIC|MAIN_HOSP|LAB_SYS|PATHOLOGY|202603011401||ACK^R01|ACK00042|P|2.5.1
MSA|AA|LAB00042

See also MLLPMSH SegmentRetry and Redelivery

Full explanation

Also: Mirth Connect Administrator, Mirth Administrator

The Admin Console is Mirth® Connect's management client, reached from the server at port 8443, where channels are authored, deployed, and monitored. It is a Java desktop application, so JRE version and self-signed TLS certificate problems are the usual reasons it refuses to launch. Everything it exposes is also reachable over the REST API, which is how MirthSync works without it.

See also MirthSyncDashboard StatisticsDeploy / UndeployChannel

Full explanation

Also: ADT message, Admit Discharge Transfer

An ADT feed is the stream of Admit, Discharge, Transfer messages that keeps every downstream system synchronized with the patient census. One ADT message code covers dozens of trigger events, from A01 admission through A08 demographic update to A40 patient merge. Nearly every hospital interface project starts by subscribing to this feed.

See also PID SegmentPV1 SegmentEVN SegmentPatient ID Merge

Full explanation

Also: Application Entity Title, AET

An AE Title is an identifier of up to 16 characters that names a DICOM node on the network. Every association carries a calling AE Title for the sender and a called AE Title for the receiver, and both must match what the peer has configured. A mismatch is the most common reason an association is rejected outright.

CALLING AE: SAGA_SCU
CALLED  AE: PACS_ARCHIVE
HOST      : pacs.example.org:11112

See also AssociationPresentation ContextConformance Statement

Full explanation

Also: Patient Allergy Information segment, AL1

The AL1 segment communicates one patient allergy or adverse reaction, repeating for each known allergen, and appears mainly in ADT messages. AL1-4 severity drives clinical decision support downstream, where severe usually means a hard stop in the ordering system. An absent AL1 is ambiguous, so send an explicit no known allergies entry instead.

See also ADT FeedPID SegmentDG1 Segment

Full explanation

An alert is a Mirth® Connect rule that watches for error events and notifies someone when they fire, typically by email or by feeding another channel. Alerts are scoped by channel and error type, so a filter set too broadly turns into ignored noise during a routine outage. They are server configuration, not channel configuration, and travel separately from a channel export.

See also Channel Export XMLDashboard StatisticsRetry and RedeliveryMirthSync

Full explanation

Archive tiering is the lifecycle policy that moves imaging studies between storage classes as they age: hot SSD for the last 30 days, warm object storage for months, cold archive for the long retention tail. The tradeoff is retrieval latency, which is why tier boundaries have to line up with prefetch rules and with the retention period your jurisdiction requires.

0-30d     hot SSD          instant
30-180d   object storage   seconds
180d+     cold archive     minutes to hours

See also PrefetchVNAEnterprise ImagingPACS

Full explanation

Also: DICOM association, A-ASSOCIATE

An association is the negotiated session between two DICOM nodes. Before any data moves, the pair agrees on who is calling, which SOP Classes they will exchange, and which transfer syntaxes encode the payload. Everything in classic DICOM networking happens inside an association, which is closed with A-RELEASE or torn down with A-ABORT.

See also AE TitlePresentation ContextDIMSE

Full explanation

Also: Audit Trail, Audit Controls

An audit log is the tamper-resistant record of who accessed which patient record, when, from where, and what they did with it. HIPAA §164.312(b) requires the mechanism; investigators require the content. Practical minimums are actor, source and destination, patient or study identifier, event type, outcome, and a UTC timestamp, commonly retained six years to line up with the HIPAA documentation retention rule.

2026-04-29T14:31:02Z user=jdoe action=READ
  resource=Patient/123 src=10.4.1.22 outcome=ALLOW

See also HIPAA Security RuleRBACIncident ResponseePHI

Full explanation

Also: Business Associate Agreement

A Business Associate Agreement is the written contract required under §164.504(e) and §164.314(a) before a vendor may touch PHI on a covered entity's behalf. It fixes permitted uses, mandates safeguards, requires incident reporting, and flows the same obligations down to subcontractors. Sharing PHI with a third party that has not signed one is itself a HIPAA violation.

See also Business AssociateCovered EntityHIPAA Privacy RulePHI

Full explanation

The HIPAA Breach Notification Rule (45 CFR §§164.400-414) requires covered entities to notify affected individuals, HHS, and sometimes the media after unsecured PHI is improperly acquired, accessed, used, or disclosed. An impermissible disclosure is presumed to be a breach unless a documented four-factor risk assessment shows low probability of compromise. Individual notice is due within 60 days of discovery.

See also HIPAAIncident ResponsePHIBusiness Associate

Full explanation

Also: Bulk FHIR, FHIR Bulk Data Access, $export

Bulk Data Export is the FHIR specification for pulling population-scale data asynchronously: kick off $export at system, group, or patient level, poll the returned status URL until the job completes, then download the NDJSON files it lists. It exists because paging millions of resources through ordinary REST search is impractical. Typical consumers are data warehouses, quality reporting, and analytics pipelines.

See also NDJSONOAuth ScopesFHIR Search Parameter

Full explanation

A business associate is any organization that creates, receives, maintains, or transmits PHI while performing a function on behalf of a covered entity. Cloud hosts, integration engine vendors, billing services, managed IT providers, and even record-shredding companies all qualify. Business associates are directly liable under the Security Rule, not just contractually bound through the covered entity.

See also Covered EntityBAAHIPAA Security RulePHI

Full explanation

Also: Verification SOP Class, DICOM ping

C-ECHO is the DICOM verification operation, the protocol's equivalent of ping. The SCU opens an association and sends a command with no data set; a successful response proves TCP reachability, AE Title acceptance, and presentation context negotiation all work. Run it first on any new connection: it separates network problems from data problems in seconds.

echoscu -v -aec PACS_ARCHIVE -aet SAGA_SCU pacs.example.org 11112

See also AssociationAE TitleSCP

C-FIND is the DIMSE query operation. The SCU sends an identifier data set in which filled attributes are match criteria and empty attributes are the fields it wants returned, and the SCP replies with one response per match. Match semantics follow each attribute's VR: ranges for dates, wildcards for names, exact only for UIDs.

(0008,0052) QueryRetrieveLevel = STUDY
(0010,0020) PatientID          = 12345
(0008,0020) StudyDate          = 20260101-20260131
(0020,000D) StudyInstanceUID   = (empty: return this)

See also C-MOVEQIDO-RSValue Representation

Full explanation

C-GET is the DIMSE retrieve operation that returns instances over the same association that requested them. It avoids the second connection and destination configuration C-MOVE needs, so it passes through firewalls cleanly, but it requires presentation contexts negotiated in both directions and many older archives never implemented it. Prefer C-GET when you control both endpoints.

See also C-MOVEPresentation ContextWADO-RS

Full explanation

C-MOVE is the DIMSE retrieve operation in which the requester names a third-party destination AE Title. The SCP then opens a new outbound association to that destination and C-STOREs the matching instances there. Because the archive dials the destination, the firewall must permit that inbound connection, and the images only reach the requester when it is itself the destination.

SCU        : WORKSTATION_1  (asks)
SCP        : PACS_ARCHIVE   (retrieves, then sends)
Destination: REVIEW2        (must be pre-registered on the SCP)

See also C-GETAE TitleFirewall Allowlist

Full explanation

Also: Storage Service Class

C-STORE is the DIMSE operation that pushes a DICOM object from one node to another. It carries a command set naming the SOP Class and SOP Instance UID, then the data set itself. A status of 0000 means success; anything else means the receiver refused, ran out of space, or could not decode the negotiated transfer syntax.

storescu -v -aec PACS_ARCHIVE -aet SAGA_SCU pacs.example.org 11112 CT.000001.dcm

See also C-FINDStorage CommitmentPresentation Context

Also: FHIR Conformance resource

A CapabilityStatement is the FHIR resource a server publishes at /metadata to declare what it actually supports: resource types, interactions, search parameters, profiles, and security schemes. Clients read it to discover an endpoint instead of guessing. Treat it as advertising rather than proof: vendor statements routinely overstate support, so probe the endpoint before you scope work against it.

See also FHIR Search ParameterFHIR ProfileConformance Statement

Full explanation

Also: Outside study import, Media import

CD import is the workflow for ingesting outside studies that arrive on physical media or as a downloaded archive, reading the DICOMDIR, and loading the images into the local PACS. The catch is identity: the outside patient ID, accession number, and often the study description belong to another organization, so every import needs coercion rules and an audit trail of what was changed.

See also Study ReconciliationPatient ID MergePart 10 FilePACS

Full explanation

A channel is one configured interface inside an integration engine: a source that receives messages, optional filters and transformers, and one or more destinations that deliver the result. Mirth® Connect, Open Integration Engine, and BridgeLink all use this structure, and a channel is the unit that gets deployed, versioned, monitored, and exported as XML.

See also Source ConnectorDestination ConnectorTransformerMirth Connect

Full explanation

Also: Channel Export

A channel export XML is the serialized form of one Mirth® Connect channel: its connectors, filters, transformers, and metadata in a single file that can be imported into another server. It carries the channel's UUID, so re-importing it updates the existing channel rather than creating a second copy. Code templates, resources, and configuration map values are not included.

<channel version="4.5.2">
  <id>7f3c1a90-0b42-4a9e-8c11-2d6f5b3e9e21</id>
  <name>ADT_Inbound</name>
  <sourceConnector>...</sourceConnector>

See also ChannelCode TemplateConfiguration MapMirthSync

Full explanation

A channel group is a folder-like container that organizes related Mirth® Connect channels, such as every ADT feed or every lab interface. Groups exist purely for organization and have no runtime effect on routing. They matter operationally because MirthSync mirrors them in the on-disk directory layout, so renaming a group reshuffles the file tree and produces a noisy diff.

See also ChannelDisk ModeMirthSync

Full explanation

Also: Composite Information Object Definition

A Composite Information Object Definition (CIOD) is the template for a complete DICOM object such as CT Image or Basic Text SR, assembled from modules marked mandatory, conditional, or user-optional. The standard defines 174 of them, and each pairs with a service to form a SOP Class. Those usage flags decide what a validator will reject.

See also IODModuleSOP Class

Full explanation

A code template is a reusable JavaScript function stored on a Mirth® Connect server and shared across channels instead of being copy-pasted into every transformer. Templates live in libraries, and each channel must explicitly subscribe to a library before its functions resolve. Forgetting that subscription is the usual reason a freshly pushed channel throws a ReferenceError on the target server.

See also TransformerChannelGlobal ScriptMirthSync

Full explanation

Also: HL7 component

An HL7 component is one of the parts a field divides into on the caret character, used when a single field carries structured data. The patient name field PID-5 holding DOE^JANE^A has three components: family name, given name, middle name. A literal caret inside a value must be escaped, or the parser will split the field in the wrong place.

See also FieldSubcomponentEncoding CharactersPID Segment

Full explanation

The configuration map is a server-level table of key-value pairs holding environment-specific settings such as database URLs, hostnames, and API keys, read from channel scripts at runtime. It is what keeps a single channel definition portable across dev, staging, and production. MirthSync omits it from pull and push unless you pass --include-configuration-map, precisely because its values differ per server.

var dbUrl = configurationMap.get('lab.db.url');

See also Environment PromotionMirthSyncChannelGlobal Script

Full explanation

Also: DICOM Conformance Statement, DCS

A conformance statement is the document a vendor must publish listing every SOP Class, transfer syntax, role, and security profile a DICOM device supports. Read it before scoping any integration: it predicts which associations will negotiate successfully. It is also self-certified and unaudited, so treat it as a hypothesis and validate with C-ECHO and real test data.

See also Presentation ContextSOP ClassC-ECHOInterface Specification

Full explanation

A covered entity is one of three organization types that HIPAA obligates directly: health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with a covered transaction. Covered entities carry compliance obligations directly, including the security risk analysis under §164.308(a)(1)(ii)(A): a consultant can run the assessment, but accountability for it never transfers.

See also Business AssociateBAAHIPAASecurity Risk Analysis

Full explanation

Also: Channel Statistics

Dashboard statistics are the per-channel counters Mirth® Connect reports for received, filtered, queued, sent, and errored messages. Filtered counts messages a filter deliberately rejected rather than failures, which is why a perfectly healthy channel can show a large filtered number. Counts accumulate until someone clears them, so watch the rate of change and queue depth instead of absolute totals.

See also Message FilterThroughputMessage QueueAdmin Console

Full explanation

A data element is one unit of DICOM data: a tag, a Value Representation, a length, and the value itself. Elements appear in ascending tag order within a data set, and an element whose VR is SQ contains a sequence of nested data sets rather than a primitive value. Everything in a DICOM object is built from these four fields.

See also DICOM TagValue RepresentationData Set

Full explanation

A data set is the ordered collection of data elements that makes up a DICOM object. In a Part 10 file it follows the File Meta Information and is encoded in whatever transfer syntax that header declares; on the wire it travels inside P-DATA-TF packets after a DIMSE command set. The structure is identical either way.

See also Data ElementFile Meta InformationPart 10 File

Full explanation

Also: Anonymization

De-identification is the process of stripping a data set of identifiers so it is no longer PHI and falls outside HIPAA's use and disclosure restrictions. The Privacy Rule recognizes exactly two methods: Safe Harbor, which removes 18 enumerated identifier types, and Expert Determination. Imaging adds a third problem, burned-in pixel text, that neither method solves for you.

See also Safe HarborExpert DeterminationDICOM Confidentiality ProfilePseudonymization

Full explanation

Also: Deploy, Undeploy

Deploying is the step that compiles a saved Mirth® Connect channel and starts it on the server; undeploying stops it and releases its ports and connections. Saving alone changes nothing at runtime, which is the classic reason an edited transformer appears to have no effect. MirthSync can push every channel and then deploy them all in one bulk operation.

./mirthsync.sh -s https://server:8443/api -u admin -t ./mirth-config --deploy-all push

See also ChannelEnvironment PromotionMirthSyncAdmin Console

Full explanation

A destination connector is the outbound side of a channel: the component that delivers a transformed message to a receiving system. A channel can have several, each with its own transformer, response handling, and queue, and they run in order or in parallel depending on configuration. A destination that queues on failure is what protects the feed when a downstream system goes offline.

See also ChannelSource ConnectorMessage QueueRetry and Redelivery

Full explanation

Also: Detailed Financial Transaction, DFT^P03

A DFT message posts charge data from a clinical system to the billing or revenue cycle platform. DFT^P03 is the primary trigger event, carrying one repeating FT1 segment per charge line with its CPT or HCPCS code, amount, and date of service. Duplicate-charge detection is the hard part of any DFT interface.

See also DG1 SegmentPV1 SegmentADT Feed

Full explanation

Also: Diagnosis segment, DG1

The DG1 segment carries a diagnosis code attached to an encounter, repeating for each diagnosis and appearing in ADT, ORM, and DFT messages. DG1-3 holds the ICD-10-CM code and its coding system, DG1-6 marks it admitting, working, or final, and DG1-15 sets priority. Priority 1 drives DRG assignment, so mis-sequencing has billing consequences.

See also DFT MessageADT FeedORM Message

Full explanation

Also: Supplement 142, Basic Application Level Confidentiality Profile

A DICOM Confidentiality Profile is a named recipe in PS3.15 Annex E for removing patient identity from DICOM objects. The Basic Profile removes or replaces several hundred identifying attributes; the option profiles Supplement 142 added for clinical trials then retain UIDs, device identity, or patient characteristics as the study design requires. Private tags and burned-in pixel text are the classic escapes.

(0010,0010) PatientName      -> Z  replaced with a dummy value
(0010,1040) PatientAddress   -> X  removed
(0020,000D) StudyInstanceUID -> U  new UID (K if Retain UIDs)

See also De-identificationPixel DataDICOM TagSafe Harbor

Full explanation

Also: Attribute tag, Group/element

A DICOM tag is the group and element pair that identifies an attribute, written as (0010,0010) for Patient's Name. Even group numbers are standard; odd groups are private and belong to whichever vendor claimed them through a private creator element. The PS3.6 data dictionary defines more than 5,000 tags with their names, VRs, and VMs.

(0010,0010)  group 0010 = Patient information
             element 0010 = Patient's Name
(0029,1010)  odd group    = private, needs its private creator

See also Data ElementValue RepresentationRetired Attribute

Full explanation

Also: DICOM over HTTP, PS3.18

DICOMweb is the family of HTTP services defined in PS3.18 that expose DICOM over REST: QIDO-RS to search, WADO-RS to retrieve, STOW-RS to store, and UPS-RS for worklists. It does not replace DIMSE, and most enterprises run both, using DIMSE for device-to-archive traffic and DICOMweb for browser viewers, cloud bridges, and AI pipelines.

See also WADO-RSQIDO-RSSTOW-RSDIMSE

Also: DICOM Message Service Element

DIMSE (DICOM Message Service Element) is the message layer of classic DICOM networking. It defines the verbs two nodes exchange inside an association: C-STORE to send an object, C-FIND to query, C-MOVE to request a transfer, C-ECHO to verify the link, plus the N-services behind MPPS and storage commitment.

See also AssociationC-STOREDICOMweb

Full explanation

Also: --disk-mode

Disk mode is the MirthSync option that decides how finely a server's configuration is broken apart on disk: code extracts every JavaScript and SQL block to its own file, items writes one XML file per channel and code template, groups writes one file per channel group and template library, and backup writes a single XML equivalent to an Administrator backup. Finer modes give readable pull-request diffs.

-m code    channel.xml + transformer.js + sourceConnector.js  (default)
-m items   Channels/Default Group/ADT_Inbound.xml
-m groups  ChannelGroups/Default Group.xml
-m backup  backup.xml

See also MirthSyncChannel GroupChannel Export XML

Full explanation

Also: RDSR, Radiation Dose Structured Report

Dose reporting is the capture and submission of radiation dose data from CT, fluoroscopy, and other ionizing modalities, usually as a DICOM Radiation Dose Structured Report emitted at the end of the exam. Programs like the ACR Dose Index Registry consume it, and the integration work is extracting RDSR values reliably across vendors that populate them inconsistently.

(0008,0060) Modality  SR
SOP Class 1.2.840.10008.5.1.4.1.1.88.67  (X-Ray Radiation Dose SR)
carries CTDIvol and DLP per irradiation event

See also Structured ReportModalityRISPACS

Full explanation

Embedded Git is the JGit-based Git implementation bundled inside the MirthSync CLI and admin console plugin, so init, status, add, commit, diff, log, and branch checkout work with no separate Git installation. It covers the everyday loop only: creating branches, merging, rebasing, and tagging still require the native git binary in the same directory.

See also MirthSyncEnvironment PromotionDisk Mode

Full explanation

Also: HL7 delimiters, MSH-2

Encoding characters are the four delimiters an HL7 v2 message declares in MSH-2, immediately after the field separator: component (^), repetition (~), escape (\), and subcomponent (&). Conformant parsers read them from each message rather than assuming the conventional set, because the standard permits other characters even though almost nobody uses them.

MSH|^~\&|...

See also MSH SegmentFieldComponentSubcomponent

Full explanation

Encryption at rest protects ePHI stored on disk, in object storage, in database files, and in backups, so that stolen media yields ciphertext instead of records. AES-256 with keys held in a managed KMS is the common baseline. HIPAA treats it as addressable rather than required, but encryption meeting HHS guidance renders PHI secured, which keeps a lost laptop out of breach notification.

See also Encryption in TransitePHIBreach Notification RuleHIPAA Security Rule

Full explanation

Encryption in transit protects ePHI moving across a network, most often via TLS 1.2 or higher on HTTPS, MLLP, and DICOM associations. The recurring gap in healthcare integration is the legacy leg: a modality or lab analyzer that speaks only clear text, tunneled or fenced onto an isolated VLAN because it cannot be upgraded.

HTTPS  443    FHIR / DICOMweb
MLLP   2575   HL7 v2 (no separate TLS port)
DICOM  2762   DIMSE over TLS (11112 is clear text)

See also Encryption at RestMLLPAssociationHIPAA Security Rule

Full explanation

An endpoint is one addressable end of an interface: a host, a port, and a protocol that either sends or receives clinical data. In a topology diagram every connector line terminates at two endpoints, and in practice an endpoint is what gets firewall rules, TLS certificates, and credentials attached to it. Vendors often supply separate endpoints per environment.

lis.example.org:6661     HL7 v2 over MLLP
pacs.example.org:11112   DICOM, AE PACS_ARCHIVE
api.example.org:443      FHIR R4 over HTTPS

See also PortFirewall AllowlistTopology DiagramSource Connector

Full explanation

Enterprise imaging is the strategy of consolidating image and multimedia content from every department (radiology, cardiology, pathology, ophthalmology, dermatology, wound care) into one archive with a single patient-centric viewer. The hard parts are the non-DICOM content, encounter-based departments that never had accession numbers, and reconciling patient identity across systems that never had to agree before.

See also VNAXDS-IPatient ID MergePACS

Full explanation

Also: Dev/test/prod promotion

Environment promotion is the practice of moving an interface change through development, test, and production in that order, with the same artifact deployed at each stage. In integration work the artifact is usually an exported channel plus its code templates, and the trap is configuration that differs per environment: hostnames, ports, credentials, and database names belong in a configuration map, never in the channel itself.

dev -> test -> prod   (identical channel XML)
per-environment values resolved from the configuration map

See also Configuration MapMirthSyncChannel Export XMLDeploy / Undeploy

Also: Electronic Protected Health Information, e-PHI

Electronic protected health information is PHI in electronic form: database rows, HL7 messages, DICOM objects, PDFs on a share drive, backups. The HIPAA Security Rule applies only to ePHI, which is why scoping a risk analysis starts with an inventory of every system that creates, stores, processes, or transmits it.

See also PHIHIPAA Security RuleSecurity Risk AnalysisEncryption at Rest

Full explanation

Also: Enterprise Service Bus

An ESB, or enterprise service bus, is general-purpose integration middleware that routes and transforms messages across an organization's applications. Healthcare interface engines are a specialized branch of the same family, and teams sometimes inherit an ESB from a corporate IT standard. The gap shows up in the details: MLLP framing, HL7 v2 parsing, and ACK semantics arrive as add-on modules rather than first-class behavior.

See also MiddlewareInterface EngineHub-and-Spoke

Full explanation

Also: Event Type segment, EVN

The EVN segment records which trigger event produced an HL7 v2 message and when it happened, sitting immediately after MSH in ADT and MDM messages. Its two timestamps are routinely conflated: EVN-2 is when a clerk recorded the event, EVN-6 is when the event actually occurred. Billing and reporting usually want EVN-6.

See also Trigger EventADT FeedMSH SegmentMDM Message

Full explanation

Expert Determination is the HIPAA de-identification method in which a statistician or similarly qualified expert documents that the risk of re-identifying any individual in a data set is very small. It costs more than Safe Harbor and requires a written report, but it preserves fields that research and AI training actually need, such as full dates or five-digit ZIP codes.

See also De-identificationSafe HarborPseudonymization

Full explanation

Also: 1.2.840.10008.1.2.1

Explicit VR Little Endian (UID 1.2.840.10008.1.2.1) writes the two-character VR alongside each tag, making the data set self-describing. A parser can skip or copy an unknown private element without a data dictionary, which is why most modern archives negotiate it first. File Meta Information is always encoded this way regardless of what the data set uses.

10 00 10 00   50 4E   0C 00   "DOE^JANE^A^^"
  tag          VR=PN   length   value

See also Transfer SyntaxImplicit VR Little EndianFile Meta Information

Full explanation

Also: Fast Healthcare Interoperability Resources, HL7 FHIR

FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard that models clinical data as discrete resources exchanged over REST APIs in JSON or XML. It replaces bespoke messaging plumbing with ordinary web technology: HTTPS, OAuth 2.0, and predictable URLs. R4 is the version US regulation targets, so most production work still lands there rather than on newer releases.

See also FHIR ResourceHL7 v2SMART on FHIRFHIR Versions

Full explanation

Also: Bundle

A FHIR Bundle is a container resource that carries a collection of other resources in one payload. Its type field decides the semantics: searchset for query results, transaction for an all-or-nothing multi-resource write, batch for the same entries applied independently, document for a clinical document, message for event delivery. Paginated searches return searchset Bundles whose link array holds the next-page cursor.

{
  "resourceType": "Bundle",
  "type": "searchset",
  "total": 142,
  "link": [{ "relation": "next", "url": "https://fhir.example.com/R4/Patient?page=2" }],
  "entry": [{ "resource": { "resourceType": "Patient", "id": "a1" } }]
}

See also FHIR ResourceFHIR Search ParameterFHIR Reference

Full explanation

Also: StructureDefinition

A FHIR profile is a StructureDefinition that constrains a base resource for a particular use: making optional elements required, fixing terminology bindings, forbidding extensions, or adding new ones. Servers assert conformance by listing profile URLs in meta.profile, and validators check payloads against them. Claiming a profile you do not actually satisfy is the most common conformance-test failure.

See also US CoreImplementation GuideValueSet and CodeSystemFHIRPath

Full explanation

Also: Reference (FHIR)

A FHIR reference is the pointer one resource uses to name another, written as a relative URL like Patient/123, an absolute URL, or a logical identifier. References are what turn separate resources into a clinical graph. The common failure is a dangling reference: the target lives on a different server, or was never created, so consumers resolve nothing.

See also FHIR ResourceFHIR BundleFHIR Search Parameter

Full explanation

Also: Resource (FHIR)

A FHIR resource is the standard's unit of exchange: a self-describing JSON or XML object representing one clinical or administrative concept, such as Patient, Observation, Condition, or Encounter. R4 defines over 140 resource types. In JSON every resource names its resourceType; once stored on a server it also carries an assigned id and usually a meta block holding version and profile claims.

{
  "resourceType": "Patient",
  "id": "erXuFYUfucBZaryVksYEcMg3",
  "name": [{ "family": "Lin", "given": ["Ada"] }],
  "birthDate": "1987-09-12"
}

See also FHIRFHIR BundleFHIR ReferenceFHIR Profile

Full explanation

Also: FHIR search, _include, _revinclude

A FHIR search parameter is a named, typed query argument a server supports on a resource type, such as Patient?family=Doe&birthdate=1980-01-15. Types include token, date, reference, quantity, and string, each with its own modifiers and prefixes. _include and _revinclude pull linked resources into the same Bundle. Servers only honor parameters listed in their CapabilityStatement, so portable queries stay conservative.

GET /R4/Observation?patient=123&category=vital-signs&_revinclude=Provenance:target
Authorization: Bearer <access_token>

See also CapabilityStatementFHIR BundleFHIRPath

Full explanation

Also: FHIR R4, FHIR R5, STU3, DSTU2

FHIR versions are the standard's numbered releases: DSTU1 (2014), DSTU2 (2015), STU3 (2017), R4 (2019), R4B (2022), R5 (2023), and R6 in development. R4 was the first release with normative content and remains what US regulation and every major EHR API target, so that is what most integrations still build against. R5 refines rather than breaks R4's normative core.

See also FHIRHL7 v2 VersionsUS Core

Full explanation

Also: FHIRPath expression

FHIRPath is the path-based expression language FHIR uses to navigate and evaluate against resource trees, written as dotted paths with functions, for example Patient.name.where(use = 'official').family. It powers profile invariants, search parameter definitions, and validation rules across the specification. It is not JSONPath or XPath: every expression evaluates to a collection, and an empty collection is not an error.

See also FHIR ResourceFHIR ProfileFHIR Search Parameter

Full explanation

Also: HL7 field

An HL7 field is the unit of data between two pipe characters in a v2 segment, referenced by position: PID-5 is the fifth field of the PID segment. Position is everything, so an empty field still needs its pipe. Dropping one shifts every later value into the wrong field.

See also ComponentRepetitionSegmentEncoding Characters

Full explanation

Also: FMI, Group 0002

File Meta Information is the group 0002 header at the front of every Part 10 DICOM file, always encoded in Explicit VR Little Endian no matter how the data set that follows is encoded. It carries the Media Storage SOP Class and Instance UIDs, the Transfer Syntax UID that decodes the rest, and the implementation that wrote the file.

(0002,0000) FileMetaInformationGroupLength  UL
(0002,0002) MediaStorageSOPClassUID         UI
(0002,0003) MediaStorageSOPInstanceUID      UI
(0002,0010) TransferSyntaxUID               UI
(0002,0012) ImplementationClassUID          UI

See also Part 10 FileTransfer SyntaxPreamble

Full explanation

Also: Firewall whitelist, Network allowlist

A firewall allowlist is the explicit set of source addresses, destination hosts, and ports permitted to cross a network boundary. Because MLLP holds a long-lived TCP session and returns its ACK on the same connection, the rule request has to name both hosts, the port, and the side that opens the session. An interface that works in test and stalls in production is usually an allowlist gap.

See also PortEndpointMLLPEncryption in Transit

Full explanation

Also: (0020,0052), Frame of Reference UID

Frame of Reference UID (0020,0052) declares that a set of images share one spatial coordinate system, so their positions and orientations can be compared directly. Registration, fusion, RT structure sets, and segmentation objects all depend on it. Two series with different Frame of Reference UIDs cannot be overlaid without an explicit spatial registration object.

See also Image Position (Patient)Image Orientation (Patient)UID

Also: Global Scripts, Deploy Script, Preprocessor Script

Global scripts are JavaScript hooks that run at fixed points in the Mirth® Connect server lifecycle rather than inside one channel: deploy, undeploy, preprocessor, and postprocessor. The preprocessor and postprocessor execute for every message on every channel, so heavy logic there becomes a site-wide throughput ceiling and a hard-to-trace source of latency.

See also Code TemplateTransformerThroughputDeploy / Undeploy

Full explanation

A hanging protocol is the saved rule set that decides how a study is laid out on a radiologist's monitors: which series go in which viewport, what orientation, what window level, and which priors hang alongside. DICOM defines a Hanging Protocol IOD for portability, but most PACS store their own proprietary version, so layouts rarely survive a viewer swap.

See also Radiologist WorklistZero-Footprint ViewerWindow Center / WidthPresentation State

Full explanation

Also: Health Insurance Portability and Accountability Act

HIPAA is the US federal law (the Health Insurance Portability and Accountability Act of 1996) that sets national standards for protecting patient health information. Its operative parts are the Privacy Rule, the Security Rule, and the Breach Notification Rule, enforced by the HHS Office for Civil Rights. There is no official HIPAA certification: compliance is self-attested and proven through documentation.

See also HIPAA Privacy RuleHIPAA Security RuleBreach Notification RuleCovered Entity

Full explanation

The HIPAA Privacy Rule (45 CFR Part 164, Subpart E) governs how covered entities may use and disclose protected health information in any form, electronic, paper, or oral. It grants patients rights to access, amend, and receive an accounting of disclosures of their records, and it establishes the minimum necessary standard that shapes role-based access design.

See also PHIMinimum NecessaryHIPAA Security RuleBAA

Full explanation

The HIPAA Security Rule (45 CFR Part 164, Subpart C) prescribes the safeguards required to protect electronic protected health information. It organizes 18 standards into administrative, physical, and technical categories, each with required or addressable implementation specifications. Addressable never means optional: you implement it, implement a documented equivalent, or record why neither is reasonable and appropriate.

§164.308  Administrative  9 standards
§164.310  Physical        4 standards
§164.312  Technical       5 standards

See also ePHISecurity Risk AnalysisAudit LogEncryption in Transit

Full explanation

Also: HITRUST, HITRUST Common Security Framework

HITRUST CSF is a certifiable security framework built for healthcare that folds HIPAA, NIST, ISO 27001, PCI DSS, and dozens of other sources into one prescriptive control set. Three tiers exist: e1 for basic hygiene, i1 for implemented practice, and the risk-based r2 on a two-year cycle. Health systems and payers increasingly require it from vendors handling PHI.

See also SOC 2ISO 27001HIPAABusiness Associate

Full explanation

Also: Health Level Seven Version 2, HL7 Version 2, HL7 v2.x

HL7 v2 is a pipe-delimited messaging standard for exchanging clinical and administrative data between healthcare systems, first published as v2.1 in 1990 and still carrying the majority of real-time hospital interfaces. Messages are plain text built from segments, fields, and components, and travel over MLLP on a TCP socket rather than an HTTP API.

See also SegmentMLLPFHIRInterface Engine

Full explanation

Also: v2.5.1, MSH-12, Version ID

HL7 v2 versions run from v2.1 in 1990 to v2.9 in 2019, with v2.5.1 the version most widely deployed in production. Every message names the version it claims in MSH-12. Releases are additive, so older parsers ignore appended fields they do not recognize, but treat MSH-12 as a hint rather than a contract.

See also HL7 v2MSH SegmentInterface Specification

Full explanation

Hub-and-spoke is the integration topology where every system connects only to a central interface engine, which handles all transformation and routing between them. Adding the Nth system costs one interface instead of N-1, which is why it is the default pattern in healthcare. The tradeoff is that the hub becomes a single point of failure worth clustering.

See also Point-to-PointInterface SpaghettiInterface EngineTopology Diagram

Full explanation

Also: (0020,0037), Direction cosines

Image Orientation (Patient) (0020,0037) holds six values: the direction cosines of the image's first row and first column relative to the patient axes. It is what lets a viewer label left, right, head, and foot correctly on a reformatted view. Missing or inconsistent orientation across a series is a common reason multiplanar reconstruction refuses to build.

(0020,0037) ImageOrientationPatient = 1\0\0\0\1\0
            row cosines = +X (left)   column cosines = +Y (posterior)

See also Image Position (Patient)Frame of ReferenceValue Multiplicity

Full explanation

Also: (0020,0032)

Image Position (Patient) (0020,0032) gives the x, y, and z coordinates in millimeters of the center of the first transmitted voxel, expressed in the patient coordinate system. Together with Image Orientation (Patient) it tells a renderer where each slice sits in space. Sorting a series by this value is more reliable than sorting by instance number.

See also Image Orientation (Patient)Frame of ReferenceValue Multiplicity

Full explanation

Imaging routing rules are the conditional forwarding logic on a DICOM gateway or router that decides where an inbound study goes based on its attributes: modality, AE Title, station name, body part, or study description. Typical uses include sending mammography to a dedicated workstation, copying studies to an AI pipeline, and compressing before forwarding offsite.

if Modality == MG and StationName starts with "MAMMO"
    forward BREAST_WS, copy AI_CAD
else
    forward MAIN_ARCHIVE

See also RouterAE TitleC-STORETransfer Syntax

Full explanation

Also: IG, FHIR IG

A FHIR implementation guide (IG) is a published package of profiles, value sets, search parameter definitions, and narrative rules that pins down how FHIR is used for one domain or jurisdiction. Base FHIR is deliberately broad; the IG is what makes two implementations actually interoperate. US Core, the Da Vinci guides, CARIN Blue Button, and SMART App Launch are the ones most US projects hit.

See also US CoreFHIR ProfileValueSet and CodeSystem

Full explanation

Also: 1.2.840.10008.1.2, Default Transfer Syntax

Implicit VR Little Endian (UID 1.2.840.10008.1.2) is DICOM's default transfer syntax and the one every conforming SCP must accept. Each element is written as tag, four-byte length, value, with no VR on the wire, so a reader must consult the data dictionary to interpret anything. That makes private and unknown tags effectively unparseable.

10 00 10 00   0C 00 00 00   "DOE^JANE^A^^"
  tag           length        value   (VR looked up in the dictionary)

See also Transfer SyntaxExplicit VR Little EndianValue Representation

Full explanation

Incident response is the documented process for detecting, containing, investigating, and reporting a security event before it becomes an uncontrolled breach. HIPAA requires the procedures under §164.308(a)(6); the Breach Notification Rule starts the clock at discovery. The part teams skip is rehearsal: a tabletop exercise against ransomware or a vendor compromise finds the gaps a written plan hides.

See also Breach Notification RuleAudit LogSecurity Risk AnalysisHIPAA Security Rule

Full explanation

Also: Integration engine, HL7 interface engine

An interface engine is middleware that receives clinical messages from one system, transforms them into the format another system expects, and routes them onward. Interface engine and integration engine mean the same thing in healthcare IT: the older name comes from the HL7 v2 era, the newer one from platforms that also speak FHIR, X12, and DICOM.

See also MiddlewareHub-and-SpokeChannelESB

Full explanation

Interface spaghetti is the tangle of direct, undocumented system-to-system connections that accumulates when an organization grows without a central engine. The practical symptom is that nobody can say what breaks when a system is retired, because the same transformation logic lives in a dozen places. Drawing a topology diagram is usually the first step out.

See also Point-to-PointHub-and-SpokeTopology DiagramInterface Engine

Full explanation

Also: Interface spec, Interface requirements document

An interface specification is the written agreement between two systems describing exactly what will be exchanged: message types, trigger events, field-level mappings, code sets, transport and port, acknowledgment behavior, and error handling. It is the artifact both vendors sign off on before build, and the one that settles arguments later about whether a field was ever in scope.

See also Trigger EventMessage TypeConformance StatementTopology Diagram

Also: Information Object Definition

An Information Object Definition (IOD) is the standard's data model for one kind of real-world entity, listing the modules an object of that type must, may, or conditionally must contain. Normalized IODs describe a single entity such as a print film box; composite IODs mix patient, study, series, and equipment information into one object.

See also CIODModuleSOP Class

Full explanation

Also: ISO/IEC 27001, ISO 27001:2022

ISO 27001 is the international standard for an information security management system, audited and certified by an accredited body on a three-year cycle with annual surveillance audits. The 2022 revision organizes 93 Annex A controls into organizational, people, physical, and technological themes. Health technology vendors selling into EU, UK, or APAC markets usually meet it before they meet HITRUST.

See also SOC 2HITRUST CSFSecurity Risk Analysis

Full explanation

Also: J2K, HTJ2K, High-Throughput JPEG 2000

The JPEG 2000 transfer syntaxes encapsulate DICOM pixel data as JPEG 2000 codestreams, in lossless and lossy variants (UIDs 1.2.840.10008.1.2.4.90 and .91), with High-Throughput JPEG 2000 added later for speed. They compress large CT and MR studies far better than RLE, but support is uneven and older archives often negotiate only uncompressed or JPEG Lossless.

See also Transfer SyntaxPixel DataConformance Statement

Full explanation

Also: KOS, Key image note

A Key Object Selection (KOS) document is a small DICOM SR object that flags a chosen set of instances and records why, using codes such as For Teaching or Of Interest. Radiologists use it to mark key images, and cross-enterprise sharing uses it as the manifest listing which instances belong to a shared study.

See also Structured ReportSOP InstanceXDS-I

Also: DICOM macro, Attribute macro

A DICOM macro is a block of attributes defined once in PS3.3 and included by reference inside multiple modules or sequences, so the standard does not repeat itself. Code Sequence Macro and Image Pixel Description Macro are the ones integrators meet most. Macros are an authoring device: on the wire their attributes appear as ordinary elements.

See also ModuleCIODData Element

Full explanation

Also: Medical Document Management, MDM^T02

An MDM message reports a clinical document lifecycle event: created, status changed, amended, replaced, or cancelled. The TXA segment carries the document metadata (type, author, authentication status) and OBX segments carry the content when the event includes it. T02 delivers an original document with its full text; T01 is notification only.

See also OBX SegmentEVN SegmentTrigger Event

Full explanation

A message filter is the rule that decides whether a channel or destination processes a given message at all. Filters typically test a field such as MSH-9 message type, a sending facility, or an order-control code, and silently drop anything that does not match. A filter that is too broad is a common cause of messages that vanish without an error.

// process only ADT admits and updates
var t = msg['MSH']['MSH.9']['MSH.9.2'].toString();
return t === 'A01' || t === 'A08';

See also ChannelRouterTransformerMSH Segment

Full explanation

A message queue is the buffer an engine writes outbound messages to when a destination cannot accept them immediately. Queuing keeps the source system from blocking and preserves order for feeds that require it, at the cost of delay that is invisible until someone checks queue depth. Rising queue depth is the earliest reliable signal that a downstream system is down.

See also Retry and RedeliveryDestination ConnectorThroughputDashboard Statistics

Full explanation

Also: Message repository

A message store is the engine's database of processed messages, holding the raw inbound content, the transformed output, and the status of every destination attempt. It is what makes reprocessing and root-cause analysis possible, and it is also the largest PHI repository most integration teams forget they operate. Storage settings and pruning schedules are a compliance decision, not just a disk one.

See also ChannelPHIAudit LogRetry and Redelivery

Full explanation

Also: MSH-9

Message type is the HL7 v2 header field (MSH-9) that tells a receiver how to interpret everything that follows. It carries three components: the message code (ADT, ORU, SIU), the trigger event (A01, R01, S12), and optionally the message structure. Integration engines route on this field, so a wrong value lands the message on the wrong channel.

ADT^A01^ADT_A01

See also Trigger EventMSH SegmentRouterChannel

Full explanation

Middleware is software that sits between applications and moves data between them without either application knowing about the other. A healthcare integration engine is middleware specialized for clinical data: it speaks MLLP, HL7 v2, FHIR, X12, and DICOM natively and enforces the acknowledgment, audit, and retry semantics those standards expect, which general-purpose API gateways do not.

See also Interface EngineESBHub-and-Spoke

Full explanation

The minimum necessary standard requires covered entities to limit PHI use, disclosure, and requests to the smallest amount needed for the purpose at hand. In integration work it decides which segments survive a filter, which fields an API response returns, and how role permissions are scoped. Disclosures for treatment are the best-known of its several exemptions.

GET /Patient/123?_elements=id,birthDate,gender
(no name, no address, no contact details)

See also HIPAA Privacy RuleRBACPHIMessage Filter

Full explanation

Also: Mirth

Mirth® Connect is a healthcare interface engine that routes and transforms clinical messages between systems using JavaScript-based channels, and the codebase every Mirth-lineage fork descends from. Releases through 4.5.2 were open source; NextGen Healthcare made 4.6 and later commercial-only, so open-source work moved to community forks. Channels, code templates, and transformer scripts stay portable across all of them without rewriting.

See also Interface EngineOpen Integration EngineChannelMirthSync

Full explanation

Also: MirthSync CLI

MirthSync is an open-source CLI and admin console plugin that serializes a Mirth® Connect or Open Integration Engine server's configuration into files a Git repository can track. It pulls channels, code templates, global scripts, channel groups, resources, and alerts over the REST API, then pushes reviewed changes to another server. The configuration map is excluded unless you ask for it.

./mirthsync.sh -s https://server:8443/api -u admin -t ./mirth-config pull
./mirthsync.sh -t ./mirth-config --commit-message "ADT retry backoff" git commit

See also Mirth ConnectEnvironment PromotionChannel Export XMLDisk Mode

Full explanation

Also: Minimum Lower Layer Protocol, Minimal Lower Layer Protocol

MLLP (Minimum Lower Layer Protocol) is the TCP framing that marks where one HL7 v2 message ends and the next begins on a persistent socket. Each message is wrapped in a start block (0x0B) and an end block (0x1C 0x0D). MLLP provides no authentication and no encryption of its own, so production interfaces carry it inside TLS.

0x0B  [ HL7 v2 message ]  0x1C 0x0D

See also ACKPortFirewall AllowlistEncryption in Transit

Full explanation

Modality is the DICOM code identifying what kind of equipment produced a series of images: two-letter values like CT, MR, US, XA, MG, DX and PT, plus longer ones like RTSTRUCT and SEG. It lives in tag (0008,0060) at the series level, so a PET/CT study carries both PT and CT series under one Study Instance UID. Study-level filtering uses Modalities in Study instead.

(0008,0060) Modality           CS  CT
(0008,0061) ModalitiesInStudy  CS  CT\PT

See also DICOM TagModality WorklistSOP ClassPACS

Full explanation

Also: MWL, Modality Worklist Management

Modality Worklist is the DICOM service a scanner uses to pull its scheduled exams from the RIS or PACS instead of having the technologist type patient details by hand. It is C-FIND against SOP Class 1.2.840.10008.5.1.4.31, and the returned Scheduled Procedure Step carries the patient ID and accession number that later bind the images to the order.

SOP Class 1.2.840.10008.5.1.4.31
(0040,0100) ScheduledProcedureStepSequence
  (0008,0060) Modality     CT
  (0040,0002) StartDate    20260726
  (0040,0001) ScheduledAE  CT_SCANNER_1

See also C-FINDMPPSAccession NumberRIS

Full explanation

Also: DICOM module

A DICOM module is a named, reusable group of attributes that CIODs include as a unit: Patient, General Study, General Series, Image Pixel, and roughly 400 more. Each module carries a usage flag (M, C, or U) within the CIOD that references it, which is what tells you whether an attribute is genuinely required for a given object type.

See also CIODMacroData Element

Full explanation

Also: Modality Performed Procedure Step

MPPS is the DICOM service a modality uses to tell the RIS that a procedure has started, been discontinued, or completed, sent as N-CREATE followed by N-SET. In many radiology shops it is also the billing trigger, so an MPPS outage shows up as claims that quietly stop dropping rather than as an imaging failure.

See also Modality WorklistStorage CommitmentOrder-to-Report LifecycleRIS

Full explanation

Also: Message Header segment, MSH

The MSH segment is the mandatory message header that opens every HL7 v2 message, declaring the delimiters, the sending and receiving application and facility, the message type, a unique control ID, and the version. MSH-11 carries the processing ID: production systems should reject anything that does not say P.

MSH|^~\&|EPIC|MAIN_HOSP|LAB_SYS|PATHOLOGY|202603011400||ADT^A01|MSG00001|P|2.5.1

See also Encoding CharactersMessage TypeHL7 v2 VersionsACK

Full explanation

Also: Enhanced multi-frame, (0028,0008)

A multi-frame object packs many images into a single SOP Instance, with Number of Frames (0028,0008) counting them and, in the Enhanced families, per-frame metadata carried in functional group sequences. Ultrasound cine loops, XA runs, and Enhanced CT and MR objects all use it. Tools written for one slice per file break here, because a whole series arrives as one instance.

See also Pixel DataSOP InstanceSeries Instance UID

Also: newline-delimited JSON, JSON Lines

NDJSON (newline-delimited JSON) is a format where each line is one complete JSON object, making a file streamable and appendable without holding the whole document in memory. FHIR Bulk Data Export emits one or more NDJSON files per resource type. The gotcha is that an NDJSON file is not valid JSON: parsers that expect a single top-level array will choke on it.

{"resourceType":"Patient","id":"a1","birthDate":"1980-01-15"}
{"resourceType":"Patient","id":"a2","birthDate":"1974-06-02"}

See also Bulk Data ExportFHIR Resource

Full explanation

Also: NIST SP 800-66 Rev. 2, SP 800-66

NIST SP 800-66 is the federal implementation guide that translates each HIPAA Security Rule standard into concrete security activities a team can actually execute. Revision 2, published in 2024, recast it as a risk-management resource cross-mapped to the NIST Cybersecurity Framework and SP 800-53 controls. It carries no legal force, but OCR points to it as the implementation reference.

See also HIPAA Security RuleSecurity Risk AnalysisISO 27001

Full explanation

Also: Next of Kin segment, NK1

The NK1 segment holds a person associated with the patient: an emergency contact, next of kin, guardian, or billing party. It repeats, one segment per person, and appears mostly in ADT messages. NK1-3 states the relationship (spouse, parent) while NK1-7 states the functional role, so the same person can appear twice.

See also PID SegmentADT FeedPHI

Full explanation

Also: SMART scopes, FHIR scopes

SMART OAuth scopes are the strings an app requests to bound what a FHIR access token can reach, shaped as context/resource.permission. patient/Observation.read reads observations for one patient, user/*.read follows the logged-in clinician's own permissions, and system/*.read grants headless backend access. SMART v2 replaces the .read suffix with granular .cruds letters. Over-requesting scopes is the fastest way to fail an EHR vendor's app review.

scope=launch/patient patient/*.read openid fhirUser offline_access
response_type=code
code_challenge_method=S256

See also SMART on FHIRBulk Data ExportRBAC

Full explanation

Also: Observation Request segment, OBR

The OBR segment defines what was ordered and where that order stands, acting as the header for a group of related results. It carries the placer order number from the ordering system, the filler order number assigned by the lab or radiology system, the test code, and the specimen collection time.

See also OBX SegmentORC SegmentORU MessageAccession Number

Full explanation

Also: Observation Result segment, OBX

The OBX segment carries a single observation value in an HL7 v2 message: one lab number, one vital sign, one radiology impression, or one embedded PDF. OBX-2 names the data type so the receiver knows how to parse OBX-5. OBX-11 gives the result status, and a C means correct a previously final result.

OBX|1|NM|2345-7^Glucose^LN||98|mg/dL|70-100|N|||F

See also OBR SegmentORU MessageComponent

Full explanation

Also: OIE

Open Integration Engine (OIE) is the community-governed, MPL 2.0 open-source fork of Mirth® Connect, started after NextGen Healthcare ended open-source releases at 4.5.2. It runs existing channels, code templates, and custom Java libraries without modification, so moving to it is a re-platform rather than a rewrite. A non-profit steering committee and a multi-vendor maintainer group govern it.

See also Mirth ConnectInterface EngineMirthSyncChannel

Full explanation

Also: Common Order segment, ORC

The ORC segment carries the order control information shared across every kind of order: lab, radiology, and pharmacy. ORC-1 is the control code that drives the lifecycle, NW for a new order, CA to request cancellation, RE for results. ORC-5 reports the order status separately, and the two are easy to confuse.

See also OBR SegmentORM MessageOrder-to-Report Lifecycle

Full explanation

The order-to-report lifecycle is the full path a radiology exam takes: order placed in the EHR, worklist entry created for the modality, images acquired and stored, study read, report signed, result returned to the chart. Each hop is a different protocol, so a break shows up as a missing worklist entry, an orphaned study, or a report that never reaches the ordering provider.

See also Modality WorklistMPPSORM MessageORU Message

Full explanation

Also: Order Message, ORM^O01

An ORM message transmits a clinical order from a provider order entry system to the department that will fill it: lab, radiology, or pharmacy. ORM^O01 is the workhorse trigger event, pairing an ORC segment for order control with an OBR segment describing the test. Later v2 releases deprecate ORM in favor of OML, though it remains widespread.

See also ORC SegmentOBR SegmentORU MessageOrder-to-Report Lifecycle

Full explanation

Also: Observation Result Unsolicited, ORU^R01

An ORU message delivers observation results from a lab, radiology, or pathology system to the ordering provider's EHR. Unsolicited means the sender pushes results on its own schedule rather than answering a query. Each OBR segment groups the OBX segments carrying individual values, and a corrected result arrives as a new ORU with status C.

See also OBX SegmentOBR SegmentORM MessageRIS

Full explanation

Also: Picture Archiving and Communication System

A PACS is the imaging department's archive and distribution platform: it receives studies from modalities over DICOM, indexes them by patient and study, and serves them to reading workstations and web viewers. Four pieces do the work: an acquisition gateway, the archive itself, reading workstations, and a web distribution tier.

See also VNARISModalityC-STORE

Full explanation

Also: DICOM file, .dcm file, PS3.10 file

A Part 10 file is DICOM stored on disk: a 128-byte preamble, the DICM marker, File Meta Information, then the data set. The same data elements travel over the network without that wrapper, which is why a byte stream captured from an association will not open as a .dcm file until you prepend a valid header.

offset 0    128 bytes   preamble (usually zeros)
offset 128    4 bytes   "DICM"
offset 132   variable   File Meta Information, group 0002
after FMI    variable   data set, encoded per (0002,0010)

See also PreambleFile Meta InformationData SetTransfer Syntax

Full explanation

Also: DICOM information model, Query/Retrieve levels

Patient, study, series, instance is DICOM's four-level information model, and nearly every query, retrieve, and storage path follows it. A patient has studies, a study has series, a series has SOP Instances. Q/R levels, DICOMweb URL paths, and PACS folder layouts all mirror it, so a level mismatch between query and retrieve returns nothing.

See also Study Instance UIDSeries Instance UIDC-FINDQIDO-RS

Also: MRN merge, Patient merge

A patient ID merge is the operation that collapses two medical record numbers found to belong to the same person, propagating the surviving identifier through every downstream system. In imaging it is expensive: the PACS, VNA, and any cached prior have to be updated, and an HL7 ADT A40 merge message that the imaging stack ignores leaves priors stranded under the retired ID.

MSH|^~\&|ADT|HOSP|...|ADT^A40^ADT_A39|...
PID|1||900445566^^^HOSP^MR    surviving MRN
MRG|900112233^^^HOSP^MR       retired MRN

See also ADT FeedPID SegmentStudy ReconciliationEnterprise Imaging

Full explanation

Also: Protected Health Information

Protected health information is any individually identifiable health data that a covered entity or business associate creates, receives, maintains, or transmits, in any medium: electronic, paper, or spoken. The identifier matters as much as the diagnosis: a name attached to an appointment date is PHI. The Privacy Rule governs how it may be used and disclosed.

See also ePHIHIPAA Privacy RuleDe-identificationMinimum Necessary

Full explanation

Also: (0028,0004), MONOCHROME2

Photometric Interpretation (0028,0004) declares how pixel values map to what you see: MONOCHROME2 means higher values are brighter, MONOCHROME1 means the opposite, and RGB, YBR_FULL_422, and PALETTE COLOR describe color layouts. Get it wrong and a chest X-ray renders as a photographic negative, the classic symptom of a viewer ignoring this attribute.

See also Pixel DataWindow Center / WidthRescale Slope / Intercept

Also: Patient Identification segment, PID

The PID segment carries patient identity and demographics in an HL7 v2 message: identifiers, name, birth date, sex, and address. PID-3 is the field that matters most, a repeating list of every identifier with its assigning authority and type. Matching on a bare MRN without checking the assigning authority is how records get merged wrongly.

See also RepetitionPV1 SegmentPatient ID MergeADT Feed

Full explanation

Also: (7FE0,0010)

Pixel Data (7FE0,0010) is the attribute holding the actual image samples, normally the largest element in the file by orders of magnitude. Its VR is OB or OW depending on the transfer syntax, and compressed syntaxes encapsulate each frame in one or more fragments. Rows, Columns, Bits Allocated, and Samples per Pixel tell a reader how to unpack it.

See also Transfer SyntaxPhotometric InterpretationMulti-frame

Also: P2P integration

Point-to-point integration wires each pair of systems together directly, with no shared hub in between. Every connection carries its own transformation and error handling, so N systems can require up to N×(N-1)/2 interfaces. It is fast to stand up for the first two or three systems and increasingly expensive to change after that.

See also Hub-and-SpokeInterface SpaghettiInterface Engine

Full explanation

A port is the number that identifies which service on a host a TCP connection is addressed to. Healthcare conventions are loose but recognizable: HL7 v2 over MLLP commonly runs on 2575 or 6661, FHIR and other REST APIs on 443, DICOM on 104 or 11112, SQL Server on 1433, PostgreSQL on 5432, and SMB file drops on 445.

See also EndpointFirewall AllowlistMLLPTopology Diagram

Full explanation

Also: DICM magic, 128-byte preamble

The DICOM preamble is the first 128 bytes of a Part 10 file, followed immediately by the four ASCII characters DICM at offset 128. The preamble is application-defined and usually all zeros; some tools stuff a small image header there so the file also opens in a picture viewer. Missing DICM means you are holding a bare data set, not a Part 10 file.

See also Part 10 FileFile Meta InformationData Set

Full explanation

Prefetch is the scheduled retrieval of a patient's relevant prior studies into fast cache before the radiologist opens the current exam. Rules key off the worklist, body part, and modality. Tune them badly and radiologists wait on cold-storage retrievals mid-read, or the cache fills with priors nobody ever opens.

See also Archive TieringRadiologist WorklistC-MOVEPACS

Full explanation

A presentation context is the pairing of one SOP Class with one or more transfer syntaxes, proposed by the SCU during association negotiation. The SCP accepts or rejects each one and may accept only a single transfer syntax per context. Two devices that both speak DICOM still fail to talk when their proposed contexts do not overlap.

PC 1  CT Image Storage
      offered : Explicit VR LE, JPEG 2000 Lossless
      accepted: Explicit VR LE
PC 3  MR Image Storage        rejected (abstract syntax not supported)

See also AssociationTransfer SyntaxSOP Class

Full explanation

Also: GSPS, Grayscale Softcopy Presentation State

A Presentation State is a DICOM object that records how images should be displayed without altering the pixels: window level, zoom, pan, flips, shutters, annotations, and overlays. Grayscale Softcopy Presentation State (GSPS) is the common flavor. It lets a radiologist's exact view travel with the study so a downstream viewer reproduces what they saw.

See also Window Center / WidthSOP ClassHanging Protocol

Pseudonymization replaces direct identifiers with a consistent surrogate key so records can still be linked across systems without exposing the real identity. It is not de-identification: to anyone who can reach the link table the data is still PHI under HIPAA, and it stays personal data under GDPR regardless. Useful for research cohorts that need longitudinal joins and a controlled path back.

MRN 4417392 -> SUBJ-0198   (pseudonymized, link table access-controlled)
MRN 4417392 -> removed      (Safe Harbor de-identification)

See also De-identificationExpert DeterminationPHI

Full explanation

Also: Patient Visit segment, PV1

The PV1 segment describes the patient's encounter in an HL7 v2 message: patient class, assigned location, attending and referring physicians, and admit or discharge details. PV1-19 is the visit number, which is not the same thing as the account number in PID-18. One stay can produce several accounts.

See also PID SegmentADT FeedEVN Segment

Full explanation

Also: Query based on ID for DICOM Objects

QIDO-RS is the DICOMweb search service: an HTTP GET with DICOM attributes as query parameters returning DICOM JSON. It maps to C-FIND, but every server supports its own subset of searchable attributes and matching rules, so probe an endpoint before assuming a filter works. Unsupported attributes usually come back as a 400 or an empty result.

GET /studies?PatientID=12345&ModalitiesInStudy=CT&StudyDate=20260101-20260131
Accept: application/dicom+json

See also DICOMwebWADO-RSC-FINDDICOM Tag

Also: Reading worklist

A radiologist worklist is the prioritized queue of studies awaiting interpretation, driven by the RIS or PACS and filtered by subspecialty, priority, and location. Stat exams and AI-flagged critical findings jump the queue, and turnaround time is measured from list entry to signed report. It is not Modality Worklist, which serves scanners rather than readers.

See also Modality WorklistHanging ProtocolPrefetchRIS

Full explanation

Also: Role-Based Access Control

Role-based access control grants permissions to roles rather than to individuals, so a nurse, a billing clerk, and a radiologist see different slices of the same record. It is how the minimum necessary standard becomes enforceable in software. The failure mode is role sprawl: dozens of near-identical roles nobody reviews, quietly accumulating permissions after every staffing change.

role=front_desk   -> demographics, scheduling
role=rn           -> + vitals, notes, orders
role=radiologist  -> + imaging studies, reports

See also Minimum NecessaryAudit LogOAuth ScopesHIPAA Security Rule

Full explanation

Also: Field repetition, Repeating field

An HL7 repetition is one occurrence of a field that may legally appear more than once, with occurrences joined by the tilde character. PID-3 repeats to carry an MRN, an enterprise identifier, and an account number in a single field. Interfaces that read only the first repetition silently lose the rest.

PID|1||MRN12345^^^EPIC^MR~E9900123^^^EMPI^PI~ACC7788^^^EPIC^AN

See also FieldEncoding CharactersPID SegmentPatient ID Merge

Full explanation

Also: (0028,1053), (0028,1052), Hounsfield conversion

Rescale Slope (0028,1053) and Rescale Intercept (0028,1052) convert stored pixel values into meaningful units: output = slope × stored + intercept. On CT this is what produces Hounsfield Units, typically slope 1 and intercept -1024. Any measurement or AI pipeline that reads raw pixels without applying them reports numbers wrong by a constant offset.

RescaleSlope     = 1
RescaleIntercept = -1024
stored 1024  ->  1 * 1024 + (-1024)  =  0 HU  (water)

See also Pixel DataWindow Center / WidthPhotometric Interpretation

Also: Library Resource, Directory Resource

A resource library is a server-level directory of JAR files that Mirth® Connect adds to the classpath, letting channels call custom Java code such as a JDBC driver or a parsing library. Each connector selects which resources it loads. The JARs live on the server filesystem, so a channel promoted to a host missing them deploys cleanly and then fails at runtime.

See also Environment PromotionChannelMirthSyncCode Template

Full explanation

Also: RET, Retired tag

A retired attribute is a tag the DICOM standard no longer defines for new objects but keeps reserved so its number is never reused. Older devices still emit them, so parsers must tolerate rather than reject them. The data dictionary flags them RET: nearly 400 of the roughly 5,200 entries in PS3.6 carry that marker.

See also DICOM TagData ElementConformance Statement

Full explanation

Retry and redelivery are the engine behaviors that re-send a message after a delivery attempt fails, usually on a fixed interval with a cap on attempts. The risk is duplicates: a destination that received a message but never returned an ACK will get it again, so downstream systems need idempotent handling keyed on message control ID.

attempt 1  22:14:03  ERROR  connection refused
attempt 2  22:14:33  ERROR  connection refused
attempt 3  22:15:03  SENT   ACK AA

See also Message QueueACKDestination Connector

Full explanation

Also: Radiology Information System

A RIS is the radiology department's operational system of record: it schedules exams, assigns accession numbers, tracks exam status, and holds the report until it is signed. The PACS owns pixels, the RIS owns workflow, and HL7 v2 order and result messages are what keep the two in agreement.

See also PACSAccession NumberORM MessageORU Message

Full explanation

A router is the logic that sends a message to one or more destinations based on its content rather than a fixed wire. A typical rule reads the message type and sending facility, then fans an ADT out to registration, billing, and the imaging archive while sending lab results only to the EHR. Content-based routing is the reason a hub scales.

ADT^A01  ->  registration, billing, PACS
ORU^R01  ->  EHR only
DFT^P03  ->  billing only

See also Message FilterChannelHub-and-SpokeMessage Type

Full explanation

Safe Harbor is the HIPAA de-identification method that removes 18 specified categories of identifiers, including names, geographic subdivisions smaller than a state, all date elements finer than year, contact details, and any other unique identifying code. It also requires no actual knowledge that what remains could still identify someone. Mechanical and auditable, it costs analytic value: full dates and ZIP codes are the first casualties.

names · geography finer than state · dates finer than year
phone / fax / email · SSN · MRN · account numbers
device serial numbers · full-face photos · biometrics

See also De-identificationExpert DeterminationPHI

Full explanation

Also: Service Class Provider

An SCP (Service Class Provider) is the DICOM role that listens and answers. A PACS acting as Storage SCP accepts C-STORE requests; the same PACS acts as Query/Retrieve SCP when a workstation searches it. Conformance statements list SCU and SCP roles per SOP Class, and the two sides must be complementary or the association fails.

See also SCUConformance StatementC-STORE

Full explanation

Also: Service Class User

An SCU (Service Class User) is the DICOM role that initiates a request. The modality pushing images is the Storage SCU; the workstation querying an archive is the Query/Retrieve SCU. Roles are assigned per SOP Class and per association, so one device is routinely SCU for some services and SCP for others.

See also SCPSOP ClassAssociation

Full explanation

Also: SRA, Security Risk Assessment

A security risk analysis is the accurate, thorough assessment of risks to the confidentiality, integrity, and availability of ePHI required by §164.308(a)(1)(ii)(A). It inventories every system touching ePHI, rates threat likelihood and impact, and records what mitigates each finding. It belongs to the regulated entity, covered entity and business associate alike, and it is the most frequently cited deficiency in OCR enforcement actions.

See also HIPAA Security RuleNIST SP 800-66Covered EntityePHI

Full explanation

Also: HL7 segment

An HL7 segment is one line of an HL7 v2 message, named by the three characters that open it: MSH, PID, OBX. Segments are terminated by a bare carriage return, not a line feed, and that detail trips up parsers fed messages that a text editor rewrote with CRLF.

PID|1||MRN12345^^^EPIC^MR||DOE^JANE^A||19850412|F

See also FieldMSH SegmentZ-SegmentHL7 v2

Full explanation

Also: (0020,000E)

Series Instance UID (0020,000E) identifies one series within a study: a single acquisition, reconstruction, or scan direction. Viewers group thumbnails and fill hanging protocol slots by series, so a modality that reuses or randomizes series UIDs produces studies that display in the wrong order or appear duplicated in the archive.

See also Study Instance UIDPatient / Study / Series / InstanceHanging Protocol

Also: Scheduling Information Unsolicited, SIU^S12

An SIU message notifies other systems about an appointment event: booked (S12), rescheduled (S13), cancelled (S15), or a no-show (S26). The SCH segment carries the appointment itself while AIS, AIG, AIL, and AIP segments describe the service, equipment, location, and staff assigned. Bidirectional scheduling needs one agreed source of truth.

See also PID SegmentModality WorklistTrigger Event

Full explanation

Also: SMART App Launch, Substitutable Medical Applications and Reusable Technologies

SMART on FHIR is the open standard that lets a third-party app launch against an EHR and read or write clinical data through its FHIR API under OAuth 2.0. Two launch modes exist: EHR launch, where patient and encounter context arrive pre-resolved, and standalone launch, where the app discovers the server and authorizes on its own. Epic, Oracle Health, and MEDITECH all support it.

See also OAuth ScopesCapabilityStatementFHIR

Full explanation

Also: SOC 2 Type II, Service Organization Control 2

SOC 2 is an AICPA attestation in which an independent CPA firm reports on a service organization's controls against the Trust Services Criteria: Security, plus any of Availability, Processing Integrity, Confidentiality, and Privacy. Type I judges design at a point in time; Type II judges operating effectiveness over a 6 to 12 month window. There is no pass or fail, only an opinion.

See also HITRUST CSFISO 27001HIPAA Security Rule

Full explanation

Also: Service-Object Pair Class

A SOP Class (Service-Object Pair Class) binds one Information Object Definition to one DICOM service, defining exactly what a system can do with that object type. CT Image Storage, Modality Worklist Information Model FIND, and Verification are all SOP Classes. Devices negotiate them by UID, and conformance statements list which ones each side supports.

See also SOP InstanceSOP Class UIDIODPresentation Context

Full explanation

Also: (0008,0016)

SOP Class UID (0008,0016) is the identifier that declares what type an object is, such as 1.2.840.10008.5.1.4.1.1.2 for CT Image Storage. It appears in the data set, in File Meta Information as Media Storage SOP Class UID, and in every association's presentation contexts. Routing and archive rules are commonly written against this one attribute.

1.2.840.10008.5.1.4.1.1.2      CT Image Storage
1.2.840.10008.5.1.4.1.1.4      MR Image Storage
1.2.840.10008.5.1.4.1.1.88.59  Key Object Selection Document Storage

See also SOP ClassUIDFile Meta Information

Full explanation

A SOP Instance is one concrete object of a SOP Class: a single CT slice, one structured report, one presentation state. Every instance carries its own SOP Instance UID plus the SOP Class UID that says what it is. When people say image or object in a PACS conversation, the precise unit they mean is usually the SOP Instance.

See also SOP ClassSOP Instance UIDPatient / Study / Series / Instance

Also: (0008,0018)

SOP Instance UID (0008,0018) uniquely identifies a single DICOM object worldwide and never changes once assigned. Duplicate instance UIDs are the usual cause of images silently overwriting each other in an archive, which is why de-identification and anonymization tools must remap UIDs consistently rather than regenerating a fresh one per file.

See also UIDSOP InstanceDe-identificationStudy Instance UID

Full explanation

A source connector is the inbound side of a channel: the listener or poller that accepts messages into the engine. Common types are an MLLP listener on a TCP port, an HTTP or FHIR endpoint, a database poller, a file reader watching an SFTP or SMB drop, and a JMS consumer. Each channel has exactly one.

Type    : TCP Listener
Address : 0.0.0.0:6661
Framing : 0x0B <message> 0x1C 0x0D
Response: auto-generate ACK

See also ChannelDestination ConnectorEndpointMLLP

Full explanation

Storage Commitment is the DICOM service in which a sender asks an archive to confirm that specified SOP Instances are safely persisted, and the archive answers asynchronously with N-EVENT-REPORT. Modalities and gateways treat that confirmation as the signal it is safe to delete local copies. Without it, a successful C-STORE only proves the receiver accepted the bytes.

See also C-STORESOP Instance UIDDIMSEPACS

Also: Store Over the Web

STOW-RS is the DICOMweb store service: an HTTP POST of one or more instances as multipart/related, optionally scoped to a specific Study Instance UID. It is the equivalent of C-STORE, and the response body reports success or failure per instance, so a 200 does not mean every instance landed. Check the referenced and failed sequences.

POST /studies
Content-Type: multipart/related; type="application/dicom"; boundary=...

See also DICOMwebC-STOREWADO-RS

Also: DICOM SR, SR

A DICOM Structured Report (SR) stores report content as a coded tree of measurements, findings, and image references instead of free text. Templates such as TID 1500, the Measurement Report, define the expected shape. SR is how imaging AI and quantitative tools return machine-readable output that can be mapped onward to a FHIR DiagnosticReport.

See also SOP ClassKey Object SelectionFHIR ResourceORU Message

Also: (0020,000D)

Study Instance UID (0020,000D) identifies one imaging study across every system that touches it, from modality to archive to viewer to FHIR ImagingStudy. It is the join key for imaging integration work: order reconciliation, prior fetching, and cross-enterprise sharing all hang off it. Splitting or merging studies means rewriting it, which is never simple.

See also Series Instance UIDPatient / Study / Series / InstanceStudy ReconciliationAccession Number

Study reconciliation is the correction workflow for studies whose demographics or order linkage are wrong: images acquired under the wrong patient, a missing accession number, or a study attached to the wrong order. The fix rewrites DICOM attributes in the archive and re-indexes, which is why reconciliation tools are privileged, audited, and never exposed to the whole department.

See also Patient ID MergeAccession NumberModality WorklistAudit Log

Full explanation

Also: HL7 subcomponent

An HL7 subcomponent is the deepest level of a v2 message, produced by splitting a component on the ampersand character. Subcomponents show up inside composite data types, for example the namespace and universal ID parts of an assigning authority. A company name containing an ampersand must be escaped so the parser does not split it.

See also ComponentEncoding CharactersField

Full explanation

Teleradiology is the practice of transmitting imaging studies to a radiologist outside the acquiring facility for interpretation, whether that is overnight coverage, subspecialty reads, or a rural network with no on-site radiologist. Technically it is an image-exchange and identity problem: encrypted transport, cross-organization patient matching, and getting the signed report back into the originating RIS.

See also Zero-Footprint ViewerDICOMwebEncryption in TransitStudy Reconciliation

Full explanation

Also: Message volume

Throughput is the rate an interface sustains, counted in messages per second, per hour, or per day. Healthcare loads are spiky rather than flat: a nightly census ADT batch or a lab autoverification burst can be ten times the daily average, so sizing against a daily total hides the peak that actually breaks the channel.

daily total        1,200,000 msgs
daily average      14 msg/s
23:00 census peak  180 msg/s

See also Message QueueChannelDashboard Statistics

Full explanation

Also: Integration topology diagram, Interface diagram

A topology diagram is the map of which clinical systems exchange data with which, and over what protocol and port. It shows the integration engine as the hub, with the EHR, lab, PACS, pharmacy, and databases as spokes and a labeled connector on every link. Teams draw one before a build, an engine migration, or a security review.

See also Hub-and-SpokeEndpointInterface SpaghettiInterface Specification

Full explanation

A transfer syntax defines how a DICOM data set is encoded: byte ordering, whether VRs are written explicitly, and which compression (if any) applies to pixel data. Every Part 10 file names one in (0002,0010), and every association negotiates one per presentation context. A mismatch is the classic cause of unreadable images.

See also Implicit VR Little EndianExplicit VR Little EndianPresentation ContextPixel Data

Full explanation

A transformer is the step in a channel that rewrites a message from the source format into what the destination expects. In practice that means mapping HL7 v2 fields to FHIR elements, translating code sets such as ICD-10 to SNOMED, defaulting missing values, and enriching from a lookup table. Most production defects in an interface live here, not in the transport.

See also ChannelMessage FilterSegmentFHIR Resource

Full explanation

A trigger event is the real-world occurrence that causes a system to emit an HL7 v2 message: a patient is admitted, a result is verified, an appointment is cancelled. The event code appears in MSH-9 alongside the message code, as in ADT^A01, and ADT and MDM messages repeat it in EVN-1.

See also Message TypeEVN SegmentADT FeedMSH Segment

Full explanation

Also: Unique Identifier, DICOM UID

A DICOM UID is a globally unique identifier written as dot-separated numbers, at most 64 characters, with no leading zeros in a component. Standard UIDs live under the 1.2.840.10008 root; every vendor and site registers its own root for the instance, study, and series UIDs it generates. UIDs are matched as exact strings, never with wildcards.

See also SOP Instance UIDStudy Instance UIDValue Representation

Also: Unified Procedure Step, Worklist Service

UPS-RS is the DICOMweb worklist service built on Unified Procedure Step, letting clients create, claim, update, and subscribe to work items over HTTP. It is the modern successor to Modality Worklist plus MPPS and a natural fit for AI inference queues where a scheduler hands studies to workers. Adoption is still thin outside newer platforms.

See also DICOMwebModality WorklistMPPS

Also: US Core Implementation Guide

US Core is the HL7 implementation guide that defines the minimum FHIR data US certified health IT must expose, and the profile set through which USCDI data classes are realized. It fixes required elements, Must Support rules, and terminology bindings to SNOMED CT, LOINC, RxNorm, and ICD-10-CM. Version matters: an app built against US Core 3.1.1 can fail validation on a server publishing 6.1.0 profiles.

See also Implementation GuideFHIR ProfileValueSet and CodeSystem

Full explanation

Also: VM

Value Multiplicity (VM) states how many values an attribute may carry, written as 1, 3, 1-n, or 2-2n. Image Position (Patient) is VM 3 because it holds x, y, and z; Image Orientation (Patient) is VM 6. Multiple values are separated by backslashes in string VRs, which trips up parsers that split on the wrong delimiter.

(0020,0032) ImagePositionPatient  DS  VM=3   -103.6\-166.5\12.75
(0028,1050) WindowCenter          DS  VM=1-n  -600\40

See also Value RepresentationData ElementImage Position (Patient)

Full explanation

Also: VR

A Value Representation (VR) is the two-letter code that declares an attribute's data type: PN for person names, DA for dates, UI for UIDs, DS for decimal strings, SQ for nested sequences. The VR fixes the value's format, its maximum length, and how a C-FIND match against it behaves. DICOM defines 34 of them.

See also Value MultiplicityData ElementTransfer Syntax

Full explanation

Also: ValueSet, CodeSystem, FHIR terminology

ValueSet and CodeSystem are FHIR's two terminology resources: a CodeSystem defines codes and their meanings (LOINC, SNOMED CT, RxNorm), and a ValueSet selects a subset of those codes for use in a specific element. Profiles bind elements to ValueSets, and a terminology server resolves them through the $expand and $validate-code operations. Local site codes that were never mapped are a frequent validation failure.

See also FHIR ProfileUS CoreFHIR Resource

Full explanation

Also: Vendor Neutral Archive, Vendor-Neutral Archive

A VNA is a storage layer that owns long-term imaging data independently of any PACS vendor, so replacing the PACS does not mean migrating petabytes with it. It speaks standard DICOM plus DICOMweb or XDS-I, which turns the next migration into a standards-level export rather than a proprietary database rewrite.

See also PACSEnterprise ImagingArchive TieringXDS-I

Full explanation

Also: Web Access to DICOM Objects by RESTful Services

WADO-RS is the DICOMweb retrieve service: an HTTP GET against a study, series, instance, or frame path returns the requested objects as multipart/related, or as rendered JPEG or PNG through the /rendered suffix. It is the rough equivalent of C-GET and the transport every zero-footprint viewer relies on to pull images into a browser.

GET /studies/1.2.840.113619.2.55.3.12345
GET /studies/{study}/series/{series}/instances/{instance}
GET /studies/{study}/series/{series}/instances/{instance}/frames/1/rendered

See also DICOMwebQIDO-RSZero-Footprint ViewerC-GET

Also: Window level, W/L, (0028,1050), (0028,1051)

Window Center (0028,1050) and Window Width (0028,1051) define the display window applied after rescaling: the center picks which value sits mid-gray and the width sets how many values span black to white. They are presentation hints, not changes to stored pixels, so a lung window and a bone window are the same data displayed twice.

See also Rescale Slope / InterceptPixel DataPresentation State

Also: XDS-I.b, Cross-Enterprise Document Sharing for Imaging

XDS-I is the IHE profile that extends cross-enterprise document sharing to imaging, letting one organization publish a Key Object Selection manifest of a study to a shared registry so another can retrieve the images without a direct DICOM association. The current revision is XDS-I.b, and it is the standards-based alternative to point-to-point image exchange between health systems.

See also VNAEnterprise ImagingTeleradiologyKey Object Selection

Full explanation

Also: Custom segment, Z segment

A Z-segment is a site-defined or vendor-defined HL7 v2 segment whose three-character name begins with Z, used to carry data the standard has no field for. Because Z-segments are outside the standard, ZPI in one hospital and ZPI in another mean nothing alike, and each one needs its own written specification.

ZPD|1|VIP|ES|PORTAL_ACTIVE

See also SegmentInterface SpecificationTransformerHL7 v2

Full explanation

Also: ZFP viewer, Web viewer

A zero-footprint viewer is a diagnostic or review image viewer that runs entirely in the browser: no thick client, no Java applet, no per-workstation install. It fetches pixels over DICOMweb rather than DIMSE, which makes it firewall-friendly and embeddable inside an EHR through a context launch. OHIF is the widely deployed open-source example.

See also DICOMwebWADO-RSSMART on FHIRHanging Protocol

Full explanation