Healthcare IT Interview Questions and Answers

HL7 (Health Level Seven) is a set of standards for sharing health data between systems.

v2 is by far the most used for internal hospital interfaces. CCDA is used to exchange documents. FHIR is the direction for new APIs and rules.

What they are checking: Can you place each standard and say where it is used?

An HL7 v2 message is a text message made of segments, one per line. Inside a segment, fields are separated by |, components by ^, repetitions by ~, the escape character is \ and sub-components are separated by &.

Common segments:

• MSH: message header (sender, receiver, message type, control ID, version)
• EVN: event
• PID: patient identification
• PV1: patient visit
• OBR: observation request
• OBX: observation result
• ORC: common order
• NK1: next of kin
• AL1: allergy
• DG1: diagnosis
• IN1: insurance

MSH|^~\&|ADT|HOSP|EHR|HOSP|20250101120000||ADT^A01|MSG0001|P|2.5
EVN|A01|20250101120000
PID|1||123456^^^HOSP^MR||DOE^JANE||19900101|F
PV1|1|I|WARD1^101^A

MSH-9 tells the receiver what the message is. The receiver replies with an ACK.

What they are checking: Can you read a raw HL7 message?

ADT (Admit, Discharge, Transfer) messages tell other systems about patient registration and movement. The trigger event is the part after the caret in MSH-9.

• A01: admit/visit notice
• A02: transfer a patient
• A03: discharge/end visit
• A04: register a patient (outpatient/ED)
• A08: update patient information
• A11: cancel admit
• A40: merge patient identifiers

ADT feeds keep lab, radiology, pharmacy and billing systems in sync with the patient master record and bed status.

What they are checking: Do you know the most common message type?

A FHIR resource is a small unit of healthcare data with a standard structure. It is identified by a type and an id. Examples: Patient, Practitioner, Organization, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, Procedure, DiagnosticReport, Claim, ExplanationOfBenefit, Coverage, and Bundle (a container for resources).

{"resourceType": "Patient", "id": "123", "name": [{"family": "Doe", "given": ["Jane"]}], "gender": "female", "birthDate": "1990-01-01"}

Resources point to each other. An Observation points to a Patient through subject. This forms the data model.

What they are checking: Do you know the core FHIR words?

FHIR uses standard HTTP verbs on resource URLs, with JSON or XML bodies:

GET    /Patient/123                       read one
GET    /Patient?family=Doe&birthdate=1990-01-01   search
POST   /Patient                           create (returns 201 and Location)
PUT    /Patient/123                       update (replace)
PATCH  /Patient/123                       partial update
DELETE /Patient/123                       delete
GET    /metadata                          CapabilityStatement
GET    /Patient/123/_history              versions

A search returns a Bundle of type searchset with paging links. Use _include and _revinclude to get related resources. Use Observation?patient=123&code=http://loinc.org|718-7 to search by code.

What they are checking: Can you use APIs in practice?

EDI (Electronic Data Interchange) is the structured exchange of business documents between computers. In US healthcare, HIPAA requires the ASC X12 standard (version 5010) for admin transactions between providers, payers and clearinghouses.

X12 files are made of segments that end with ~. Elements are separated by *, and sub-elements by :. The envelope has ISA/IEA (interchange), GS/GE (functional group) and ST/SE (transaction set). Key transactions: 837 claims, 835 remittance, 270/271 eligibility, 276/277 claim status, 278 prior authorisation, 834 enrolment, 820 premium payment.

What they are checking: Do you know EDI basics and the envelope structure?

A 999 confirms that a file was accepted in terms of syntax.

What they are checking: Do you know the core transaction map?

1. Registration and eligibility: collect insurance, check coverage (270/271), and get prior authorisation if needed.
2. Service delivery and notes.
3. Charge capture and coding: assign ICD-10 diagnosis codes and CPT/HCPCS procedure codes.
4. Claim creation and scrubbing: build the 837 and run checks to catch errors.
5. Submission to the payer through a clearinghouse.
6. Adjudication: the payer checks eligibility, medical need, coding and price. Then it pays, denies or holds the claim.
7. Remittance: the 835 and the EOB explain the payment and adjustments.
8. Payment posting and billing the patient for the balance.
9. Denials and appeals, then follow-up.

A BA should know where data can break at each step.

What they are checking: Do you understand the domain from start to end?

A rejection happens before adjudication. The claim failed format or front-end checks, for example missing data, an invalid code or a wrong member ID. It was never processed. You must correct it and send it again.

A denial happens after adjudication. The payer processed the claim and refused to pay. Typical reasons are no coverage, no authorisation, not medically necessary, or filing too late. You handle a denial by correcting the claim and appealing. Use the CARC and RARC codes on the 835 to understand why.

What they are checking: Do you know the difference between a rejection and a denial?

