Medical Claims Processing Briefing: SGML Application
Subject: Medical Claims Processing Briefing: SGML Applications
Date: Sun, 15 Jun 1997 20:45:08 -0400
From: Liora Alschuler <liora@the-word-electric.com>
Newsgroup: comp.text.sgml
-----------------------------------------------------------
BRIEFING ON AUTOMATED CLAIMS PROCESSING:
NOTE BENE: The following is supplied for the benefit of vendors and
consultants who wish to address claims processing requirements in their
demonstrations or presentations. (See the previous post annoucing the
HL7 SGML Mixer.) Please note, however, that this conference is not
focused solely on the government requirements. While the implementation
of the recent legislation will influence the industry, there are many
forces shaping healthcare information requirements. Unlike the defense
industry of the late 1980's where the DoD CALS program was pushing the
development of SGML technology, we expect that in healthcare private
industry will play the leading role over the next several years.
That said, and while there is no open or formal RFP from either the
government insurers or their providers, there is substantial interest in
innovative solutions for claims attachment processing on the part of
both the government and private industry. We feel that there are
substantial opportunities to influence this process by demonstrating
solutions both to the current mandate and to future requirements.
Background
The Health Insurance Portability and Accountability Act (HIPAA, also
known as Kennedy-Kassebaum) passed by the US Congress and signed in 1996
mandates that standards for claims submission and supporting
transactions be selected by the Secretary of the Department of Health
and Human Services. HL7, the parent organization of the HL7 SGML SIG, is
working closely with X12N, the insurance sector of X12 (EDI), to support
the HIPAA requirement for claims attachment processing. A Proof of
Concept (POC) initiative is taking place under the direction of the US
Health Care Financing Administration (HCFA). A joint working group (JWG)
comprised of representatives of both X12N and HL7 participated in an
orientation on June 4, in Chicago.
Claims Processing Today
HCFA has experience and a track record in accepting Medicare claims as
X12N transactions. Each X12 transaction (which is essentially the same
as an HL7 message) is known by a number and has a fixed purpose and data
definition. Several transactions are used for claims submission from
providers to payors and for notification of results from payors to
providers. While X12N and HL7 messages are quite similar in syntax and
the semantics overlap (there is a data modeling and reconciliation
effort underway), in most implementations X12N has been used for
exchange between enterprise boundaries while HL7 has been used within a
single enterprise, between systems using different proprietary data
formats.
Each transaction/message is the equivalent of a single paper claims
form. When additional information is required to support a claim, the
subsequent submission is called an attachment. Ideally, an attachment is
defined as "only what is required to adjudicate a claim." Under the
current system, while claims are submitted electronically, attachments
submission and processing is paper-based. For the most part, attachments
conform to more-or-less agreed-upon paper forms.
Paper attachments can be any one of these three basic types:
1. "Standard" forms -- Each provider and each payor may have their own
list of standard attachment forms with data elements that differ,
slightly, from similar attachment forms used by other providers and
payors. A single agency may use 75 or more different attachment forms
and may add a form at any time.
2. Data elements -- The payor can request a single piece of information
(a reading, result, report or date, for example).
3. The patient record -- The payor can request an entire medical record.
New Requirements
HIPAA legislation mandates that by 2/99 the Secretary of the Department
of Health and Human Services select a standard for automated
attachments. This standard must service the commercial insurance
industry as well as the government. The legislation does not define
"automated". It could be interpreted as transfer of a bit-mapped image
of an attachment document or transfer of fielded data automatically
processed on the receiving end by intelligent engines. The current
requirement does not define the granularity or functionality required
from the transmitted attachment. All indications are that the proof of
concept initiative will interpret this as the submission of fielded data
organized and defined as if on a paper form for the first type of
attachment. The initiative has not formulated a strategy to address the
second and third types of attachments and it is here that the largest
opportunity to demonstrate innovative and forward-looking solutions
lies.
The first tasks assumed by the X12 HL7 JWG are a census of forms in
current use, identification of the top five, most-used forms, creation
of an agreed-on data model for these, and subsequently for all forms.
The data models will be encoded and transferred in a hybrid syntax
composed of X12, where pre-defined X12 transactions apply, and HL7,
where HL7 messages apply, or a hybrid of X12 and HL7 (an X12 envelop
with HL7-encoded data in a segment.) The X12N transaction that will
serve as the envelop is the 275 -- a transaction type for clinical data
that was defined, but never implemented. The 275 includes a BIN segment
which can be any binary data segment. The CAP segment which precedes the
BIN will identify the data type of the BIN.
Long term requirements include not only send, receive, and
acknowledgment, but real-time notification of reimbursement.
Opportunities for Technical Demonstrations
We see several opportunities to demonstrate how SGML encoded data and
SGML-based technology can address these requirements.
Much of the information requested in attachments is clinical data that
exists in notes (narrative) and is not defined by either X12 or HL7.
There may be substantial advantages to use of SGML or XML to describe
this data and send it in the BIN segment within an X12 or HL7 attachment
envelop. This can be demonstrated for each type of attachment.
Where the requested attachment does not conform to an existing document
or form, there is a significant opportunity for demonstration of the
advantage of SGML-based attachments.
Consider that even in the first case, where a single attachment form is
well-defined, the number of attachments is very difficult to ascertain
and is constantly shifting, changing, and increasing. Listing and
defining all attachment forms, creating separate, but overlapping data
models for each, and standardizing these through X12N or HL7 balloting
will be a long and cumbersome process.
A standard query and link mechanisms can accommodate widely varying
requests even where no agreed-upon forms exists as long as there are
standards for SGML encoded medical data. Today, lacking such a standard,
send and receive by link or query mechanisms can illustrate the
direction that ultimate solutions will take once such a standard is in
place and can generate support for this standard.
Public and private insurers and providers will be receptive to and
interested in demonstrations that meet the immediate POC requirement for
known attachment forms including:
1. Creation of SGML-encoded documents with
structured editors
database extraction
2. transmitting and receiving these documents within message segments.
3. payor processing such as:
import and display in a desktop browser,
import and insertion into a database,
transformation and reformatting of data,
standard queries performed on XML data.
4. demonstration of flexible query and link mechanisms that can operate
between distributed, secure systems such that payors can request and
received all three types of attachments: pre-defined data collections,
single data elements, entire medical records.
Participants in the HL7 SGML Mixer are invited to address these
government requirements for electronic attachments or other requirements
for medical record creation, distribution, and processing unrelated to
claims attachments. For those specifically interested in addressing the
claims attachment requirements, we invite forward-looking solutions that
meet or exceed the immediate proof of concept requirements and that
illustrate the application of sgml-based tools and technology for these
difficult questions.
We will post examples of attachments on the web sites of the three
sponsor organizations or you can request a copy by fax from Marion
Elledge at GCA (703) 519-8193
FOR MORE INFORMATION:
Contact the organizations co-sponsoring the event
* GCARI (Graphic Communications Association Research Institute;
http://www.gca.org)
* HL7 SGML SIG (Health Level 7, SGML Special Interest Group;
http://www.mcis.duke.edu/standards/HL7/committees/sgml/)
* SGMLOpen (http://www.sgmlopen.org)
or
Liora Alschuler, HL7 SGML Mixer Program Chair
mixer@the-word-electric.com or 802/785-2623