**********************
******************
Updated:09/19/2008 Copyright © 1996-2008 Skip Stein
HIPAA Repository EDI Slide Presentation
Introduction
MSC, Inc. has developed a HIPAA Repository Concept that will provide a common approach to HIPAA compliance for all of our CLIENT systems EDI interface requirements. (See Diagram) In developing the HIPAA Repository, in addition to addressing the actual HIPAA requirements, we needed to consider issues such as performance and storage requirements to assure that our design will meet the demands of our largest customers.
This document is intended to provide an overview of the HIPAA Repository design so that our customers have an understanding of our approach. Our HIPAA Repository will help your organization in complying with the HIPAA Electronic Transaction Standards mandates.
The HIPAA Repository processing is a batch process for HIPAA-regulated EDI transactions. Real-time EDI functionality will be developed and delivered at a later time. Please note that this document is for general information purposes only and may not serve as legal or professional advice or counsel.
HIPAA Repository Overview
The MSC, Inc. HIPAA Repository is designed to work with healthcare application systems to capture all of the input and output transactions that are subject to the HIPAA regulations for electronic transactions. The HIPAA Repository is a relational database structure for which we plan to support MS SQL Server and Oracle as DBMS choices for our customers. Other data base engines, such as Sybase and DB2 will be supported at a later date.
Upon receipt of a supported HIPAA EDI transaction, the data will be written to the HIPAA Repository and passed to the healthcare application system for processing. Output from the healthcare application system that is required to be in a supported HIPAA EDI format may be combined with data in the Repository to generate a HIPAA compliant response. This response is then saved in the HIPAA Repository prior to being passed through the HIPAA Repository for transmission to the trading partner. There will be a series of inquiries developed and processed against the HIPAA Repository so that users can view the information a transaction contained and the response generated by the healthcare application system. The compliant EDI transaction data will be saved in the HIPAA Repository in for subsequent use and formatting by the EDI translator software program.
Inquiries against the HIPAA Repository must be in compliance with security and privacy processing rules established by the organization. These security and privacy rules must be in conformance with existing HIPAA mandated rules. We will work with each individual client to formulate compliant audit and access tracking processes, procedures and data elements. Since each organization may interpret the HIPAA regulations in a slightly different manner, these functions and processes have been left to each individual installation.
MSC, Inc. HIPAA Repository Components
The following sections will describe the major components of the MSC, Inc. HIPAA Repository. In this document, the term ‘base system’ is used to refer to any managed health care, claims administration or group administration product for which the HIPAA Repository serves as a front end.
It is important to note that the MSC, Inc. HIPAA Repository is under development and there may be changes to the design prior to release of the product. Performance and maintainability are key considerations for our design and we may therefore choose to modify our approach if we determine there is a more effective way of accomplishing any of the functions required by the HIPAA Repository.
Transaction Reception
The MSC, Inc. HIPAA Repository is designed to work in a closely coupled manner with any one of several EDI industry translator products. These program products have been developed to receive, process and transmit standard EDI transactions according to various national and international standards. One of the most recently developed new standards is the HIPAA ANSI X12N transaction set. The HIPAA Repository is designed to handle these new HIPAA X12N transactions. While the client business may also process other X12 EDI transactions (or EDIFACT, VICS or other standards based transactions), the current HIPAA Repository is does not support these other standard EDI transactions at this time.
The EDI Translator component handles the reception of electronically transmitted transactions from trading partners. The EDI Translator will invoke compliance checking and translate or repackage the X12N transaction so that the HIPAA Repository can store the translated components into logical grouping of tables constituting a single healthcare transaction.
The process of translating the X12N transactions is conceptually very simple – place each data element in a table which itself represents a healthcare transaction data element group (Provider information, Patient information, procedure data, etc.) with the appropriate transaction header and control segments (see Appendix A – HIPAA Repository Key Structure). The resulting tables must constitute independent and compliant X12N transactions. The process does not assume that incoming transaction types will not be commingled (for example 837 and 270 transaction types may be packaged together). The information on the Transaction Header and Control Header segments for each fundamental unit will preserve the original hierarchical information from the input file.
Transaction Transmission
The HIPAA Repository will be used to store HIPAA compliant EDI transactions prior to passing these outbound transactions to the EDI translation program for transmission to a trading partner. This process will be applied to a number of single, HIPAA-compliant X12N documents from the Repository, all may be intended for the same or different trading partners. The EDI translator will handle the outbound direction and processing based on the HIPAA Repository Transaction Header and Control Segments, producing a single transmission file with one or more transactions. The HIPAA EDI formatting will be applied to this file using the EDI translator, which will also handle the transmission of the data.
HIPAA Repository and Access Routines
The HIPAA Repository is a relational data base structure. Our plans call for supporting MS SQL Server 2000 and Oracle on a Windows 2000 Server platform. The Repository will store the HIPAA EDI transactions that pass through the HIPAA Repository along with a series of relational tables that describe the data in the transactions. Each HIPAA transaction will be saved in X12N format in the Repository relational tables. The relational tables will be used to access the data in the Repository either for inquiry purposes or when merging data from the base system and the Repository in creating a response.
The HIPAA Repository is designed to store a unique ID for every document stored. This unique ID is called the Repository ID or GWID and is based the Globally Unique Identifier (GUID) generated by the Windows 2000 operating system. This GWID is generated before the document is stored and is guaranteed to be unique for every call. See Appendix B for more details on the GWID. Users may request a document by its GWID or by one of the predefined alternate indexes.
Appendix A – HIPAA Repository Key Structure
| Column Name | Description |
| EDIT-TableName | Table Name |
| EDI-IntchgCntrlNum | Assigned by the Translator. A unique number that is assigned for each Interchange Header Received / Sent |
| EDI-FunctCntrlNum | Assigned by the Translator. A unique number that is assigned for each Functional Header within the Interchange that is Received / Sent. |
| EDI-Typ | Inbound Transaction / Outbound Transaction |
| EDI-TranSet | IE: 835, 837, 276, 277, etc. |
| EDI-TranSetCntrlNum | Assigned by the Translator. Unique number that is assigned for each Transaction set with Functional that is Received / Sent. |
| EDI-SegSeqNum | Assigned by the Translator. The number is sequential, beginning with the first segment having a value of 1, second segment 2, and so on. Gives a positional reference. If the total number of segments in a transaction was 100, then the first segment would be assigned a 1 and the last would be assigned 100. |
| EDI-LoopSeq | Transaction Loop Id. (IE: 1000A, 1000B, etc.) |
| EDI-LoopSegSeq | Assigned by the translator. The number is sequential, beginning with the first segment within the loop having a value of 1 and the second a value of 2 and so on. If there were 10 segments in a given loop, then the first segment within the loop would have a 1 and the last would have a 10 as the value for this field. |
| EDI-HeaderDetailFlg | Header or Detail Component Flag. H=Header D=Detail |
| EDI-ProcessedFlg | Indicator that this transaction set of tables have been processed. |
| EDI-EditCd | Indicator/Code that controls acceptance/rejection of this transaction set - TBD! |
| EDI-ICN | Internal Claim Number EDI Control (Separate from CLIENT Claim Number) |
| EDI-ICN-Sub | EDI ICN Subsidiary Number for Claim adjustment, additional service lines or related additional data (Separate from CLIENT) |
Appendix B – Repository ID (GWID)
The Repository ID or GWID is based on the Globally Unique Identifier (GUID) that is generated by the Windows 2000 operating system. The GWID will serve as a unique key to transactions stored in the HIPAA Repository and will be derived in the following manner:
- Windows 2000 generates a GUID in the following format: 12345678-1234-1234-1234-123456789ABC.
- The Repository Access routines will strip off the dashes to create the GWID. The resulting GWID would then have the following format: 12345678123412341234123456789ABC
- Stripping these extra characters brings the size of the GWID down from 36 bytes to 32bytes each.
After investigating other methods for generating a unique key for each document, we found that the performance increase in basing the GWID on the Windows 2000-generated GUID outweighs the issue of the extra disk space that the 32 byte GWID occupies.
A GUID is a Globally Unique IDentifier. It means the no two GUID's are the same no matter what computer they were generated on. These GUID's are very handy for unique ID's for databases or anything else.
Private Declare Function CoCreateGuid Lib "OLE32.DLL" _
(pGUID As GUID) As Long
Private Declare Function StringFromGUID2 Lib "OLE32.DLL" _
(pGUID As GUID, _
ByVal PointerToString As Long, _
ByVal MaxLength As Long) As Long
Private Type GUID
Guid1 As Long
Guid2 As Long
Guid3 As Long
Guid4(0 To 7) As Byte
End Type
Public Function CreateGUID() As String
Dim udtGUID As GUID
Dim sGUID As String
Dim lResult As Long
lResult = CoCreateGuid(udtGUID)
If lResult Then
sGUID = ""
Else
sGUID = String$(38, 0)
StringFromGUID2 udtGUID, StrPtr(sGUID), 39
End If
CreateGUID = sGUID
End Function
'--end code block
