Skip to main content
U.S. flag

An official website of the United States government

Dot gov

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

Https

The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Questions Submitted by the Public, by Date Posted to the Website

Publication Date
Nov 1, 2001

Effect of standards on transmission requirements (e.g., addresses)

Does the Transactions Rule affect health plan transmission requirements? May a health plan continue to require health care providers to send dental claim transactions to one location (electronic mail box, etc.) and preauthorization transactions to another?


11/2/2001:

The Transactions Rule does not affect transmission requirements, such as specified billing addresses, of health plans. These are business decisions between health plans and health care providers. HIPAA does require health plans to accept the electronic transactions which were adopted through the transaction rule.

COB with auto insurance companies

Is a health plan required to use the standard transaction when performing coordination of benefits (COB) with an automobile insurance company?


11/2/2001:

Property and casualty insurance programs are not included within the definition of health plan, so they are not required to use the standard transactions. However, they may do so if they wish, and if they use the standard COB transaction in performing coordination of benefits with a health plan with which they have tradng partner agreements to conduct COB, the health plan is required to accept the standard transaction.

Transmission of administrative data outside of a claim

Our business provides administrative services to large group physician practices. As part of this service, we collect demographic and clinical information from hospitals and other venues where the group physicians perform services. We send this information electronically to the physicians' billing offices to use in preparing bills to send to various health plans. Do these transmissions have to be in HIPAA standard format?


11/2/2001:

The activity you describe does not meet the definition of a health claim transaction or any other transaction for which standards have been adopted under 45 CFR Part 162, subparts K through R. These transmissions therefore do not have to be conducted as standard transactions. The bills sent by the physicians' billing offices to the health plans must be in standard format.

Assigning responsibility for non-compliant transactions

If a health care provider electronically conducts a non-compliant transaction (transmits an old National Standard Format or a proprietary format) directly to a health plan after the transaction regulation compliance date, and the health plan accepts and processes the non-compliant transaction, who is in violation of the regulation? Is it the health care provider or the health plan?

Does the acceptance and processing of a non-compliant transaction by a health plan from a health care provider constitute a violative trading partner agreement between the health plan and the health care provider?


11/2/2001:

If a health care provider electronically conducts a non-standard transaction with a health plan after the transaction regulation compliance date, the health care provider and the health plan are both out of compliance. Section 162.923(a) of the rule requires a covered entity conducting an electronic transaction for which a standard has been adopted with another covered entity to conduct it as a standard transaction.

If the health plan by agreement required the health care provider to conduct non-standard electronic transactions, such agreement would not by its terms violate section 162.915. However, if either party were to abide by the agreement, they would be out of compliance with section 162.923(a), for the reason stated above.

COB requirements

As a health plan we currently only conduct coordination of benefits (COB) with Medicare. Does the transaction and code set regulation require health plans to conduct COB with all health plans and health care providers even though they may not currently conduct COB with those entities?


11/2/2001:

No. It is the health plan's decision as to whether they coordinate benefits electronically with another health plan or a health care provider. If a health plan decides to coordinate benefits electronically with another health plan or a health care provider, they must use the standard transaction for COB.

Transaction standard for pre-adjudication claim edits

Should pre-adjudication claim edits be reported back to health care providers via an ANSI X12N 277 rather than the X12N 835 remittance transaction?

For example, a provider sends claims electronically using the X12N 837 claim standard to a health plan, the health plan compares the contents of the X12N 837 to a series of high-level mainframe edits before the claim enters into adjudication. At this point, claims are either accepted into the health plan's adjudication system or rejected back to the provider, so that the claims can be fixed and re-submitted.


9/17/2001:

The Secretary did not adopt a standard for reporting claim edit errors back to a health care provider. It is the health plan's decision as to whether it uses the unsolicited X12N 277 to send error messages back to the health care provider.

Same/different rules for health plans vs. health care providers or group plan sponsors

I understand that, under the statute, if a health plan performs a business function covered by a standard transaction, it must be able to support the electronic standard for the transaction, regardless of whether, prior to the compliance date, it conducts the transaction electronically or not. Is the same true for a health care provider or the sponsor of a group health plan?


9/17/2001:

No, the rules do not apply in the same way to health care providers and plan sponsors.

