From:	kepa.zubeldia@envoy.com
Sent:	Monday, August 23, 1999 9:47 PM
To:	Interop@afehct.org
Subject:	Proposal #12 - Real Time 

Here is the proposal that reflects the Real Time Security
Interoperability parameters as were defined by the group during
the meeting in Alexandria on June 29.

Real Time connectivity in this context is the connection over the
Internet from a healthcare provider location (or billing service,
PMS vendor, clearinghouse, or similar entity) to a healthcare
transaction processor such as a payer or a clearinghouse or
switch.  The data sent is in a standard EDI format such as NCPDP,
or ASC X12 270/271.  The transaction is originated by the party
that establishes the connection.  Each transaction causes some
response that is also in EDI format as applicable to the
response.

The protocol is just a socket that handles the NCPDP or X12
message, without the additional MIME headers like HTTP uses.  So,
it is not HTTP protocol.

We are not trying to define the EDI formats, as those are already
in place, but the assumption is that whatever happens to be the
format of the transaction, either the envelope (e.g. X12-ISA) or
the transaction itself contains the identity of the sender and
the receiver.  The identity will probably be a number agreed
between the sender and receiver.  In the future, as HIPAA goes
into effect, the identity could be a standard ID number such as a
PayerID or NPI, or a new number such as the "EDI address"
described in the NPRMs.  Regardless of its nature, it is assumed
that the identity of the sender is available to the receiver
system inside or enveloping the transaction.

For Real Time we are also under the assumption that either the
transaction or its envelope could contain the password of the
sender as applicable to the receiver.  For NCPDP transactions the
password is not part of the transaction, and for X12 transactions
the password could be part of the envelope, but not part of the
transaction data itself.  The identity of the EDI sender is the
minimum required authentication mechanism for real time
transactions.  This may be supplemented by a client certificate
as described later.

The identity of the EDI message will be the identity of the
location sending the message, or a physical computer system, or
the identification of a legal entity, or a store within a
pharmacy chain, or a department of a University, or a similar
identity.  In most cases it will not be the identity of the
healthcare provider that caused the transaction (except for the
case of a solo provider).  The healthcare provider ID will be
inside the transaction, elsewhere, unrelated to the EDI identity
of the sender of the transaction.

The host system at the payer location or clearinghouse or switch
will  likewise identify itself in the response EDI messages.

The bottom line is that whatever authentication system is being
used today for EDI transactions over private lines should not be
discontinued when using the Internet.  The use of certificates
should provide an additional level of authentication over the
transaction self-authentication.

The data will be protected with an SSL session, implemented with
a commercial SSL implementation of Version 3.0 or newer, or the
equivalent TLS version 1.0 or newer.  A minimum of 112 bits of
encryption will be required in the SSL or TLS session, such as
Triple DES (EDE).  Weaker encryption methods with 40 or 56 bit
implementations will be disabled at the server, Also, methods
that provide a strong session encryption (112 or 128 bits) but
reveal part of the key during the SSL negotiation will  not be
used.  In general, these weakened encryption methods are
described as "export" or "medium" grade encryption.  The SSL
server configuration must allow only strong encryption and
disable SSL negotiation with weaker methods.

In order to establish the SSL session, the server will have a
certificate of 1024 bits or more.

Client certificates are optional.  We need to determine during
the pilot whether client certificates should be required.  Some
of the servers in the pilot may be asking the client for a
certificate during the session negotiation, but until the pilot
participants make a decision in this area, the SSL session
should be established with only the server certificate if the
client certificate is not available.  Clients must be ready to
present a certificate if the server requires it.

Client certificates must have a public key with at least 1024 bits.

If the client presents a certificate, the server must validate
the certificate, the certificate trust path, check it against the
latest CRL, and use the certificate to determine access control
per the access control mechanism of the server.

It is likely that the high volume real time servers will use CRLs
instead of OCSP certificate validation, so the servers must have
a recent CRL and an established mechanism for periodic refreshing
of CRLs from the different CAs involved.

In order to have most flexibility, the workgroup decided not to
have a common TCP port to be used for all transactions, but allow
each server to specify the address and port to be used for each
transaction.  This could vary by transaction type, like
specifying a host/port for eligibility and another host/port for
referrals.  But the server could also specify the same host/port
for all transactions, if that is their need.

The Internet host name and TCP port will be expressed in the
usual format of //host.domain:port/

The client opens a TCP/IP SSL session to the specified host/port
and starts sending one or more transactions.  The responses are
received from the same port.  Once the response is received, the
client determines whether to continue with a persistent session
or to disconnect the session.  The host should not automatically
disconnect the session after sending the response.  Persistent
sessions should be disconnected by either the host or the client
after a timeout of 1 hour without any activity.