Short, accurate definitions of the standards, transactions, and regulations that show up in every integration conversation — written by the people who implement them.
An intermediary service that receives, validates, transforms, and forwards healthcare transactions between a client's systems and downstream partners. A zero-retention transaction layer completes each transform in flight and persists no protected health information at rest, keeping only non-identifying metadata for monitoring and audit.
An architectural commitment that no protected health information is written to persistent storage — no staging tables, no message archives, no PHI in logs or error queues. Data is transformed in memory and forwarded, which removes entire categories of encryption-at-rest, retention, and breach-scope obligations.
An HL7 standard that models clinical and administrative data as discrete resources exchanged over RESTful APIs. FHIR R4 is the version referenced by current United States regulation, and conformance is defined by implementation guide profiles such as US Core, CARIN Blue Button, and Da Vinci rather than by base R4 alone.
A pipe-delimited messaging standard that still carries the majority of real-time clinical traffic inside hospitals — admissions and transfers (ADT), orders (ORM), and results (ORU). Widely implemented with local variation, which is why interface work is dominated by site-specific conventions rather than the standard itself.
The HIPAA-mandated electronic claim transaction, issued in professional (837P), institutional (837I), and dental (837D) variants. Carries patient, provider, diagnosis, and service-line detail from submitter to payer, typically via a clearinghouse.
The electronic remittance advice transaction that reports payer adjudication of a claim — amounts paid, adjustments, and the CARC and RARC codes explaining every difference between charged and paid. Reconciles back to the 837 through the patient control number returned in CLP01.
The eligibility and benefit inquiry (270) and its response (271). Used to verify coverage, benefits, and patient financial responsibility before service. Response completeness varies significantly by payer, which is why downstream systems should treat a 271 as evidence rather than as authoritative benefit detail.
The services review request and response transaction used for prior authorization. Under CMS-0057-F, the Da Vinci Prior Authorization Support implementation guide wraps the 278 inside FHIR, so payers need both the API and the underlying X12 mapping.
A standardized code in the CAS segment of an 835 that explains why a paid amount differs from the billed amount. Paired with Remittance Advice Remark Codes (RARC) for additional context. Collectively the highest-value denial-management dataset available to a revenue cycle team.
The CMS Interoperability and Prior Authorization final rule. Requires impacted payers to operate Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization FHIR APIs, shortens prior authorization decision timeframes, and mandates public reporting of prior authorization metrics.
A national framework establishing common terms for health information exchange across networks, operationalized through Qualified Health Information Networks (QHINs). Provides a route to nationwide query-based exchange without negotiating bilateral agreements with every partner.
Under the 21st Century Cures Act, a practice that is likely to interfere with access, exchange, or use of electronic health information, unless it meets a defined exception. Compliance is demonstrated through documented policies, API availability, and request-handling records rather than intent.
A HIPAA-required contract between a covered entity and any vendor that creates, receives, maintains, or transmits protected health information on its behalf. Extends to cloud hosting, observability tooling, and any AI service that receives PHI in a request payload.
Removing or obscuring identifiers so data is no longer protected health information, using either the HIPAA Safe Harbor method (removal of eighteen specified identifier types) or Expert Determination (a qualified statistician certifying low re-identification risk). Distinct from pseudonymization, which remains PHI.
AI systems that plan and execute multi-step workflows against real systems rather than only generating text. In healthcare, viability depends less on model capability than on deterministic guardrails: scoped permissions, verifiable tool calls, human review gates on consequential actions, and an audit trail for every step.
A traceable record of where a data element originated, every transformation applied to it, and every downstream system consuming it. In regulated environments lineage is what converts an analytics number into defensible evidence.
The BCP capabilities that turn this topic into delivered, governed systems.
BCP builds and operates the integration, claims, and AI systems behind these terms — with no PHI retained at rest.