HIPAA (Health Insurance Portability and Accountability Act, US) protects health information and sets standard transactions. Main rules:

• Privacy Rule: who may use or share PHI. Patients can see their data and ask for changes. Share only the minimum necessary.
• Security Rule: admin, physical and technical safeguards for electronic PHI (access control, audit logs, encryption, risk analysis).
• Breach Notification Rule: after a breach, tell the people affected, the regulators, and sometimes the media.
• Transactions and Code Sets Rule: standard X12 formats and code sets.
• Enforcement Rule: penalties.

It applies to covered entities (providers, plans, clearinghouses) and their business associates. Business associates sign a Business Associate Agreement (BAA).

What they are checking: Do you know the compliance rules?

PII (personally identifiable information) is any data that can identify a person, such as name, national ID or email. PHI (protected health information) is health information that identifies a person. It covers past, present or future health, care, or payment for care. It is held or sent by a HIPAA covered entity or business associate, in any form.

• ICD-10-CM: diagnosis codes (what is wrong). They are alphanumeric, up to 7 characters, for example E11.9 for type 2 diabetes without complications. ICD-10-PCS is used for hospital inpatient procedures.
• CPT: procedure and service codes kept by the AMA. They have five characters, for example 99213 for an office visit. Modifiers change them.
• HCPCS Level II: codes for supplies, equipment, drugs and services outside CPT, for example J-codes for injectable drugs.

A Bundle is a resource that holds a collection of other resources. Its type sets its purpose: searchset (search results), document (a clinical document), message, collection, batch and transaction.

HEDIS (Healthcare Effectiveness Data and Information Set) is a set of quality measures kept by NCQA. Health plans report them. They cover areas such as breast cancer screening, diabetes care (HbA1c control), childhood immunisations and taking medicines as prescribed. The data comes from claims, EHRs and registries. The results feed plan ratings and Medicare Star ratings. To find gaps in care, check whether an eligible member had a qualifying service in the measurement year.

An interface engine is middleware. It receives messages from one system, checks and changes them, and sends them to other systems. So each system needs only one connection. Typical features: connectors (MLLP, HTTP, SFTP, database), filters, mapping and transformation, queuing and retry, logging and monitoring.

The National Provider Identifier is a unique 10-digit number. CMS gives it to US healthcare providers and organisations. HIPAA requires it on standard transactions such as claims. Type 1 NPIs are for individuals. Type 2 NPIs are for organisations.

Prior authorisation is the payer's approval. It is required before some services or drugs. It confirms medical need and coverage. The provider sends a request (X12 278, a portal, or more and more a FHIR-based API) with clinical details. The payer approves, denies or asks for more information. It returns an authorisation number that must go on the claim. Missing or expired authorisations are a common cause of denials. So track them when the visit is scheduled.

An EMR is the digital chart inside one practice. An EHR is built to share patient information across organisations and care settings. A provider gives care (doctor, hospital, lab). A payer pays for it (insurer, government programme). Providers send claims to payers and receive payment. Payers also run eligibility checks, utilisation management and quality programmes.

ORU^R01 is an unsolicited observation result message. It is used mostly for lab and radiology results. It carries the patient (PID), usually the visit (PV1), the order (ORC and OBR), and one or more OBX segments with the results.

