Search Saga IT
HL7 · FHIR · DICOM · Mirth Connect · OIE: docs, guides & tools
Browse the full Saga IT library: 337 pages across HL7/FHIR, DICOM, Mirth Connect, OIE, and our services. Or search above for instant matches plus deep full-text results.
HL7 & FHIR
- product HL7 Workbench Free online HL7 v2 parser, viewer & validator. Parse, decode & format messages into a tree and browse the spec across 14 versions — all in-browser.
- service HL7 Integration Services HL7 integration for healthcare systems — ADT, ORU, ORM, SIU v2 interfaces, HL7 v2-to-FHIR mapping, and managed interface engine operations.
- service FHIR API Integration Services FHIR API development: FHIR R4 API design, SMART on FHIR apps, Bulk FHIR export, CDS Hooks, and FHIR server implementation.
- page HL7 v2 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.
- page 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.
- page 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.
- page 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.
- page 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.
- page Repetition 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.
- page MSH Segment 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.
- page PID Segment 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.
- page PV1 Segment 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.
- page OBR Segment 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.
- page OBX Segment 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.
- page ORC Segment 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.
- page EVN Segment 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.
- page NK1 Segment 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.
- page AL1 Segment 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.
- page DG1 Segment 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.
- page Trigger Event 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.
- page Message Type 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.
- page ADT Feed 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.
- page ORM Message 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.
- page ORU Message 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.
- page SIU Message 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.
- page DFT Message 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.
- page MDM Message 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.
- page ACK 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.
- page MLLP 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.
- page Encoding Characters 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.
- page 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.
- page HL7 v2 Versions 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.
- page 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.
- page FHIR Resource 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.
- page FHIR 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.
- page FHIR Reference 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.
- page FHIR Profile 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.
- page Implementation Guide 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.
- page US Core 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.
- page SMART on FHIR 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.
- page OAuth 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.
- page CapabilityStatement 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.
- page FHIR Search Parameter 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.
- page Bulk Data 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.
- page NDJSON 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.
- page FHIR Versions 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.
- page ValueSet and CodeSystem 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.
- page FHIRPath 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.
- docs HL7 FAQ: Messages, Segments & Integration Answers to common HL7 v2 questions: message types, segments and delimiters, MLLP transport, acknowledgments, versions, and interface troubleshooting.
- docs HL7 v2 Sample Messages & Examples HL7 v2 sample messages and examples across ADT, ORU, ORM, SIU, and MDM, annotated segment by segment, ready to copy or download as .hl7 files.
- docs What Is HL7? Standards, Definition & v2 Reference What is HL7? Definition of Health Level Seven standards, HL7 v2 message types, segment reference, and integration tools for healthcare IT professionals.
- docs HL7 ACK Message: Acknowledgment & Errors HL7 ACK (Acknowledgment) message reference. MSA segment codes, ERR segment error handling, original vs enhanced acknowledgment modes, and retries.
- docs HL7 ADT Message: Event Types & Structure HL7 ADT (Admit, Discharge, Transfer) message reference. A01 through A44 event types, segment structure, and PID/PV1 field breakdowns.
- docs HL7 DFT Message: Financial Transactions HL7 DFT (Detailed Financial Transaction) message reference: DFT^P03 structure, FT1 segment fields, charge codes, and charge-posting workflows to billing.
- docs HL7 v2 Message Types Reference HL7 v2 message types reference. ADT, ORU, ORM, SIU, DFT, MDM, and ACK messages with event types, segment structure, and usage guidance.
- docs HL7 MDM Message: Medical Document Management HL7 MDM (Medical Document Management) message reference. T02 through T11 event types, TXA segment structure, and document status tracking.
- docs HL7 ORM Message: Order Messaging Complete reference for HL7 ORM (Order Message) including ORM^O01 structure, ORC order control codes, order lifecycle, and annotated sample messages.
- docs HL7 ORU Message: Observation Results HL7 ORU (Observation Result Unsolicited) message reference: ORU^R01 structure, OBX value types, OBR fields, result status codes, and lab examples.
- docs HL7 Query Messages: QBP & RSP HL7 v2 query messages reference. QBP Query by Parameter and RSP responses: QPD, RCP, and QAK segments, QBP^Q11/RSP^K11 pairs, and IIS lookups.
- docs HL7 SIU Message: Scheduling Information HL7 SIU (Scheduling Information Unsolicited) message reference: S12 through S26 event types, SCH and resource segments, status codes, and examples.
- docs HL7 VXU Message: Immunization Records HL7 VXU (Unsolicited Vaccination Record Update) reference: VXU^V04 structure, RXA/RXR segments, immunization registry reporting, with a sample.
- docs HL7 v2 Data Types Reference Reference for common HL7 v2 data types. CX, XPN, XAD, CE, CWE, TS, HD, PL, XCN, and other composite types with component breakdowns and examples.
- docs HL7 v2 Encoding & Delimiters How HL7 v2 messages are encoded: the segment/field/component hierarchy, the MSH delimiter declaration, encoding characters, and escape sequences.
- docs MLLP Protocol: HL7 Framing Characters, ACKs, Ports, TLS MLLP (Minimal Lower Layer Protocol) wraps HL7 v2 messages over TCP: 0x0B and 0x1C 0x0D framing bytes, ACK handling, ports, TLS, and Mirth Connect setup.
- docs HL7 Interface Troubleshooting Guide Diagnose HL7 v2 interface problems by symptom: MLLP connection refused, missing ACKs, ACK timeouts, duplicate messages, queue backups, patient matching.
- docs HL7 Versions: v2.1 to v2.9 Compared HL7 v2 version history from v2.1 to v2.9. Why v2.5.1 is the most deployed, how MSH-12 declares the version, backward compatibility, and v3 vs FHIR.
- docs HL7 AL1 Segment: Patient Allergy Information Complete field reference for the HL7 AL1 (Patient Allergy) segment. Allergy types, severity codes, reaction descriptions, and patient safety integration.
- docs HL7 DG1 Segment: Diagnosis HL7 DG1 (Diagnosis) segment field reference: ICD-10 diagnosis codes, diagnosis types and coding systems, DRG grouping, and clinical documentation fields.
- docs HL7 FT1 Segment: Financial Transaction HL7 FT1 (Financial Transaction) segment field reference. Transaction types, CPT/HCPCS procedure codes, charge amounts, and modifier handling.
- docs HL7 GT1 Segment: Guarantor HL7 GT1 (Guarantor) segment field reference. Guarantor demographics, employer information, financial responsibility, and billing integration.
- docs HL7 EVN Segment: Event Type Complete field reference for the HL7 EVN (Event Type) segment. Trigger event codes, event timestamps, operator identification, and event reason codes.
- docs HL7 IN1 Segment: Insurance Fields, COB and Payer ID Mapping HL7 IN1 segment field reference: IN1-2 plan ID, IN1-3 payer ID, group number, coverage dates, and the COB order that drives billing interfaces.
- docs HL7 MSH Segment: Message Header HL7 MSH (Message Header) segment field reference. Encoding characters, sending/receiving applications, message type, processing ID, and version.
- docs HL7 v2 Segment Reference HL7 v2 segment reference. Field-by-field guides for MSH, PID, PV1, ORC, OBR, OBX, and 10+ additional segments organized by clinical workflow.
- docs HL7 NK1 Segment: Next of Kin HL7 NK1 (Next of Kin) segment field reference. Emergency contacts, responsible parties, relationship codes, contact roles, and HIPAA considerations.
- docs HL7 NTE Segment: Notes and Comments HL7 NTE (Notes and Comments) segment field reference. Comment types, source identification, context-dependent usage, and free-text note handling.
- docs HL7 OBR Segment: Observation Request HL7 OBR (Observation Request) segment field reference. Universal service identifier, specimen info, ordering provider, and result status fields.
- docs HL7 ORC Segment: Common Order Complete field reference for the HL7 ORC (Common Order) segment. Order control codes, placer/filler numbers, order status, and order lifecycle management.
- docs HL7 OBX Segment: Observation/Result HL7 OBX (Observation/Result) segment field reference. Value types (NM, ST, CE, TX, ED), result status codes, abnormal flags, and LOINC coding.
- docs HL7 PV1 Segment: Patient Visit HL7 PV1 (Patient Visit) segment field reference. Patient class, assigned location, attending physician, admit/discharge dates, and visit tracking.
- docs HL7 PID Segment: Patient Identification HL7 PID (Patient Identification) segment field reference: every field from PID-3 lists to demographics, with data types and EHR mapping guidance.
- docs HL7 SCH Segment: Scheduling Activity HL7 SCH (Scheduling Activity) segment field reference. Appointment identifiers, scheduling resources, duration, and appointment status fields.
- docs HL7 TXA Segment: Document Header HL7 TXA (Transcription Document Header) segment field reference. Document types, authentication status, authorship, and lifecycle management.
- docs HL7 v2 Reference Guides HL7 v2 reference guides: data types, encoding and delimiters, the MLLP transport protocol, version history from v2.1 to v2.9, and interface troubleshooting.
- blog FHIR R4 Implementation Guide for Healthcare APIs FHIR R4 implementation guide for healthcare developers: resource profiling, US Core, CapabilityStatement, search, validation, and production pitfalls.
- blog Azure API for FHIR: Migration Guide for 2026 Migrate to Azure Health Data Services before Azure API for FHIR retires September 30, 2026. Strategies, OSS migration tool, pre-migration gotchas, FAQ.
- blog FHIR R4 vs R5 vs R6: Which to Implement? Compare FHIR R4, R5, and R6: release dates, EHR vendor support, US Core alignment, SubscriptionTopic framework, and the practical decision framework.
- blog HL7 Message Types: ADT, ORU, ORM, DFT & SIU HL7 v2 message types reference: ADT, ORM, ORU, DFT, SIU, and MDM with annotated examples, segment breakdowns, and real-world integration patterns.
- blog HL7 vs FHIR: Differences, Use Cases & When to Use Each (2026) HL7 v2 vs FHIR explained: architecture, message anatomy, regulatory mandates (CMS-9115-F, CMS-0057-F), cost, and a hybrid migration path.
- blog Build a SMART on FHIR App: OAuth, Launch & Publishing (2026) SMART on FHIR developer guide: OAuth 2.0 flow, EHR launch, scopes, refresh tokens, backend services, and publishing to Epic Showroom + Oracle Health Code.
- blog eClinicalWorks Bulk FHIR $export: A Developer's Guide How to use eClinicalWorks' Bulk Data $export: Backend Services OAuth, the Patient and Group $export kickoff, async polling, NDJSON output, and eCW gotchas.
- blog Medical Device Integration with Epic & Cerner How medical devices, modalities, and PACS connect to Epic and Oracle Health (Cerner): HL7 v2 ORU/ORM, DICOM/DICOMweb, Epic Bridges, FHIR, CareAware iBus.
DICOM & Imaging
- service Medical Imaging, DICOM & PACS Integration Medical imaging integration services — DICOM, DICOMweb, and PACS connectivity, VNA migrations, and cloud imaging for health-tech vendors.
- dicom DICOM Tools & References Free browser-based DICOM tools: viewer, tag editor, validator, sample files, plus the NEMA PS3 standard browser. No install — files stay local.
- dicom Free DICOM Viewer Free online DICOM viewer and DCM file reader. Open .dcm files in your browser — no install, no upload. Works on Mac, Windows, and Linux.
- dicom Sample DICOM Files Free DICOM sample files — CT, MR, mammography, X-ray, PET, ultrasound. Real .dcm + .zip studies, CC-BY licensed, de-identified, no signup.
- dicom DICOM Anonymizer Free online DICOM anonymizer. De-identify .dcm files per PS3.15 Basic Profile in your browser. No upload, files never leave your computer.
- dicom DICOM Tag Editor Free online DICOM tag editor. Edit .dcm metadata in your browser with VR-aware validation. PatientID, AccessionNumber, StudyUID — local only.
- dicom DICOM Validator Free online DICOM conformance validator. Check .dcm files against NEMA PS3 CIOD and module rules. Reports missing Type 1 tags, VR mismatches.
- dicom Learn DICOM Narrative explainers for the DICOM standard — what DICOM is, how it works, service classes, file format, PACS, security, and implementation guidance.
- dicom DICOM Standard Browser Browse the DICOM standard: 5,213 tags, 174 CIODs, 412 modules, 320 SOP classes, 63 transfer syntaxes — plus FHIR, HL7 v2, and Mirth Connect notes.
- page AE Title 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.
- page Association 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.
- page DIMSE 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.
- page SCU 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.
- page SCP 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.
- page C-STORE 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.
- page C-FIND 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.
- page C-MOVE 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.
- page C-GET 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.
- page C-ECHO 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.
- page Presentation Context 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.
- page Transfer Syntax 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.
- page Implicit VR Little Endian 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.
- page Explicit VR Little Endian 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.
- page JPEG 2000 Transfer Syntax 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.
- page Value Representation 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.
- page Value Multiplicity 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.
- page DICOM Tag 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.
- page Data Element 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.
- page Data Set 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.
- page IOD 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.
- page CIOD 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.
- page 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.
- page 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.
- page SOP 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.
- page SOP Instance 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.
- page SOP Class UID 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.
- page SOP Instance UID 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.
- page 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.
- page Study Instance UID 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.
- page Series Instance UID 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.
- page Patient / Study / Series / Instance 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.
- page File Meta Information 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.
- page 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.
- page Part 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.
- page Pixel Data 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.
- page Photometric Interpretation 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.
- page Rescale Slope / Intercept 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.
- page Window Center / Width 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.
- page Image Position (Patient) 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.
- page Image Orientation (Patient) 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.
- page Frame of Reference 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.
- page Multi-frame 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.
- page Structured Report 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.
- page 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.
- page Key Object Selection 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.
- page Conformance Statement 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.
- page DICOMweb 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.
- page WADO-RS 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.
- page QIDO-RS 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.
- page STOW-RS 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.
- page UPS-RS 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.
- page Storage Commitment 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.
- page Retired Attribute 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.
- page PACS 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.
- page VNA 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.
- page RIS 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.
- page Modality 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.
- page Modality Worklist 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.
- page MPPS 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.
- page Accession Number 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.
- page Order-to-Report Lifecycle 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.
- page Hanging Protocol 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.
- page Prefetch 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.
- page Imaging Routing Rules 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.
- page Archive Tiering 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.
- page Zero-Footprint 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.
- page Enterprise Imaging 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.
- page Radiologist 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.
- page Teleradiology 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.
- page CD 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.
- page Study Reconciliation 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.
- page Patient ID 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.
- page Dose Reporting 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.
- page XDS-I 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.
MirthSync
- product MirthSync CLI Open-source CLI for Mirth Connect version control. Sync channels, code templates, and configs to Git — enable CI/CD pipelines and team collaboration.
- product MirthSync Plugin Free, open-source (Apache 2.0) Mirth Connect Admin Console extension with embedded Git. One-click pull, push, diff for channels — no terminal needed.
- product MirthSync — Mirth Connect IDE for VS Code & Cursor Free Mirth Connect IDE for VS Code, Cursor & Windsurf — IntelliSense, channel sync, security diagnostics, and a one-command local Mirth Docker stack.
- page MirthSync Plugin Download Download the MirthSync Plugin — a free extension that adds Git-based version control to Mirth Connect and OIE. Installs in under 5 minutes.
- page Mirth Connect 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.
- page Open Integration Engine 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.
- page MirthSync 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.
- page Channel Group 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.
- page Code Template 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.
- page Configuration Map 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.
- page Global 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.
- page 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.
- page Admin Console 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.
- page 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.
- page Embedded Git 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.
- page Channel Export XML 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.
- page Resource Library 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.
- page Alert 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.
- page Dashboard 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.
- docs Command Cheat Sheet Quick reference for MirthSync CLI commands. Covers pull, push, Git operations, branching, environment management, and troubleshooting.
- docs FAQ MirthSync FAQ: answers to common questions about CLI and Plugin. Solutions for connection errors, auth issues, and Git conflicts.
- docs mirthSync Git-based version control for Mirth Connect & OIE via CLI, Admin Console plugin, and VS Code extension to manage integration configs as code.
- docs MirthSync Resources & Community Comprehensive resource guide for MirthSync - external documentation, community links, and support channels for Mirth Connect version control
- docs Support Get help with MirthSync: community support, bug reporting, and professional healthcare IT consulting services from Saga IT.
- docs CLI Reference Complete command-line interface reference for MirthSync - pull, push, and git operations for Mirth Connect and Open Integration Engine
- docs Install MirthSync CLI Install MirthSync CLI on Windows, macOS, and Linux. Java prerequisites, JAR download, configuration, and troubleshooting guide.
- docs MirthSync CLI Overview MirthSync brings Git-based version control and CI/CD to Mirth Connect and OIE. Open-source CLI with embedded Git for healthcare.
- docs MirthSync CLI Setup Set up MirthSync for Mirth Connect or OIE. Configure connections, manage credentials, use disk modes, and start version control.
- docs Backup & Disaster Recovery Back up Mirth Connect channels and configurations for disaster recovery. Git-based strategies using MirthSync CLI and Plugin.
- docs Best Practices Best practices for using MirthSync in production environments. Repository structure, branching strategy, and team workflows.
- docs CI/CD Setup Automate Mirth Connect and OIE deployments with CI/CD pipelines. GitHub Actions and GitLab CI examples using MirthSync CLI.
- docs Multi-Environment Management Manage dev, staging, and production Mirth Connect environments with MirthSync. Configuration isolation and promotion workflows.
- docs Version Control Workflow Complete guide to Git workflows for Mirth Connect and OIE with MirthSync. Branching strategies, pull/push patterns, and team collaboration.
- docs Video Tutorials Video tutorials and walkthroughs for MirthSync CLI and Plugin - learn version control for Mirth Connect through hands-on demonstrations
- docs IDE Integration Supercharge your Mirth Connect development with modern IDE features - syntax highlighting, code completion, debugging, and more
- docs MirthSync IDE Setup Get started using your IDE with MirthSync in 5 minutes. Editor configuration, extension setup, and Git integration walkthrough.
- docs VS Code Setup Optimize VS Code for MirthSync development with recommended extensions, workspace settings, and Git integration configuration.
- docs Plugin Guide Complete guide to the MirthSync Admin Console Plugin: interface walkthrough, features, and version control workflows for Mirth Connect.
- docs Install MirthSync Plugin Install MirthSync Plugin for Mirth Connect Admin Console. Two installation methods with embedded Git and CLI in a single JAR.
- docs MirthSync Plugin Overview MirthSync Plugin - All-in-one Admin Console extension with embedded Git, MirthSync CLI, and graphical interface for Mirth Connect version control
- docs Tutorials Step-by-step tutorials for common MirthSync Plugin workflows with screenshots and detailed instructions for Mirth Connect.
- docs User Guide Guide to the MirthSync VS Code extension covering connections, tree views, sync, language features, diagnostics, snippets, debugger, and file explorer.
- docs Installation Install the MirthSync VS Code Extension from the marketplace or VSIX file. Set up your first Mirth Connect server connection in minutes.
- docs Local Mirth One-command Docker Compose stack for OIE / Mirth / BridgeLink, scaffolded into your VS Code workspace. Commands, settings, and troubleshooting reference.
- docs MirthSync VS Code Extension Overview MirthSync VS Code extension, a dev environment for Mirth Connect with IntelliSense, channel tree views, multi-server sync, and connection management.
- docs Commands & Settings Complete reference for all MirthSync VS Code Extension commands, configuration settings, and troubleshooting
- docs MirthSync VS Code Extension Resources Links, community resources, and external references for the MirthSync VS Code Extension
Mirth Connect & OIE
- page Download Mirth Connect (Open Source) Download Mirth Connect free — the open-source lineage continues as the Open Integration Engine (OIE). Installer, Docker image, and Git plugin.
- service Mirth Connect Services & Consulting Mirth Connect HL7 integration, implementation, and support — channel development, FHIR mapping, AWS/Azure cloud deployment, and 24/7 managed services.
- service Open Integration Engine (OIE) Consulting & Migration Open Integration Engine (OIE) consulting — Mirth Connect migration, channel development, AWS / Azure deployment, and 24/7 managed services.
- service Healthcare Integration Engine Services Integration engine consulting, deployment, and managed services for Mirth Connect, OIE, and enterprise platforms.
- page 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.
- page Hub-and-Spoke 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.
- page Point-to-Point 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.
- page Interface Spaghetti 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.
- page Channel 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.
- page Source Connector 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.
- page Destination Connector 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.
- page Transformer 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.
- page Message Filter 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.
- page Router 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.
- page Message Queue 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.
- page Message Store 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.
- page Retry and Redelivery 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.
- page Throughput 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.
- page Interface Specification 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.
- page Endpoint 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.
- page Port 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.
- page Firewall 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.
- page Middleware 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.
- page ESB 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.
- page Topology 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.
- page Environment 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.
- docs Mirth Connect & OIE Database Troubleshooting Resolve database issues in Mirth Connect and OIE. Step-by-step fixes for MySQL, SQL Server, Oracle, and PostgreSQL connectivity.
- docs OIE Docker Image Run Mirth Connect and OIE in Docker with pre-installed plugins. Quick start, docker-compose with PostgreSQL, environment variables, volumes, and secrets.
- docs Mirth Connect & OIE FAQ Mirth Connect and OIE FAQ: installation, channel development, integration patterns, performance tuning, security, and troubleshooting.
- docs Mirth Connect & OIE Resource Center Resources for Mirth Connect and OIE. FAQ, troubleshooting, database diagnostics, and integration best practices for healthcare IT.
- docs Mirth Connect & OIE Troubleshooting Guide Troubleshooting Mirth Connect and OIE. Solutions for database connections, performance, channel errors, SSL/TLS, and startup issues.
- blog CI/CD for Mirth Connect with mirthSync Implement CI/CD for Mirth Connect with mirthSync and GitHub Actions. Automate channel deployments and environment promotion workflows.
- blog Mirth Connect Alternatives 2026: OIE, BridgeLink & More 14 Mirth Connect alternatives compared for 2026: open source forks OIE and BridgeLink, plus Rhapsody, Iguana, Qvera, scored by cost, migration, and risk.
- blog Mirth Connect Best Practices for 2026 (Also Applies to OIE & BridgeLink) 2026 Mirth Connect best practices: channel naming, connectors, transformers, error handling, pruning, monitoring, security, and MirthSync CI/CD.
- blog DICOM Over TLS with Mirth Connect: Tutorial Secure DICOM over TLS with Mirth Connect. Step-by-step tutorial for certificate generation, keystore setup, and HIPAA-compliant imaging exchange.
- blog HL7 Messages to AWS SQS with Mirth Connect Step-by-step Mirth Connect AWS SQS tutorial. Configure IAM, install the AWS SDK, and route HL7 messages to SQS queues with sample code.
- blog How to Install Mirth Connect, OIE, or BridgeLink (2026 Docker Quickstart) Spin up Mirth Connect, OIE, or BridgeLink locally in 5 minutes with the MirthSync VS Code extension's one-command Docker stack, plus installer paths.
- blog OIE vs BridgeLink vs Commercial Mirth Connect: 2026 Comparison Compare OIE, Innovar Healthcare's BridgeLink, and commercial Mirth Connect 4.6+: features, licensing, support, migration effort, and total cost.
- blog Mirth Connect development in VS Code and Cursor MirthSync is now on Open VSX, so our Mirth Connect & OIE extension installs in Cursor, Windsurf, and VSCodium, not just VS Code. Here's why that took a second marketplace.
Services & Company
- tool Unified Search Search across Saga IT services, products, blog posts, docs, and the DICOM & HL7 references from one place.
- tool Integration Topology Builder Free in-browser tool to diagram healthcare integration networks — HL7 v2/MLLP, FHIR, DICOM & SQL across EHR, PACS & integration engines. PDF/JSON export.
- product OpenShare Operate, share, and monitor healthcare integrations from one browser console. Built on the Open Integration Engine. Now in open beta.
- service EHR & EMR Integration Services EHR & EMR integration for Epic, Oracle Health, MEDITECH, eClinicalWorks, NextGen, athenahealth, Allscripts — HL7 v2, FHIR R4, and SMART on FHIR.
- service Epic Consulting & Integration Epic consulting for App Orchard developers, IDNs, and digital health teams. FHIR R4, Bridges, Care Everywhere, MyChart, and Vendor Services.
- service Healthcare Interoperability Services Healthcare interoperability consulting across HL7 v2, FHIR R4, DICOM, and X12 EDI. CMS-0057-F compliance, TEFCA QHIN onboarding, IHE conformance.
- service TEFCA Integration Services TEFCA in healthcare: the Trusted Exchange Framework powers nationwide data exchange via QHINs. Saga IT delivers QHIN onboarding & compliance.
- service Medical Device Integration & Consulting Medical device consulting & integration — IEC 62304, ISO 14971, FDA 510(k), IEEE 11073 SDC, IHE PCD, IoMT, and EHR connectivity for monitors and pumps.
- service Healthcare Software Development Custom healthcare software development company: HIPAA-compliant SaMD (IEC 62304), cloud EHR builds, and integrations for regulated care.
- service Healthcare App Development Healthcare app development services: HIPAA-compliant patient portals, telehealth platforms, RPM, and mobile health apps with EHR + FHIR integration.
- service Healthcare Data Analytics & OMOP CDM Healthcare data analytics and OMOP CDM services. Clinical data warehousing, ETL pipelines, population health analytics, and real-world evidence studies.
- service HIPAA Compliance Programs HIPAA compliance consulting: gap analysis, BAA management, technical safeguards, breach notification, and ongoing compliance monitoring.
- service Healthcare Cybersecurity Services Healthcare cybersecurity: penetration testing, vulnerability assessments, security architecture, medical device security, and incident response.
- service Healthcare Cloud Services HIPAA-compliant cloud infrastructure on AWS and Azure. Healthcare cloud migration, managed services, and cost optimization for health systems.
- service Healthcare Cloud Security Healthcare cloud security: HIPAA compliance, security architecture, IAM, encryption, and HITRUST readiness for AWS and Azure.
- page About Saga IT US-based healthcare IT consulting firm specializing in HL7, FHIR, EHR integration, and HIPAA-compliant development. Founded 2016 in West Palm Beach, FL.
- page Contact Us Get in touch with Saga IT for healthcare IT consulting. Schedule a free consultation about HL7, FHIR integration, cloud, or cybersecurity projects.
- page Healthcare IT Consulting in West Palm Beach Healthcare IT consulting in West Palm Beach, FL. EHR integration, HL7/FHIR interoperability, HIPAA compliance, and cybersecurity services.
- page Privacy Policy How Saga IT collects, uses, and protects your personal information. Covers data handling, cookies, and your rights under privacy laws.
- page PHI 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.
- page ePHI 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.
- page HIPAA 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.
- page HIPAA Privacy Rule 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.
- page HIPAA Security Rule 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.
- page Breach Notification Rule 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.
- page BAA 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.
- page Covered Entity 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.
- page Business Associate 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.
- page Minimum Necessary 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.
- page De-identification 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.
- page Safe Harbor 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.
- page Expert Determination 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.
- page Pseudonymization 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.
- page DICOM 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.
- page Audit Log 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.
- page RBAC 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.
- page Encryption at Rest 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.
- page Encryption in Transit 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.
- page SOC 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.
- page HITRUST CSF 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.
- page ISO 27001 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.
- page NIST 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.
- page Security Risk Analysis 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.
- page Incident Response 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.
- page 21 CFR 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.
- docs Documentation & Resources Documentation and technical references for healthcare IT, covering MirthSync, Mirth Connect, HL7, DICOM, and interoperability.
- blog C-CDA Healthcare Guide: Clinical Document Architecture Learn what C-CDA is, how it structures clinical documents, its XML templates, document types, and when to use C-CDA vs FHIR for health exchange.
- blog CMS-0057-F Compliance Checklist for 2027 CMS-0057-F compliance: the four required FHIR APIs (Patient Access, Provider Access, Payer-to-Payer, Prior Auth), Da Vinci IGs, and the timeline.
- blog EHR & PACS Integration: A Vendor's Guide Strategies for third-party vendors integrating with EHR + PACS systems. HL7 v2, FHIR R4, DICOM, VPN, and cloud PACS gateway methods compared.
- blog Complete Guide to EHR & EMR Integration Practical EHR + EMR integration guide: HL7 v2, FHIR R4, Epic, Oracle Health, MEDITECH, athenahealth, eClinicalWorks, integration engines, and architecture.
- blog FDA Medical Device Cybersecurity: Section 524B, SBOM & QMSR FDA Section 524B explained: cyber-device premarket submission requirements, SBOM mandates (CycloneDX/SPDX), June 2025 guidance, and QMSR readiness.
- blog How to Integrate with Epic EHR: 2026 Developer's Guide 2026 guide to Epic EHR integration: FHIR R4 APIs, SMART on FHIR auth, HL7 v2 Bridges, CDS Hooks, MyChart, and Vendor Services + Showroom.
- blog Building AI-Ready Healthcare Data Pipelines Build HIPAA-compliant healthcare AI data pipelines: FHIR bulk export ($export/NDJSON), OMOP CDM transformation, de-identification, NLP, and ML serving.
- blog Getting Started with MirthSync Get started with MirthSync for Mirth Connect. Install, configure, and export channels, migrate configs, and enable version control.
- blog Healthcare App Development Cost: 2026 Pricing Guide Realistic healthcare app development costs by type: patient portals, telehealth, RPM, and CDS. Covers HIPAA, EHR integration, and budgeting.
- blog Healthcare Cloud Migration: AWS vs Azure vs GCP AWS vs Azure vs GCP for healthcare workloads. HIPAA BAA coverage, FHIR services, HL7 support, EHR hosting, and migration costs. 2026 buyer's guide.
- blog Healthcare EDI 835: Understanding Remittance Advice Files Learn how EDI 835 remittance advice files work, their X12 structure, CLP/SVC loops, adjustment reason codes, and how to process them in healthcare billing.
- blog Healthcare EDI 837: Claims Submission Guide for Providers Complete guide to EDI 837 claims files. Learn 837P vs 837I vs 837D differences, X12 structure, submission workflows, and common rejection codes.
- blog HIPAA Business Associate Agreement Checklist Guide to HIPAA business associate agreements: required §164.504(e) provisions, subcontractor BAAs, cloud-provider BAAs, and an audit checklist.
- blog HIPAA-Compliant Software Development: A Developer's Guide HIPAA software development guide covering technical safeguards, encryption, access control, audit logging, and security risk assessment.
- blog HIPAA Security Rule 2026: What the Update Means The proposed 2026 HIPAA Security Rule would require MFA, AES-256 encryption, 72-hour disaster recovery, and annual pen testing. Here's what's coming.
- blog HITRUST vs SOC 2: Which Does Your Org Need? HITRUST vs SOC 2 (and HIPAA) for healthcare vendors selling to hospitals and health plans. Compare costs, timelines, assessment tiers, and which to pursue.
- blog How to Choose a Healthcare Software Development Company Evaluate healthcare software development companies with this expert guide. Covers HIPAA expertise, EHR integration, red flags, RFP questions, and cost.
- blog ISO 27001 vs SOC 2: Healthcare Comparison ISO 27001 vs SOC 2 for healthcare: ISMS certification vs AICPA attestation, the 2022 Annex A controls, cost, global recognition, and whether you need both.
- blog IEC 62304: Medical Device Software Compliance Guide IEC 62304 compliance guide: software safety classification, lifecycle requirements, SaMD classification, and a practical checklist for device teams.
- blog OIE & Mirth Connect CI/CD with MirthSync Automate Mirth Connect and OIE deployments with MirthSync. CI/CD guide with GitHub Actions, version control, and environment promotion.
- blog MirthSync for VS Code: A Modern IDE for Mirth Connect & OIE MirthSync for VS Code: one-command Local Mirth Docker stack, IntelliSense, channel sync, multi-server profiles, and tree-view editing for Mirth and OIE.
- blog Modernizing DICOM in OIE: An Optional dcm4che5 Backend An optional dcm4che5 backend for OIE's DICOM connector: keeping existing channels working while opening the door to modern Java, TLS, and security fixes.
- blog USCDI v7: New Data Elements for Interoperability USCDI v7 draft adds SDOH, communication preferences, and expanded coverage: version history, US Core/FHIR mapping, certification timeline, prep steps.
- blog TEFCA in 2026: Technical Integration Guide TEFCA technical integration guide: 11 designated QHINs, three participation tiers, exchange modalities, and HL7 FAST UDAP security.
- blog Using MirthSync with Git for Version Control Version control for Mirth Connect using MirthSync and Git. Track channel changes, review diffs, and implement rollback for healthcare interfaces.
- blog Get Your App on Epic Showroom (formerly App Orchard) List on Epic Showroom (formerly App Orchard): Vendor Services, open.epic sandbox, SMART on FHIR + OAuth, and the live-connection gate.
- blog OpenShare Is Live: The Healthcare Data Gateway, in Open Beta OpenShare is live in open beta: browser admin for Mirth Connect and OIE, plus direct org-to-org HL7, FHIR, and DICOM exchange. No per-study fees.
- blog Closing Care Gaps in the EHR Workflow What care gaps are, why they stay open, and how CDS Hooks, SMART on FHIR sidebars, and discrete write-back close them during the visit.
- blog Enabling Clinical Research with EHR Data How EHR data powers clinical trial recruitment, feasibility counts, and cohort identification, and when to standardize it into the OMOP Common Data Model.