It is correct that health plans must be able to support the standard transactions for which a standard has been adopted and which they conduct. This is based on section 1175(a)(1) of the Act, which provides that if a person desires to conduct a transaction with a health plan as a standard transaction, the health plan may not refuse to conduct the transaction as a standard transaction. Thus, if a health plan supports the transaction in any form, it must be prepared to accept it as a standard transaction.

The requirement of section 1175(a)(1) does not apply to health care providers. Thus, unlike health plans, health care providers are not required by the statute to have the capability to conduct electronically the transactions for which standards have been adopted and may instead conduct them by paper. However, once the applicable compliance date has occurred, if a provider elects to conduct electronically a transaction for which a standard has been adopted, it must conduct it as a standard transaction.

Sponsors of group health plans are not covered entities (entities described at section 1172(a) of the Social Security Act). They are legally distinct from the group health plans they sponsor, and it is only the latter entities that meet the statutory definition of "health plan." Since the requirement of section 1175(a)(1) applies only to health plans, it does not apply to the plan sponsors.

Accepting standard transactions and additional formats

Is it permissible for health plans to continue to accept additional formats as well as the standard transactions adopted under HIPAA past the effective date of the final regulation?


9/17/2001:

Section 162.923(a) of the regulation requires a covered entity that electronically conducts a transaction adopted under part 162 of the regulation, with another covered entity, to conduct the transaction as a standard transaction. Health plans may continue to accept additional electronic formats after the transaction and code set final rule compliance date only if the submitter is NOT a covered entity under HIPAA.

Restricting data to that necessary for adjudication

Section 1.3 of the X12N 837 Professional Implementation Guide (IG) mentions that payers may create subsets to the guide within trading partner agreements and that payers are not required to bring data they cannot / prefer not to accept, into their adjudication system. Trading partners could then send transactions without that data and know the payer has agreed to accept and process the transaction without that data. The example given in the IG relates to home health data, the usage of which is situational.

Is it also correct to interpret this to mean that covered entities may therefore agree to transmit only data they deem necessary regardless of whether or not the data element is required or situational within the IG?

As an example, if a payer determines that they do not require the service facility address and that they will not be taking that data into their adjudication system, may they add a subset IG to their trading partner agreements indicating this data is not required? Or since section 1.1.1 of the same IG states that trading partner agreements may not modify the definition, condition, or use of a data element or segment in the standard IG, would the payer be required to maintain that required usage in the subset?


9/17/2001:

Health plans are required to be able to accept all of the data content included in the implementation guide (IG). They must be able to accept the data, but they do not have to process the data. Trading partner agreements may not change the definition, data condition, or use of a data element or segment in an implementation guide. If the element is defined as required, it must always be included in the standard transaction.

The subset to the IG referred to in section 1.3 of the professional 837 IG refers to data clarifications that may supplement the IG. Clarifications could include identifiers to use when a national standard has not been adopted, parameters in the IG that provide options, such as the number of claims to submit in a X12N 837 health care claim transaction or identifying elements that you will accept but will not process. Section 162.915 of the final rule sets the boundaries for trading partner agreements.

Electronic standard for HCFA-1500

What is the standard electronic transaction for the paper HCFA-1500 (Health Insurance Claim Form)?


9/17/2001:

As stated in section 162.1102 of the Final Rule on Standards for Electronic Transactions, the ASC X12N 837--Health Care Claim: Professional, Volumes 1 and 2, Version 4010, is the adopted standard for professional health care claims or equivalent encounter information.

Required level of service for batch/real time transactions

What level of service is required to be provided under HIPAA when an entity implements batch and/or real time submission of a standard transaction?


8/27/2000:

45 CFR 162.925 states "a health plan may not delay or reject a transaction, or attempt to adversely affect the other entity or the transaction, because the transaction is a standard transaction." If the standard transaction (e.g., ASC X12N 270/271) is offered in a batch (non-interactive) mode, the health plan has to offer the same or higher level of service as it did for a batch mode of transaction before the standards were implemented by the plan. If a health plan offers the transaction in a real time (interactive) mode, the level of service has to be at least equal to the previously offered level for a real time mode of transaction. If a transaction is offered through Direct Data Entry (DDE), the level of service, again, has to be at least equal to the level offered for the DDE transaction before implementation of the HIPAA standard.

Parties to transaction use same clearinghouse

If a clearinghouse performs a transaction on behalf of two parties to the same transaction, how must it communicate with each party, and at what point must the transaction be in the standard?

