User Guide : Managing Document Schemas : About E-Documents : E-Document Types
 
Share this page             
E-Document Types
E-documents are actually ASCII data strings that are sent electronically from the sending system to the receiving system and back to the sending system. The structure of the data strings different for the e-doc types. The documents are readable. However, you must understand the individual codes so that you can understand the information that the document is communicating. For instance, HIPAA e-docs start with an ISA header that includes important structural information, while HL7 e-docs begin with a MSH header. However, both contain PID segments that contains patient identification information.
Currently, the following e-document types are supported in Document Schema Designer:
EDI X12
HL7
HIPAA
EDIFACT
SWIFT
EDI X12
EDI stands for Electronic Data Interchange. It is the direct computer-to-computer exchange of structured data, sent in a form that allows automatic processing without human intervention.
EDI, uses standard formats to pass data between different business systems. Third parties provide EDI services that enable organizations with different equipment to connect. Although interactive access may be a part of it, EDI implies direct computer-to-computer transactions into vendors' databases and ordering systems. The EDI standard is ANSI X12, developed by the Data Interchange Standards Association (DISA). ANSI X12 is either closely coordinated with or is being merged with an international standard, EDIFACT.
Beginning in the 1960s, large corporations created private networks with business partners to share information about sales, supplies, funds transfers, and order processes. Using EDI, a retailer tells a warehouse about an order, and the warehouse could immediately notify suppliers of an inventory change. Information passed through these networks differed from most of today's Internet information, in that it was structured or standardized. Members of the EDI network agreed on the forms that presents the data, and uses translation software to ensure that the transmitted data can be understood by their computer systems and that their records/inventory immediately updated.
An EDI message contains a string of data elements, each of which represents a singular fact, such as a price, product model number, and so forth, separated by delimiters. The entire string is called a data segment. One or more data segments framed by a header and trailer form a transaction set, which is the EDI unit of transmission (equivalent to a message). A transaction set often consists of what is contained in a typical business document or form. The parties who exchange EDI transmissions are referred to as trading partners.
To learn more about EDI terminology, tutorials, and technical information, see http://www.x12.org
HIPAA
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandates that health care organizations must adopt transaction and information security standards to support the electronic exchange of administrative and financial health care data for the purpose of administrative simplification. See the HIPAA Transaction Set Synopsis subsection below.
How HIPAA Adapters Can Help
Three HIPAA adapters are available for use with Map Designer to help speed the creation, parsing, transformation, and integration of HIPAA transactions with existing systems. They provide built-in HIPAA transaction parsing logic, and compliant target templates for mapping native data (without the need to modify existing applications). The adapters provide a tool to develop and test transactions while maintaining data integrity.
Schema Files Included with Map Designer
The following schema files are included with map designer:
270.ds.xml
271.ds.xml
Document schema for other HIPAA transaction sets can be purchased. Contact Sales for more information.
Check for Validity of HIPAA EDI Structure
Here is a quick tip to determine whether you are working with valid HIPAA EDI files as the source. Check the value of the second record of the file. The value here should be something like "005010XNNN", where "NNN" is the numeric value corresponding to the appropriate HIPAA X-code transaction set (such as "005010X098" for the Professional 837).
For example:
ISA*00* *00* *30*34-39495350 *30*11-22233344
*000302*1541*U*00401*000000742*0*T*:
GS*HC*TEST-SND*TEST-RCV*20000302*1541*1*X*005010X098
HIPAA Transaction Set Synopsis
A listing of HIPAA transaction sets, which includes Guide ID, Guide Description, Primary Trading Partners, and Exceptions/Limitations, follows:
270/271: Health Care Eligibility/Benefit Inquiry and Information Response
276/277: Health Care Claim Status Request and Response
278: Health Care Services Review -- Request for Review and Response
820: Payroll Deducted and Other Group Premium Payment for Insurance Products
834: Benefit Enrollment and Maintenance
835: Health Care Claim Payment/Advice
837: Health Care Claim: Institutional
837: Health Care Claim: Dental
837: Health Care Claim: Professional
277/275: Health Care Claim Request for Additional Information and Response
NCPDP: National Council for Prescription Drug Programs
Other non-HIPAA related data types
NSF: National Standard Format
270/271: Health Care Eligibility/Benefit Inquiry and Information Response
GUIDE ID: 005010X092
Guide Description: The Health Care Eligibility/Benefit Inquiry and Information Response Implementation Guide describes the use of the Eligibility, Coverage or Benefit Inquiry (270) Version/Release 3070 transaction set and the Eligibility, Coverage, or Benefit Information (271) Version/Release 3070 transaction set for the following business usage:
Determine if an Information Source organization, such as an insurance company, has a particular subscriber or dependent on file
Determine the details of health care eligibility and/or benefit information
PRIMARY TRADING PARTNERS: Health care providers, such as hospitals and physicians. Health care payers, such as insurance companies, HMOs, PPOs, and state and federal agencies, such as Medicare, Medicaid and CHAMPUS.
EXCEPTIONS/LIMITATIONS: Intended for use for health care eligibility/benefits. Does not provide a history of benefit usage. Is not intended for property and casualty or workers' compensation usage.
276/277: Health Care Claim Status Request and Response
GUIDE ID: 005010X093
DESCRIPTION: The Health Care Claim Status Request and Response Implementation Guide describes the use of the ANSI ASC X12.316 Health Care Claim Status Request (276) transaction set and the ANSI ASC X12.317 Health Care Claim Status Notification (277) transaction set for the following business usage:
Request the status of health care claim(s) and respond with information regarding the specified claim(s).
PRIMARY TRADING PARTNERS: Health care providers, such as hospitals, physicians, medical groups, independent physician associations, and facilities. Health care payers, such as insurance companies, HMO's, PPO's, and state and federal agencies.
277/275: Health Care Claim Request for Additional Information and Response
When finalized, this document will be mentioned in an upcoming Notice of Proposed Rulemaking (NPRM)
278: Health Care Services Review -- Request for Review and Response
GUIDE ID: 004020X094
DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Services Review Information (278) Version/Release 5010 transaction set for the following business usage:
Health care admission certificate requests and responses
Referral requests and responses
Health care services certification requests and responses
Extend certification requests and responses
Certification appeal requests and responses
Informational inquiries and responses
PRIMARY TRADING PARTNERS: Health care providers, such as hospitals, physicians, medical groups, independent physician associations, and facilities. Health care review entities, such as insurance companies, HMOs, PPOs, health care purchasers, professional review organizations, and other utilization review organizations.
EXCEPTIONS/LIMITATIONS: Does not include health care services review for patient arrival, transfer, and discharge notices; certification change notices; and medical therapy supporting information.
820: Payroll Deducted and Other Group Premium Payment for Insurance Products
GUIDE ID: 005010X061
DESCRIPTION: Describes the use of the ANSI ASC X12 Payment Order/Remittance Advice (820) transaction set, version 5010 for the following business usage:
Transmit payroll deducted premiums for a wide variety of insurance products, to include life, health, property and casualty, and disability.
This guide was also designed for health care premium payments between federal and state governments, government agencies, and private industry.
PRIMARY TRADING PARTNERS: Insurance companies Third-party administrators Payroll service providers Internal payroll departments.
EXCEPTIONS/LIMITATIONS: Does not support insurance claim payments and not intended for use in pension and investment type products.
834: Benefit Enrollment and Maintenance
GUIDE ID: 005010X095
DESCRIPTION: Describes the use of the ANSI ASC X12 Benefit Enrollment Maintenance (834) transaction set for the following business usage:
Enrollment of group health care plans
PRIMARY TRADING PARTNERS: The benefits process addressed in this guide involves the transmission of benefits information between group benefit plan sponsors and benefit plan administrators.
835: Health Care Claim Payment/Advice
GUIDE ID: 005010X091
DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim Payment/Advice (835) transaction set for the following business usages:
Make payment on a health care claim
Send an Explanation of Benefits (EOB) remittance advice
Make payment and send an EOB in the same transaction
PRIMARY TRADING PARTNERS: Health care providers such as hospitals and physicians; health care payers such as insurance companies, PPOs, HMOs, and state and federal agencies.
EXCEPTIONS/LIMITATIONS: Intended use is for health care remittance advice/payment. It is not intended for non-health care use.
837: Health Care Claim: Dental
GUIDE ID: 005010X097
DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim (837) transaction set for the following business usage:
Submit and transfer dental claims and encounters from health care providers to health care payers
PRIMARY TRADING PARTNERS: Health care providers, such as dentists and dental groups. Health care payers, such as private health care insurers and HMOs.
EXCEPTIONS/LIMITATIONS: Does not explicitly support property and casualty medical bill claims.
837: Health Care Claim: Institutional
GUIDE ID: 005010X096
DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim (837) transaction set for the following business usage:
Submit and transfer institutional claims from health care providers to health care payers
PRIMARY TRADING PARTNERS: Health care providers, such as clinics and hospitals. Health care payers, such as private insurers and federally-supported health care payers.
EXCEPTIONS/LIMITATIONS: Does not explicitly support property and casualty medical bill claims.
837: Health Care Claim: Professional
GUIDE ID: 005010X098
DESCRIPTION: Describes the use of the ANSI ASC X12 Health Care Claim (837) transaction set for the following business usage:
Submit and transfer professional claims and encounters from health care providers to health care payers and between payers
PRIMARY TRADING PARTNERS: Health care providers, such as physicians and surgeons. Health care payers, such as private health care insurers and HMOs.
NCPDP: National Council for Prescription Drug Programs
Purpose: for trading of prescription information
NSF: National Standard Format
Description: ASCII-based claim form. Precursor to HIPAA claims. This "standard" is a form for a physician encounter.
For more information, see the following web site:
http://www.hcfa.gov/hipaa/hipaahm.htm
Other non-HIPAA related data types
997 (EDI): Functional Acknowledgement
Purpose: To start and identify an interchange of one or more functional groups.
HL7
Health Level Seven (HL7) is an organization that develops messaging standard specifications that enable disparate healthcare applications to exchange keys sets of clinical and administrative data. The HL7 standard provides an electronic interchange of clinical, financial and administrative information among independent healthcare-oriented computer systems, such as hospital information systems, clinical laboratory systems, enterprise systems and pharmacy systems.
"Level Seven" refers to the highest level of the International Standards Organization's (ISO) communications model for Open Systems Interconnection (OSI) - the application level. The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.
HL7 is singular as it focuses on the interface requirements of the entire health care organization, while most other efforts focus on the requirements of a particular department.
HL7 Recognized in US and Internationally
The HL7 governing body group works to comply with United States and International standards development activities. HL7 is an American National Standards Institute (ANSI) approved Standards Developing Organization (SDO).
The global influence of HL7 is evidenced in the number of countries that adhere to HL7 initiatives, including Argentina, Australia, Canada, China, Czech Republic, Finland, Germany, India, Japan, Korea, Lithuania, The Netherlands, New Zealand, Southern Africa, Switzerland, Taiwan, Turkey and the United Kingdom.
HL7 Standard Structure
The HL7 standard provides the layout of messages exchanged between two or more applications. A message is comprised of multiple segments that must be sent in a particular order and which may or may not repeat. Segments are collections of data elements that typically share a common subject. For example, the PID segment contains patient identification data elements such as name, address and social security number. The NK1 next of kin segment contains similar data elements about the patient's next of kin.
HL7 defines which data elements are to be sent, and determines the data type and the suggested length of each. It also indicates whether the data element is required or optional, and whether it may repeat. Fields must be sent in the order in which they are presented in the Standard. This way, both the sending and receiving systems know what data is expected, in what order, and in what format. HL7 also enables one system to query another for relevant information.
For the latest official information on HL7 structure and standards, go to http://www.hl7.org.
Accessing HL7 Data Via Map Designer
Document Schema Designer currently supports HL7 version 2.3.1.
At first glance, HL7 data looks nearly identical to EDI data. But there are significant differences. HL7 data contains:
Repeating Field Name support
Significantly different Properties
Deeper file structure -- Segments, Fields, Components, and Subcomponents
Different data types (such as basic data types)
Segments with basic data types cannot have child fields or components
Subcomponents can be basic data types only—since they cannot have children
Data type designation is essential for the hierarchy in HL7 data
MaxSize property only (no MinSize property available)
Loose structure, which necessitates use of Document Schema Designer to tighten structure by tweaking properties, changing data types, or making fields required or optional.
EDIFACT
EDI, or Electronic Data Interchange, uses standard formats to pass data between the disparate business systems. Third parties provide EDI services that enable organizations with different equipment to connect. Although interactive access may be a part of it, EDI implies direct computer-to-computer transactions into vendors' databases and ordering systems. The EDI standard is ANSI X12, developed by the Data Interchange Standards Association (DISA). ANSI X12 is either closely coordinated with or is being merged with an international standard, EDIFACT.
An EDI message contains a string of data elements, each of which represents a singular fact, such as a price, product model number, and so forth, separated by delimiters. The entire string is called a data segment. One or more data segments framed by a header and trailer form a transaction set, which is the EDI unit of transmission (equivalent to a message). A transaction set often consists of what would usually be contained in a typical business document or form. The parties who exchange EDI transmissions are referred to as trading partners.
SWIFT
Society for Worldwide Interbank Financial Telecommunication (SWIFT) message type is the format or schema used to send messages to financial institutions on a secure SWIFT network. The data exchanged between institutions is unambiguous and machine friendly, facilitating automation, reducing costs and mitigating risks.
SWIFT messages consist of five blocks of the data including three headers, message content, and a trailer.
References to E-Document Terminology
 
E-Document Name
Web Site
Description
EDI
Provides information about EDI.
Provides the structural hierarchy of EDI transaction sets.
Technical tutorial for EDI X12. It emphasizes on EDI and XML and their evolving standards.
Includes several white papers on EDI sections.
Emphasizes on United Nations EDIFACT, the international version of EDI. This is the United Nations Trade Data Interchange Directory.
HL7
http://www.hl7.org/
Search for the latest glossary at the Health Level Seven (HL7) site.
HIPAA
Provides information about the Center for Medicare and Medicaid Services (formerly the Health Care Financing Administration).
http://snip.wedi.org/
Provides the Strategic National Implementation Process.
EDIFACT
http://www.unece.org/trade/untdid/welcome.htm
Provides information about EDIFACT.
SWIFT
https://www.swift.com
Provides information about SWIFT standards.