The Healthcare
Interoperability Glossary

We treat FHIR APIs as the preferred bridge between custom workflow applications and EHR systems: where an EHR exposes FHIR, custom software can read and write data through it instead of relying on manual re-entry.

When an EHR exposes FHIR R4, we design integrations against its normative resources for long-term API stability.

HL7 v2 feeds are still common, so integration designs should plan to ingest, parse, and translate them into clean JSON for modern applications rather than assume FHIR everywhere.

A typical pipeline design parses HL7 v2.x pipe-delimited messages as they arrive and transforms them into structured FHIR resources for modern cloud applications.

SMART on FHIR is the standard authorization path for apps that launch from, or read data out of, enterprise EHRs such as Epic and Cerner. Access still depends on each EHR vendor's developer program and each health system's approval.

In medical billing, RPA fits repetitive portal work that has no API or EDI route, on portals whose terms allow automated access or whose payer has approved it in writing: checking claim and prior authorization statuses and pulling EOBs for reconciliation, with a person reviewing the exceptions.

We sign a BAA with every client before any PHI access; see opexia.io/hipaa-baa. A BAA is a legal agreement, not a technical safeguard, so we also build the technical safeguards (encryption, audit logging, role-based access) and help map which vendors in your stack need a BAA before they touch PHI.

Software we build is built to HIPAA requirements (encryption, audit logging, role-based access). Compliance itself also depends on your organization's policies, training, and risk analysis, which code alone cannot provide.

The CCM/PCM platform in the Opexia case study encrypts patient identifiers (MRN/FIN) at the field level, logs access, and restricts each user to the patients assigned to them. We apply the same patterns, plus TLS for data in transit, to new builds.

We engineer the technical controls SOC 2 auditors test — access control, encryption, logging, change management — for health-tech teams preparing for enterprise vendor reviews. A licensed CPA firm issues the report.

Middleware is how we connect a custom application to Epic, Cerner, or Athenahealth: one internal API for your app, with the vendor-specific FHIR, HL7 v2, or proprietary interfaces handled behind it — limited to what each EHR and health system actually exposes.

When building custom practice management software, we design EMR databases with future interoperability in mind, so you can share records via FHIR later even if you start as a closed system.

EOB handling can be automated: electronic remittance (ERA/835) files from your clearinghouse, and the EOB PDFs your staff download or scan, are parsed and payments matched against the patient ledger in your practice management software, with unmatched items routed to staff.

Status changes are tracked through the payer's API or the X12 278 where available, and by scheduled portal checks only where the payer's terms allow it or the payer has approved it in writing, with staff notified of each change.

The CCM/PCM platform in the Opexia case study tracks care minutes per patient and per coordinator, and generates monthly invoices from CPT paycode counts. That time-tracking and billing core is where any CCM platform we build starts.

The platform in the Opexia case study handles CCM and PCM side by side, counting CPT paycodes (99490/99439 for CCM, 99426/99427 for PCM) from documented time.

A real-time ADT pipeline listens for HL7 v2 messages, normalizes them into FHIR resources, and triggers workflows such as follow-up care scheduling.

The Opexia case study is a care coordination platform: role-based access, per-patient time tracking, automated invoicing, patient reassignment, and an integration with an external RPM system (enrolled-patient export), built to HIPAA requirements (encryption, audit logging, role-based access).

A claim scrubbing engine applies rule-based checks and payer-specific requirements to flag errors before submission, so they are fixed before a payer denies the claim.

Custom RCM dashboards can give real-time visibility into claim statuses, denial trends, and aging accounts receivable, so follow-up happens before revenue is written off.

Rather than forcing your workflows into generic PM software, we build practice management software around your specialty, ownership structure, and operational complexity — when the fit problem is real enough to justify the cost.

Custom clinical charting interfaces can include ICD-10 search and validation, so claims are coded correctly the first time.

In the CCM/PCM platform from the Opexia case study, monthly CPT paycode counts are computed from documented care time, and invoices are generated from those counts instead of being assembled by hand.

A custom PM system can generate superbills from clinical notes and procedure logs, streamlining the handoff from clinical care to billing operations.

We automate a payer portal only where the payer's terms of use allow it or the payer has approved it in writing, and we do not work around CAPTCHA, bot detection or two-factor login. Where it is permitted, portal bots break when payer UIs change, so the design needs resilient selectors and monitoring that alerts someone as soon as a run fails.

We design cloud environments around Zero Trust principles: VPC isolation, least-privilege IAM roles, and mandatory MFA for any PHI access.

We encrypt databases holding PHI with KMS-managed keys and automatic rotation. HIPAA's encryption specification names no key type (45 CFR 164.312(a)(2)(iv)); customer-managed keys are good practice that security questionnaires ask about.

Our default for a healthcare application is a dedicated VPC with private subnets and network ACLs, with private connectivity for integrations where the other side supports it.

We implement least-privilege IAM policies across cloud resources, so developers cannot access production PHI and automated systems use service-specific roles with minimal permissions.

We prefer Terraform-managed infrastructure because version-controlled definitions are reproducible and give auditors a reviewable change history — useful evidence for a SOC 2 examination or a HITRUST assessment.

We configure immutable CloudTrail logs with S3 Object Lock and anomaly alerts to support HIPAA's audit controls standard (45 CFR 164.312(b)) and to detect unauthorized PHI access.

Denial reasons can be tracked automatically, patterns flagged, and corrected claims queued for resubmission with supporting documentation, recovering revenue that would otherwise be written off.

Eligibility checks work best through payer APIs or clearinghouse eligibility transactions, with RPA as a fallback, so front-desk staff know coverage details before the patient arrives.