For example, a provider contracts with a clearinghouse to send transactions to a health plan on its behalf. Health Plan A contacts with that same clearinghouse to receive transmissions from provider on the health plan's behalf. The clearinghouse receives a claim from the provider in non-standard format for submission to Health Plan A. The clearinghouse's agreement with Health Plan A requires the clearinghouse to send claims to Health Plan A in another non-standard format. Must the clearinghouse translate the provider's non-standard transmission to standard format before converting it to the non-standard format required by Health Plan A?


8/27/2000:

Section 162.923(a) requires a covered entity to conduct electronic transactions with other covered entities as standard transactions, and section 162.923(c) allows a covered entity to use a business associate to conduct these transactions. Section 162.923(c)(1) requires that where a covered entity uses a business associate to conduct all or part of a transaction on its behalf, the covered entity must, as relevant here, require the business associate to comply with the applicable requirements of the transactions rule. Also, under section 162.930, a health care clearinghouse may, when acting as a business associate for another covered entity, translate a standard transaction into a non-standard transaction or vice versa. Since a clearinghouse is also a covered entity, this latter provision operates as an exception to the requirement of section 162.923(a) that covered entities conduct transactions for which standards have been adopted as standard transactions.

The provider in the above scenario is using the clearinghouse as a business associate for the purpose of sending an electronic claim. The communication between the provider and the clearinghouse need not be a standard transaction. However, the covered provider must, under section 162.923(c)(1) require the clearinghouse to send the transaction as a standard transaction. Also, the clearinghouse must produce the transaction as a standard transaction for forwarding to Health Plan A, or it does not come within the exception provided for by section 162.930(b) and is consequently in violation of section 162.923(a).

In the above scenario, Health Plan A is also using the same clearinghouse as a business associate for the purpose of receiving a standard electronic claim. Health Plan A may contract with the clearinghouse to translate, on Health Plan A's behalf, a standard transaction to Health Plan A's non-standard format and, under section 162.930(a), the clearinghouse may do this on the health plan's behalf. The communication from the clearinghouse to Health Plan A need not be done as a standard transaction, because the communication comes within the exception provided for by section 162.930(a). Thus, the clearinghouse may translate the standard transaction into a non-standard transaction and forward it to Health Plan A.

The inescapable result of this logic is that a clearinghouse must use a standard transaction as an intermediate stage (even if only for a microsecond) when it serves both a health care provider and a health plan conducting a transaction using non-standard formats.

Retaining maximum field lengths in transactions

Are covered entities expected to retain in all circumstances the entire content received in a standard transaction? A majority of data elements on the HIPAA transactions have lengths in excess of the field lengths on our local record formats. Are covered entities responsible for preventing truncation of the content received in a standard transaction in all circumstances or does it depend whether the data processed is needed for sending to another entity?


8/27/2001:

Health plans and health care clearinghouses are required to be able to accept the "maximum" data set; this includes maximum fields lengths as well as all of the required and situational data elements possible in a standard transaction. Extraneous data does not have to be processed; however, if a health plan electronically performs coordination of benefits, with another health plan, the health plan must store the coordination of benefits data that is necessary to forward to the other health plan.

Maximum field lengths in legacy systems

Under HIPAA, are covered entities expected to expand their legacy systems to accommodate and store the maximum field lengths that could be sent in a transaction?

A majority of data elements on the HIPAA transactions have lengths in excess of the field lengths on our local record formats. An example would be a telephone number: the implementation guides and X12 standards allow for up to 80 alphanumeric bytes for a telephone number. In North America, a telephone number can be stored in 10 numeric bytes. Many legacy systems allow for a middle initial in an individual's name, but the NM1 segment allows for the transmission of an entire middle name. Some organizations may not have a business need for the middle name and can get by on just the middle initial.


8/27/2000:

No. Covered entities are not required by the rules to modify their legacy systems to accommodate and store the maximum field lengths. A health plan must be able to receive the maximum size at their front end and retain certain data required for exchanging coordination of benefits. A health plan may build the outbound X12N 837 for coordination of benefits using the data the health plan used to adjudicate the claim (data on claim history and other reference files). Data that a health plan receives, but doesn't use to process the claim, must be stored to be used later in building the outbound X12N 837 if they exchange coordination of benefits.