FHIR itself does not define security. So servers use OAuth 2.0 and OpenID Connect over TLS. SMART on FHIR is the standard profile for this. It defines how an app is launched (EHR launch or standalone). It defines how the app finds endpoints (.well-known/smart-configuration). It uses the authorization code flow with PKCE. It also defines scopes such as patient/Observation.read or user/*.read.

C-CDA (Consolidated Clinical Document Architecture) is an XML document standard, based on HL7 CDA. It summarises a patient's clinical information. A document has a header (patient, author, custodian) and a body made of sections. Sections include problems, medications, allergies, immunisations, vital signs and results. Each has a readable narrative and coded entries.

837P is the professional claim. Doctors and other practitioners use it. It maps to the CMS-1500 form. 837I is the institutional claim. Hospitals, nursing facilities and other facilities use it. It maps to the UB-04 form. 837D is for dental.

An 837 is organised in loops that sit inside each other:

• 2000A: billing provider (NM1*85, plus NPI and tax ID)
• 2000B: subscriber/insured (SBR segment, member ID, payer in 2010BB)
• 2000C: patient, only when different from the subscriber
• 2300: claim information (CLM with claim ID, total charge and place of service; HI with diagnosis codes; DTP dates)
• 2400: service lines (SV1 for professional, SV2 for institutional, with procedure code, charge and units)

HCC (Hierarchical Condition Category) risk adjustment is used by CMS for Medicare Advantage. It predicts the expected cost of a member from age, sex and diagnoses. Diagnosis codes on claims and encounters map to HCCs. Each HCC has a weight. The weights add up to a risk adjustment factor (RAF) score. This score raises or lowers the payment to the plan. Hierarchies keep only the most severe condition in a related group.

HL7 v2 is event driven and push based. A system sends a message when something happens. Formats differ between sites, and mapping is often custom. FHIR is based on resources and APIs. Clients query or subscribe to well-defined resources over REST. It has built-in versioning, search and standard profiles (such as US Core).

A clearinghouse sits between providers and payers. It receives claims, checks them against payer rules, and changes the format if needed. It sends them to the right payer. It returns acknowledgements (999, 277CA) and remittances. It reduces rejections. A provider needs only one connection, not one for each payer.

CARC (Claim Adjustment Reason Codes) explain why the paid amount differs from the billed amount. They appear in CAS segments on the 835, together with a group code: CO (contractual obligation), PR (patient responsibility), OA (other adjustment), PI (payer initiated). RARC (Remittance Advice Remark Codes) give more information or next steps. Together they drive denial management and automatic posting rules.

They are clinical terminologies. They give coded data that different systems can share.

• LOINC: identifies lab tests and clinical observations (for example 718-7 hemoglobin).
• SNOMED CT: a full set of clinical terms for conditions, findings and procedures.
• RxNorm: standard names and identifiers for medicines.

MLLP (Minimal Lower Layer Protocol) is the simple wrapper used to send HL7 v2 over TCP. A message is wrapped with a start block character (0x0B) and an end block (0x1C followed by carriage return 0x0D). The receiver reads the message and returns an ACK in the same wrapper. It is not encrypted. So it is normally used inside a private network, or over a VPN or TLS tunnel.

An ACK is the receiver's reply to an HL7 v2 message. MSA-1 holds the code. MSA-2 holds the control ID of the original message.

• AA: application accept. It was processed successfully.
• AE: application error. There was a problem processing it. The sender may fix it and send it again.
• AR: application reject, for example an unsupported message type or version. Sending it again as is will not help.

An MPI links records from different systems to one person. Matching is hard because of typos, nicknames, changed names or addresses, missing data, and shared identifiers like a family phone number. Approaches: deterministic matching on exact keys, probabilistic matching that scores how similar fields are, and manual review of unclear pairs. A wrong merge (two people joined into one) is a patient safety risk. So the thresholds are set carefully.

The Cures Act (US) promotes interoperability and bans information blocking. Patients and their approved apps must be able to access their electronic health information. USCDI (United States Core Data for Interoperability) is the standard set of data classes and elements, such as allergies, medications, problems, lab results and notes. Certified systems must be able to exchange them. US Core FHIR profiles implement it. For a BA or integrator, this defines what patient access APIs must provide.

I work from the message to the cause:

1. Get the failing raw message and the ACK or error code from the engine logs.
2. Check the header: version, message type and event, sending application, and delimiters.
3. Check the required fields against the interface specification. Look at the PID-3 identifier, the name, the...

Use layers of controls:

• Encrypt data in transit (TLS) and at rest.
• Use role-based access, least privilege, MFA, and audit logs of who accessed what.
• Minimum necessary: pass only the fields that are needed.
• Do not use real PHI in lower environments. Use de-identified or synthetic data, masking or tokenisation...

I start with the 835 or the payer response. The group and reason codes (CARC/RARC) usually name the field. Then I trace the claim data back through the 837 to the source (registration, charge capture). I check the member ID format, subscriber and patient details, billing and rendering NPI, taxonomy, diagnosis pointer,...

Likely causes: the sender retried because the ACK was missing or slow. The engine reprocessed a queue. Result corrections arrived as new results. Or two sources feed the same system. I check the message control IDs (MSH-10), the placer/filler order numbers and the OBR/OBX result status (F final, C corrected).

I would not just pick one. First I confirm that the records are really the same person. I use the MPI match evidence (identifiers, name, date of birth). Then I define survivorship rules (which value wins) with the data owners. For each field, decide which system is the source of truth, or let the most recent verified...

First I clarify the requirements. How many checks, and how fast? Which payers? Does the payer have a real-time API, or is there a clearinghouse? What does the screen need from the 271 (active status, copay, deductible, plan type)?

Bring in the 837/835 and 834 files (by SFTP or from the clearinghouse) into a landing zone, and keep the raw file. Parse them into staging tables and validate them (envelope counts, required fields). Standardise codes and map member IDs through the member master. Remove duplicate claim versions (original, replacement,...

Business: which workflow (eligibility, claims, prior auth, status), what outcome, volumes and service levels. Technical: which standard and version (X12 5010, FHIR R4), transport and authentication, test environments, who sends first. Data: required fields, code sets and mapping, and how corrections and cancellations...