Networks, business associates as clearinghouses

Does the definition of "Business Associate" in 45 CFR section 160.103 apply to a network that links providers and payers (health plans) together in order to help facilitate certain health care transactions, but does not convert or otherwise touch the data that pass between payers (health plans) and providers?

Is this network a clearinghouse if it does not perform the functions of format translation and data conversion?


7/1/2001:

The definition of Business Associate at 45 CFR 160.103 applies generally to a person or organization that performs, on behalf of a covered entity, a function or activity involving the use or disclosure of protected health information or any other function, activity, or service covered by the Administrative Simplification regulations. If the network in the question accesses or uses protected health information on behalf of a covered entity, whether for translation or payment or quality assurance or other purposes, it is considered a business associate.

The preamble to the final rule for Standards for Privacy of Individually Identifiable Information published in the Federal Register on December 28, 2000 states (65 FR 82476) that we do not require a covered entity to enter into a business associate contract with a person or organization that acts merely as a conduit for protected health information. If the network in the question merely transports information but does not access it other than on a random or infrequent basis as may be necessary for the performance of the transportation service or as required by law, it is acting only as a conduit for the health care transactions and is not considered a business associate of the health plans and providers.

If the network does not process or facilitate the processing of nonstandard format/data content received from another entity into standard format/data content, or standard format/data content into nonstandard format/data content for the receiving entity, the network is not considered a health care clearinghouse as defined in 45 CFR 160.103 of this regulation.

Data content for direct data entry (DDE) systems

What are the data content requirements that apply to direct data entry (DDE) systems?


7/1/2001:

Section 162.923(b) of the regulation requires that the data content and data condition requirements of the standard must be met by DDE systems. This means that these systems must:

  1. Collect all data elements that are required in the implementation guide, as well as those data elements that are situational and the situation is met (unless the data are already available on the health plan's system);
  2. Use only the internal and external code sets designated in the implementation guide with no additions or substitutions;
  3. Provide for at least the field size minimums noted in the implementation guides, but no more than the maximum sizes; and
  4. Permit at least the minimum number of field repeats noted in the implementation guide, but not more than the maximum number.

Web-based transactions, DDE vs. regular transactions

When are web-based transactions considered to be part of Direct Data Entry systems which are subject only to the data content portions of the standards, and when are they considered regular transactions which must meet both data content and format requirements of the standards?


7/1/2001:

If the sender is using his or her browser to directly enter information onto a server that is part of the receiver's system, then it is considered a direct data entry transaction which need only meet the data content and data condition requirements. If, however, the data are being entered onto a server which is then repackaging the information to be sent to the receiver's system, that is considered a transaction which must be sent to the receiver meeting the data format requirements as well.

When entities must conduct the standard transaction

Where in the implementation guides is the definition that the eligibility for a health plan transaction is an inquiry from a health care provider to a health plan or from one health plan to another health plan. in the implementation guides? Can you clarify the criteria that determine when entities must conduct the transaction as a standard?

In the preamble of the Final Rule, item 6 "Exceptions for Transactions Within Corporate Entities," example 2 involves a large multi-state employer, seven insurance companies (TPAs) and one data service company. The example appears to be used to illustrate the criterion that determines when entities must comply with the electronic formats under HIPAA law. In this specific example, the conclusion is made that the eligibility inquiries from the TPAs to the data service center do not have to meet the requirements because, "...the inquiry is from one business associate of a health plan to another business associate of the same health plan. Therefore, the inquiry does not meet the definition of an eligibility for a health plan transaction, and is not required to be conducted as a standard transaction."

The conclusion that this example makes is that the definition of the transaction is not met by virtue of who was inquiring and who was responding (i.e., the inquiry was between two business associates of the same health plan). This would seem to establish a number of criteria for entities to use in determining whether entities are to conduct transactions using the standard.

The example states that the definition of the eligibility for a health plan transaction is an inquiry from a health care provider to a health plan or from one health plan to another health plan. Where is this definition in the implementation guides? Can you clarify the criteria that determine when entities must conduct the transaction as a standard?


7/1/2001:

The final rule did not create an exception for transactions within a "corporate entity." Instead, two criteria are to be used to determine whether a transaction must be conducted as a standard transaction.

First, is the entity conducting the transaction a covered entity?

Second, does the transaction meet the definition of one of the transactions defined in subparts K through R of part 162?

The transactions are described in the regulation itself rather than within the implementation guides. Since the TPAs are business associates of the health plan, the health plan must require them to follow the transactions rules that apply to it. However, since the transmission of the eligibility request is from the TPA to the data service center (business associate to business associate of the same health plan), it does not meet the definition of eligibility for a health plan transaction in 162.1201

Providing additional information to standard transactions

If a covered entity adheres to the data content requirement, can they also provide additional information using other technologies?

For example, if a health plan has a Web query solution for claim status, and meets all data content requirements for the 276 request and the 277 response, could they also provide additional information regarding the status of the claim? An example of additional information would be to provide claim resolution instructions for denied claim, or a statement that would better clarify the action taken on the claim.


7/1/2001:

A health plan may not add additional information to any of the standard transactions. It may, however, provide additional information through a separate mechanism. For example, the web-based service described in the question could provide additional information on a web page separate from the web page containing the standard data content. The resolution of the standard transaction cannot depend on the additional information.

Health care providers and health plans that have a business need for additional information are encouraged to work with the Designated Standard Maintenance Organizations to submit a request to modify the standard(s). Section 162.910 established criteria for the processes to be used for such modifications.

When a PPO is/is not a covered entity

When is a PPO not a covered entity?

A question was submitted regarding a Preferred Provider Organization (PPO), which was described as an organization that contracts with health care providers to arrange networks and does not accept insurance risk. The PPO contracts with employee benefit plans (a type of health plan) to provide access to its networks. The PPO has negotiated a discount from the providers for the employee benefit plans. The PPO is not run by an insurer or an HMO.

Is the PPO a health plan and therefore a covered entity under the HIPAA Administrative Simplification rules?

The particular concern involves a PPO that has informed its contracted employee benefit plans that any clearinghouse fees incurred will be passed back through to the employee benefit plan. If the PPO is a covered entity, is it prohibited from passing on these clearinghouse fees to the employee benefit plan? See 45 CFR 162.925(a)(5).


7/1/2001:

A PPO as described in the first paragraph of the question does not meet the definition of a health plan, because it is neither providing nor paying the cost of medical care. Rather, it is facilitating an arrangement regarding fees between the payers - the employee benefit plans - and the health care providers in the network it set up.

45 CFR 162.925(a)(5) applies to any health plan that operates as a health care clearinghouse or requires another entity to use a health care clearinghouse. This section would not apply to the PPO in the situation described in the second paragraph of the question because the PPO is not a health plan, and does not, as a business associate acting on behalf of a health plan, operate as a health care clearinghouse or require that other entities use a health care clearinghouse. Therefore, the PPO is free to pass clearinghouse fees back to the employee benefit plan.

Minimum Data Set (MDS) reports by long-term care facilities

Are long-term care facilities required to submit their Minimum Data Set (MDS) reports using a HIPAA standard? The reports are not used for request of payment.


7/1/2001:

No. The Minimum Data Set (MDS) is an array of data that nursing facilities are required to collect and report on each of their residents as a condition for Medicare and Medicaid certification and payment under the Nursing Home Reform Act of 1987. See 42 C.F.R. Part 483, Subpart F for MDS requirements.

The MDS includes a comprehensive assessment of many factors concerning a patient's care during a stay in a facility, and therefore contains a substantial amount of data beyond that needed for the 837 claim. The Medicare program and a number of State Medicaid programs use data elements extracted from the MDS to compute payment rates. In some States, nursing facilities use MDS data to construct individual claims for payment. These are permitted uses for this data. By the compliance date for the HIPAA transactions, any individual claims for payment constructed from this data must be in the standard 837 format. However, reporting of patient assessment data using MDS is not one of the standard transactions adopted in the Transactions Rule.

When a third-party administrator (TPA) is/is not a covered entity

Many self-insured group health plans use third party administrators (TPA's). These TPA's are not covered entities. Are all electronic transactions between a self-insured group and its TPA outside the scope of the transaction requirements?


7/1/2001:

If the self-insured group health plan uses a TPA to conduct all or part of a transaction on behalf of the health plan, the TPA is acting as the business associate of the health plan. In order to determine whether a transaction between the health plan and its TPA must be a standard transaction, it is necessary to look at the description of the transaction in 45 CFR 162, Subparts K through R. The health plan, as a covered entity, must use the standard when transmitting a transaction as described in Subparts K through R with another covered entity or within itself. The health plan must also require its TPA, as its business associate, to follow the rules and transaction standards applicable to the health plan as though the health plan were performing the functions itself. This means that in cases where the health plan would be required to use a standard transaction within itself, the transaction would have to be standard when conducted between the health plan and its TPA.

Non-federal-government, not-for-profit, self-funded health plans

Would non-federal-government, not-for-profit, self-funded health plans be exempt, in whole or in part, from the HIPAA Administrative Simplification regulations?


7/1/2001:

The characteristics identified in the question - status as a non-federal government entity, non-profit status, and self-funded status - are not relevant to determining whether an entity is a health plan or not. The question is whether the entity in question meets the definition of health plan at 45 CFR 160.103, either because it is included in one of the specific listings or because it meets the general definition, and is not otherwise excluded from the definition.

Plans that meet the definition of health plan at 45 CFR 160.103 are covered entities under the HIPAA Administrative Simplification provisions and must comply with the applicable requirements of the regulations. The definition of health plan includes group health plan (see below for definition) and also includes any other individual or group plan (other than those specifically listed in the definition of health plan), or combination of individual and group plans, that provides or pays for the cost of medical care. The definition of health plan lists two exclusions. The first of these might apply to the plan in the question. The definition excludes "any policy, plan, or program to the extent that it provides, or pays for the cost of, excepted benefits that are listed in section 2791(c) (1) of the PHS Act, 42 U.S.C. 300gg-91 (a) (2)".

Group health plan is defined at 45 CFR 160.103 as an employee welfare benefit plan, including insured and self-insured plans, to the extent that the plan provides medical care, including items and services paid for as medical care, to employees or their dependents directly or through insurance reimbursement or otherwise, that

  1. Has 50 or more participants; or
  2. Is administered by an entity other than the employer that established and maintains the plan.

The only employee welfare benefit plans that are excluded from the definition of health plan are those that have fewer than 50 participants and are administered by the employer that established and maintains the plan.

If the plan in the question does not fall under one of the exclusions mentioned above, it would be a covered entity and would be required to comply with the HIPAA Administrative Simplification regulations.

Health plans offering both batch and real-time transactions

Must health plans offer both batch and real-time transactions if the implementation guide supports both?


7/1/2001:

No, it is a business decision that is left up to the health plan to decide whether to offer batch, real time, or both types of transactions.

Applicability to State-licensed dental HMOs

Do the definitions of covered entities include State licensed dental HMOs?


7/1/2001:

Health maintenance organizations (HMOs) recognized under State law are considered health plans and are therefore covered entities and subject to the requirements of the regulation.

Internet inquiry and response systems

Does the use of only an Internet-based (computer-to-person) inquiry and response solution (e.g., claims status and eligibility inquiries come to a client via the Internet) constitute compliance with the HIPAA standards, or does a health plan need to also use an EDI-based (computer-to-computer) inquiry/response technology solution at a minimum? What number/types of technologies must be used for a health plan to be compliant with HIPAA mandates?


7/1/2001:

The health plan must, at a minimum, provide an EDI-based solution that meets the requirements of the standards adopted by the regulation. For the current standards, this means an EDI based solution that meets the requirements of the implementation guides. Any number of additional technologies for data submission (direct data entry, Internet-based or not) may be adopted at the discretion of the plan, but there is no requirement that a plan offer any additional options beyond the minimum required EDI solution.

Data content and format for direct data entry

Does 'standard transaction' mean that the screens used for direct data entry, using a browser in an extranet application, have to conform to both data content and format?

There appears to be a conflict between the regulation text and the preamble regarding the exceptions for the Internet electronic media. The final regulation text states that, "If a covered entity conducts with another covered entity, using electronic media, a transaction for which the Secretary has adopted a standard under this part, the covered entity must conduct the transaction as a standard transaction. Electronic media means the mode of electronic transmission. It includes the Internet, Extranet, leased lines, dialup lines, etc." Does 'standard transaction' mean that the screens used for direct data entry, using a browser in an extranet application, have to conform to both data content and format?


7/1/2001:

We do not see the conflict suggested. The provisions for direct data entry are explicitly listed as an "exception" to the general rule at section 162.923(b). This means that, for transactions coming within the exception, the alternate requirements of the exception constitute the standard (unless, of course, the health care provider elects to follow the general rule).

Direct data entry (DDE) systems are not subject to the transaction format requirements, but must use 'applicable data content' and data condition requirements. In this context, 'applicable data content' means that the DDE systems must collect all fields that are required in the HIPAA implementation guide for a particular standard, as well as those situational elements that are needed for processing (unless that data is already available to the health plan's system). All internal and external code sets designated in the implementation guide(s) are to be used. DDE systems must provide for at least the field size minimums noted in the implementation guide(s), but no more than the maximum size allowed. DDE systems must also permit at least the minimum number of segment/field repeats noted in the implementation guide(s), but no more than the maximum number allowed. In addition, DDE systems may not collect additional data that are not included in the implementation guide for a particular standard transaction.

No HIPAA definition for "attending physician"

Did the Administrative Simplification provisions of HIPAA establish a definition of "attending physician"?


7/1/2001:

No. Neither the Administrative Simplification provisions of HIPAA nor the implementing regulations establish a definition of "attending physician."

Small health care providers

Do small health care providers have to comply with the transaction standards adopted under HIPAA?


7/1/2001:

All covered entities (health plans, health care clearinghouses, and certain health care providers), regardless of their size, must comply with the transaction standards adopted under HIPAA.

A covered health care provider as defined in section 160.103 is one who transmits any health information in electronic form in connection with a transaction covered by 45 CFR Subtitle A, Subchapter C. Some small health care providers do not conduct any business transactions electronically and do not use a service to do so on their behalf. Such health care providers are not subject to the requirements of the transaction standards. HIPAA distinguishes only health plans on the basis of size, giving small health plans an extra year to comply.

Maximum allowable transmission size of an X12N transaction

Has the Secretary of Health and Human Services set limitations on the maximum allowable transmission size of an X12N transaction?


7/1/2001:

The Secretary has not set standards for transmission size. Receiving trading partners may have system limitations as to the size of the transmission they can receive. The maximum transmission size is to be negotiated by submitters and receivers of the standards through trading partner agreements.

Measuring annual receipts to define a "small" health plan

The criterion for a small health plan has been defined to mean $5 million or less in annual receipts. Is this restricted to receipts, is it only pure premiums, or does it include all revenue, including investment income?


7/1/2001:

The term "receipts" in the definition of "small health plan" does not include net capital gains or losses, but may include more than just pure premiums. The Secretary adopted the size classification used by the Small Business Administration (SBA) for "small health plans," that is, $5 million or less in annual receipts (13 CFR 121.102). In order to be consistent with the SBA requirements, the meaning of the term "receipts" in the Rule is based on SBA definitions as well. The SBA defines receipts as "'total income' . . . plus the 'cost of goods sold' as these terms are defined or reported on Internal Revenue Service (IRS) Federal tax return forms . . ." but specifically excludes net capital gains or losses, among other things. (13 CFR 121.104.)

The preamble to the privacy rule stated that we consider "pure premiums" to be equivalent to "annual receipts." While these terms will be equivalent for many entities, that may not always be the case. A covered entity should base a determination of whether or not it is a "small health plan" on the relevant SBA regulatory definitions

Standard code sets for service prior to 10/16/2002

Can non-standard medical codes (codes such as J codes for drugs and home grown or local codes) be sent on electronic transactions submitted after the compliance date of 10/16/02 for dates of service prior to 10/16/02?


6/4/2001:

For dates of service prior to 10/16/2002, the compliance date for the adopted standard medical data code sets would not have been reached. Therefore non-standard codes may be used for dates of service prior to 10/16/2002 on transactions submitted after 10/16/2002. Section 162.1000(a) requires covered entities to use the applicable medical data code sets "valid at the time the health care is furnished" for transactions they conduct after 10/16/2002. To determine which code set was valid at the time of service, the covered entity has to determine the validity dates "specified by the organization responsible for maintaining that code set" and determine whether the date of service falls within those dates.

Compliance date in New Jersey

I have heard that if we receive electronic claims from the State of New Jersey, that we have to be HIPAA compliant by October 2001. Can you confirm and tell me where I can find additional information on this?


5/24/2001:

In New Jersey, the HINT (Healthcare Information Networks and Technologies) law promotes the development and use of health care Electronic Data Interchange (EDI) using national standards to achieve health care administrative simplification, resulting in potential cost savings for both the public and private sectors. According to state officials, HINT is mandated only among those entities regulated by the New Jersey state Department of Banking and Insurance (DOBI); Medicaid is NOT regulated by DOBI. Therefore, New Jersey Medicaid's decision to adhere to the HINT time line, for implementing transactions and code sets, is merely voluntary and not mandated.

The HINT law will require certain transactions and code sets be implemented prior to the federally mandated HIPAA compliance date. However, the HINT rule has not been finalized and therefore no compliance date relative to HINT has been published. The proposed rules are available on the Department of Banking and Insurance's web site: Answers to Your Questions" -- on the ADMNSIMP website so that FAQs coming into HIPAA-QUESTION can be accessed separately from the FAQs published earlier.

Each new FAQ that is added will have a posting date (the date the FAQ was posted on the website), and the ADMNSIMP homepage will display the date of the most recent posting. You will be able to check this date to determine whether any new answers have been posted since the last time you checked. If there has been a new posting, you will be able to identify the specific FAQ that has been added or updated by checking the posting date associated with each question.

As the number of FAQs grows, we will develop a structure for the questions and answers (e.g., by topic) to improve accessibility.

Number of transactions per transmission

Can health plans limit transmissions to contain one type of transaction, such as health care claims, or must we be capable of accepting and sending multiple types of transactions in one transmission, such as claims and remittance payment?


12/28/2000:

Health plans may continue to limit one type of transaction (e.g., health care claim) to a single transmission. Health plans are not required to redesign their systems in order to accept or send multiple types of transactions (e.g., health care claims, eligibility, claim status) in one transmission.

Faxed transmissions

If a health care provider faxes a health care claim form, must the transaction comply with the standard?


12/28/2000:

Fax imaging and voice response transmissions are not subject to the HIPAA transactions standards but may have to meet privacy and security standards. Health plans may continue to offer these services, however, they must still be able to accept and send the HIPAA standard transactions.

Code sets named in Implementation Guides

In the ASC X12N Implementation Guide, there could be code sets listed which are not named in the final rule. For example, the Professional 837 Implementation Guide lists HCPCS, NDC Codes, HIEC Product Service Codes, and Mutually Defined Codes of which only the first two code sets are named in the final rule. Am I in HIPAA compliance if I use any code set not included in the final rule but listed in the Implementation Guide?


12/7/2000:

The standards adopted in the Standards for Electronic Transactions Final Rule do not include the Home Infusion EDI Coalition Coding System (HIEC). In the final rule we acknowledged that the coding systems adopted as national standards may not address all business needs, however, health plans must conform to the requirements for code set use specified in the final rule. Therefore, the use of HIEC or other codes not adopted in the final rule is not compliant with HIPAA. As stated in the final rule, segments exist in standard transactions that allow for manual processing of services for which codes have not been adopted.

We will be requesting corrections to the Implementation Guides to remove all references to code sets that have not been adopted under HIPAA.

Professional liability insurer

I work for a professional liability insurance company that specializes in medical malpractice. Often the claims we handle involve health information about patients of our policyholders (providers such as doctors or dentists). We enter some basic claim information in our database for internal use, but we do not transmit this information electronically to others outside our company. Will we need to comply with the HIPAA regulations? If so, can you recommend resources that can help us determine exactly the extent that we will be affected by HIPAA?


12/7/2000:

The definitions at 45 CFR 160.103 apply to all the HIPAA administrative simplification regulations. A professional liability insurance company does not meet the definition of a health plan, health care clearinghouse, or health care provider, and therefore is not a covered entity that is directly regulated under the HIPAA administrative simplification regulations. The malpractice claim information that is stored in the company database for internal use does not meet the definition of a health care claim as set forth in 45 CFR 162.1101. The professional liability insurance company described in this question would not be regulated by the final regulation on Standards for Electronic Transactions published in the Federal Register on August 17, 2000.

Since the professional liability insurance company does maintain health information as defined in 45 CFR 160.103, and since the source of the health information would generally be a covered entity (a health care provider or health plan), it is possible that the final HIPAA regulations on standards for privacy and security of health information, when they are adopted, will have an effect on the professional liability insurance company's protection of the health information or on its disclosure of the information to other entities, such as a malpractice law firm. The final regulations on privacy and security and accompanying Frequently Asked Questions will be posted at