Re: The Mao Zedong PKI Model
William, Credentials are to me something that are a must for business to trust one another, I find it interesting that everyone wants trustworthy credentials, but know one wants the responsibility. And while it's not a specific goal or issue for the routing group to resolve, without proper digital credentials, we most likely will fail to gain sufficient momentum from the industry to support our efforts for a CPP model. So, I'll through my two cents into the discussion. When we look at the business model for Credentialing that has been sustained for years in the medical industry, I find it difficult to believe that we must somehow come up with a new entity for digital credentialing. I'm not an expert in Provider Credentialing, but other organizations are, and it is my understanding that all Medical Providers must register with the State and be Licensed to provide specific services. Therefore, it seems to me that the obvious choice for a CA would be the Licensing authority. If they can issue a paper license, why can't they also issue and maintain digital certificates? I would presume that the technology and infrastructure to support such efforts would be contracted out to some other organization (Verisign, Entrust, Digital Trust, etc.) but if a Provider chooses to do healthcare business electronically, why can't the licensing organization provide a digital certificate? Same with a Payor organizations, it is my understanding that each payor must be licensed to provide insurance in a particular state and therefore should be able to receive both a paper license and digital certificate. I know several states are attempting to create services that provide this type of trusted environment. I'm specifically aware of the ACES program sponsored by the GSA at the federal level and Transact Washington a state based certificate service to conduct electronic transactions with the State agencies. Because the healthcare industry provides a social service and in many cases conduct business with the state, can we suggest that these certificates be used to conduct private business transactions between Covered Entities as well as public services transactions with state agencies? If so, it's seems it would be possible to include in the CPP which certificates an organizations has obtained, and allow business partners the opportunity to validate such certificate to determine the level of trust they wish to associate with an entity. Then the question becomes, will businesses accept a Federal certificate or a State certificate of a certain class of entity (individual, business representative, etc.) as a means to determine level of trust? Ronald Bowron William J. Kammerer [EMAIL PROTECTED] 08/07/02 08:02AM Payers are not necessarily the best entities to serve as Certificate Authorities (CA), for various technical reasons that I can get into later. But payers identifying providers for the purposes of signing X.509 certificates is a completely separate issue from payers credentialing participating providers. I can certainly see how provider malpractice sewage can back up into a payer's basement: after all, the payer is the one who published the directory of participating providers passed out to subscribers, and in effect forced patients to go to one of those providers (because the patient wouldn't have been compensated as much if he chose a non-participating provider). That's a completely different matter, I believe, than serving as a CA for identity purposes in e-commerce. More likely, a payer would not want to serve as a CA simply because other payers, trusting the first payer's judgement, would rely on the certificate without any real benefit accruing to the signing payer. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Kathleen Connor [EMAIL PROTECTED] To: Christopher J. Feahr, OD [EMAIL PROTECTED] ; William J. Kammerer [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Sunday, 28 July, 2002 01:08 AM Subject: RE: The Mao Zedong PKI Model The problem is health plan/payer liability for credentialing a provider who is involved in a malpractice controversy - it's been a huge barrier to any rationalization of the credentialing process and would spill over to credentialing e-commerce id as well if fraud were a possibility. This has been explored in other venues and the only cure that's come up so far is national legislation that would remove some of the liability. -Original Message- From: Christopher J. Feahr, OD [ mailto:[EMAIL PROTECTED]] Sent: Saturday, July 27, 2002 3:58 PM To: William J. Kammerer; [EMAIL PROTECTED] Subject: Re: The Mao Zedong PKI Model William, Thank you... this is the most lucid and understandable explanation I have read on this subject! It would seem that large payors are the ideal Certificate Authorities (CA) for providers in the context
Re: digital certificates for access to CPP repository
Chris Rachel, I've been holding back on this message for awhile, and some of my information has already been addressed by Rachel or Joe, but I've kept it in this response anyway. Chris' asks: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's repository record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If I've interpreted Joe's response correctly, he has provided the technical basis for how information can be shared with trusted and unknown entities. Not having the opportunity to read all the technical functions of the ebXML work, I'd like to believe they've got much of the functionality figured out to allow an entity the ability to protect their digital assets. But with regards to our efforts, my suggestion would be that anyone requesting access to the Healthcare CPP should be required to be fully registered with the Healthcare CPP. So if you don't provide your information including a valid digital certificate, you don't have access to others. I also think this initial registration should only allow access to Testing requirements or publicly known business requirements and each entity would have the freedom to define what others can access based upon a level of trust. This may be over complicating the situation, but it only makes sense to me that an entity would not release certain information to just anyone. From Joe's response, I would assume this is all possible. Also, by requiring entities to register, they could select whether or not they want active membership to be notified of their entry. If so, a receiving entity could develop the ability to automate the Trading partner agreement process (workflow). Otherwise, new CPP entities could notify each individual business that they are interested in an electronic relationship. The new business should not have to forward a bunch of TPA documents, but simply pull CPP for the information, and then provide documents that can be digitally signed using a trusted digital signature, or printed and then manually signed and returned. And, in response to Rachel's request for a real problem definition document. We all know that most of larger organizations have the resources in place to assess and plan for HIPAA, as demonstrated in the latest HIMSS surveys. The issues arise when the medium to smaller businesses attempt to determine where to start, what to do, and how long it will take. If I remember the HIPAA statistics correctly, there are slightly over 6000 Hospitals in the U.S. and over 80% of institutional claims are now electronic. Which means the institutions have already built the necessary relationships and have established much of the connectivity. Most likely the remaining players are the smaller facilities and the smaller insurance plans that haven't yet automated claim entry, adjudication or payment/posting systems. On the other hand, from the HIPAA statistics there are over 750,000 physicians, and I believe it was only 35% of professional claims (Physician Services, Dental, Optical, etc.) are electronic. These are the little guys... There are also many business associates that have yet to figure out where they fit as well. If the little guys are willing to out source their EDI compliance to a Clearinghouse, this could significantly improve the numbers, but arguably (ClaimsNet and others may disagree) even some of the Clearinghouses don't want to be bombarded by every 1-5 physician practice for EDI services - support costs are simply too high for the 20-150 claims per day they might see, or the physicians are not willing to pay the setup costs and ongoing support/transaction fees. So, once a physician upgrades or buys a HIPAA TC compliant office/admission billing management system, and is ready to hook it up to the EDI world, where does he begin? How long would it take to get all of the plans he participates with to approve his transaction interfaces? Or is the clearinghouse his only hope? Even if every covered entity was able to demonstrate that they can produce or process the HIPAA Transactions and Code Sets, determining how to Route transactions to the appropriate covered entity or business associate for processing will be challenging. So, establishing a standard method for discovering how and where to send EDI documents, what identifiers to use to ensure proper routing, seems to be the issue this group is attempting to resolve. If a Standard Service was available for any registered healthcare organization to lookup the business and technical requirements for conducting electronic data/document interchanges with any other registered healthcare organization, I think that could significantly reduce the barriers for organizations to become connected. Especially if the process can be fully automated such that the applications can discover and determine the Interchange and
Re: Fourth National HIPAA Summit: session on Identifiers, EDIAddressing and Routing
William, If you recall, there was discussion about how information is processed prior to the lookup. To solve the routing issues, must we first understand the process that occurs before routing can begin? Should we identify and validate our assumptions about the pre-routing process? It seems the information gathering process that occurs before a transaction set can be submitted via an exchange header will significantly impact the type of information needed in a directory or CPP. Do we need to understand the difference between the major models of insurance - i.e. Employer Sponsored(HMO, PPO), Self-Insured, Medicare/Medicaid, etc. and what type of information is necessary to properly identify the Plan that covers the patient? Do we get input from the provider side as to the typical processes used to gather insurance information? What types of information can you typically rely on from the patient to identify the appropriate Plan? How do you get that plan information today? Which types of plans are the most difficult to collect information about? What percentage of the 30% non-card carrying patients do the providers simply Patient bill, and then let the patient deal with the insurance company? Would this be within scope of our initiatives? So many questions, so little time -Ronald Bowron William J. Kammerer [EMAIL PROTECTED] 04/29/02 10:13AM Peter Barry and I presented a session on Identifiers, EDI Addressing and Routing at the Fourth National HIPAA Summit at the Renaissance Marriott in Washington, DC. last Friday. See http://www.hipaasummit.com/ for more information about the HIPAA Summit. The presentation slides themselves are available as a PDF file at http://www.novannet.com/wedi/ , by selecting Identifiers, EDI Addressing, and Routing Presentation. Like most Powerpoint slides, they are of limited usefulness unless you have the audio tape - which is available from HIPAA Summit for a price. Peter covered the National Plan and Provider IDs, their enumeration, and the database requirements for their maintenance and I followed up with an overview of some of our plans from the Joint WEDI/SNIP and AFEHCT ID Routing Special Interest Group. Folks did seem to doubt that anything as ambitious as our Healthcare directory and electronic Trading Partner profile could be available by the time H-day rolls around. I emphasized that the registry and electronic profiles will be usable in a manual fashion, where CPPs can be viewed with XSLT style sheets. Most of the value of the registry is just in the ability to locate trading partners' profiles - we don't need to wait for software vendors to update their software for completely automating the Discovery process. We've been assuming all along that providers would have no problem identifying payers and plans, figuring that each patient carries his insurance card around with him (and that the cards would have the EDI identifier printed on them). But we've been disabused of that notion by comments at the meeting - either patients don't have their insurance cards 30% of the time, or the information that the provider has on file for them is woefully out of date. Pharmacy, according to David Feinberg, maintains a centralized database to solve this problem: apparently, insurance companies load demographic information about their covered subscribers at some clearinghouse for shared access by pharmacies. Of course, this isn't the problem we're trying to solve (of patients not carrying their insurance card). We can make the assumption that the provider has some means of determining some ID of the plan or payer applicable to the particular patient. But to help things along, we may want to add searching by payer name as a requirement - to accommodate the situation where the patient knows the name of his plan or insurance company: refined searches in the registry can locate the actual CPP covering the plan to which eligibility inquiries can be sent. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
RE: Are only 15 characters in the ISA receiver ID enough?
Rachel, You may recall that we had submitted definitions for ISA sender and ISA receiver that I thought were considered acceptable. The basic concept is that the sender is the entity responsible for creating the exchange and it's contents and the receiver is responsible to processing the contents of the exchange. So, if the contents of the entire exchange (ISA to IEA) will be processed entirely by the receiver, then yes the ISA receiver will most likely be the provider or payor. But in many cases, data will be sent to a clearinghouse for the expressed purpose of processing the contents within the ISA to IEA and the repackaging the contents for transport to the ultimate receivers. In these cases, the ISA sender is a provider, but the receiver is the clearinghouse. While it may seem logical for a provider to send an ISA/IEA for each payor to the clearinghouse, that could make managing the transmission cumbersome. Instead of one 10Mb transmission with a 997 response, they could end up with 100+ transmitted files and 100+ responses. This can make managing the EDI interface too complicated for the average system environment. Although, there are some valid arguments regarding the complexities associated with bundling transactions within a single ISA/IEA. The mistake we keep making with regards to the Post Office comparison is we leave out two very important concepts - the type of Stamp we place on the envelope and the mailbox we initially place the letter into. If you put a FedEx package in your U.S. post office box, would it be sent? You first must determine the routing service (U.S. Post Office, UPS, Fedx). The other attributes on the package or envelop are dictated by the service chosen. The U.S Post office expects all envelops to be filled out the same way, but FedEx and UPS use another labeling method (although with similar routing attributes). We cannot assume a single transport or exchange, just like all packages currently do not get sent via one mailing service. The we previous challenges we faced within the current healthcare industry was the potential number of possible exchanges (VANs, Clearinghouses, direct connects, etc.). Each of these must be considered as a potential delivery service that has their own exchange (stamps and labeling) methods. Fortunately the EDI/X12 standards requires all players to accept the same exchange format (ISA/IEA). To fulfill the proper analogy with the existing mailing services, I believe the ISA/IEA is more closely associated with the Return Address (Sender) and the Stamp or mailing method (Receiver) - if a problem occurs, the receiver knows where to return the package. The type of package is represented by the GS/GE and ST/SE segments (priority, ground/air, letter, box , etc.) and the final destination address is something evaluated by the receiving party (U.S. Post office) to determine how to route it internally until it can be delivered to it's final destination (transaction level address) so the details of the transaction can ultimately be processed by the receiver of the package. While it is difficult to build a complete correlation between physical mailing vs. electronic mailing of transactions, we cannot ignore the stamps and labels required by the mailing services. Regards, Ronald Bowron
Re: Sender/Receiver Definitions for HIPAA
William, The provider clearinghouse model typically receives proprietary formats and converts them to standard formats, and therefore ISA is not used and a 997 is not generated. What does happen is the user that sent the file has both inbox and outbox (BBS or FTP) for uploading and downloading data based on their user ID they used to connect to the Clearinghouse. The response was typically a proprietary response that feeds into the reporting/mgt system so the user could confirm receipt of each claim/transaction. If a ISA/IEA was sent for parsing into payer specific ISA/IEA, the business policy of the Clearinghouse was that the Sender ID was to be the same (or one to one relation) as the BBS/FTP User ID to avoid any confusion. Regardless of what was put in the ISA, the response was always placed into the BBS/FTP users outbox - this was a business decision to not support alias sender/receiver capability. The reverse is typically true for the Payer Clearinghouse, only the payer receives data in propriety format and responds in proprietary format, and the CH converts it to the Standards. Therefore, again the ISA or 997 has no part to play until the CH sends the ISA/IEA out to it's destination. In response to your example, I agree that an ISP is more like a VAN offering connectivity services, but a VAN may also include store and forward capabilities (file level transfers) between known entities. Very rarely did any of the VAN's we used offer the ability for someone to send anonymously or using an alias as you suggest in your e-mail example. That is why VAN's are still quite popular over the Internet for healthcare business transactions ( it's provides a simplified layer of authentication). IP based e-mail is an application service and it's also possible that the SMTP server is not even owned by the ISP, but by an ASP like Hotmail.com. If the ISP chooses to offer ASP services such as e-mail, then they offer addition value added services beyond connectivity and take on a more active roll in the delivery process. Depending on the sophistication of the services, ISP's providing ASP services could be acting more like a clearinghouse than a VAN, especially if the service involves any type of translation or modification of data. If I were to attempt providing a similar service via the EDI X12N format, I'd suggest the ISA Sender represents the ISP login and the GS is the e-mail Login (application functional group). Then if the routing service so chose to allow the user to submit under an Alias for another, the GS Sender could represent the alias From ID you use in your e-mail example. Of course this assumes the Interchange will provide such flexibility in it's routing and trading partner tables and the trading partners will support it as well. As for having to breakdown the transactions to identify the original transaction owner - I believe that has been defined as beyond the scope of this group. Based on the remainder of your response, are you suggesting that the definitions offered are inappropriate? INTERCHANGE(ISA) SENDER: Entity responsible for preparing the transaction sets (ST/SE) into functional groups (GS/GE) and interchange controls (ISA/IEA) for transmission to the INTERCHANGE RECEIVER and for resolving a functional acknowledgment (997) that contains errors regarding the interchange. INTERCHANGE RECEIVER: Entity responsible for processing the function group and transaction sets (GS/GE, ST/SE) within an interchange control (ISA/IEA) and sending a functional acknowledgment (997) back to the ISA SENDER. Is it your position that the ISA Sender is equivalent to the return address label on the outside of an envelop? (i.e. it's only needed to send back a failed attempt to deliver?) If so, I agree and I believe the ISA Sender definition supports that position. If not, what changes would you recommend to either definition? Regards, Ronald Bowron
Routing Transactions or Interchange Routing?
Is the purpose to resolve routing of Transactions or to know which interchange data was routed? I believe most of the community would like to see the Transaction routing/auditing solved and to be able to verify where the transaction went or where it is. Therefore, the ISA isn't the only vehical to solve ths problem. ISA is simply the equivalent of allowing a user to login to your environment, I don't understand how given the current looping capabilities (multiple transactions from different submitters and too multiple receivers) of the 837, standardizing ISA information would solve anything, unless the only means of transmission was point-to-point - provider to payer (No CH's, Third Part Admins/Repricers, etc.). If routing involves determining that all submitters data was properly routed to the receiver, then routing involves just about any segment that contains a Segment Control Numbers (possibly down to the detail) and ID's representing the TP's (Submitter/Reciever). One purpose of the Control Number I believe was to help manage routing and auditing - should we accomplish getting all the TP's to conform to the the idea of properly managing unique control numbers. The anologie we often used was the routing of a 837 is like shooting a large bullet down a barral that splits it into shotgun pellets. Then, what we wanted to know was if each pellet hit their target. Now imagine 300 people on the same firing range. Unless the target watcher knows what bullet the pellet came from, we'll never know who hit what and route tracking is lost. What makes this worse is when a target takes the pellet and either uses it as a bullet (i.e breaks it into more smaller transactions) or combines it with similar pellets from other guns (combines common claims for sending to a payer). In the end, we had to work with CH's and Payers to accept our Transaction Control Number and use it to forward down the line, or if they generate new numbers, we ask that they provide the cross-ref value so we could track it. This is much like a FedX routing number, but the logistics is more like a distribution channel and warehousing. The elements we identified for our internal tracking were as follows: File Name (because in our modle a file may contain multiple ISA's) ISA Control Number GS Control Number Transaction Control Number Transaction Date Submitter ID Receiver ID (transaction level) I believe we combined Our Sender ID + Submitter ID + Reciver ID + Transaction Date + Transaction Control Number to create a Global Unique Routing Number (GURN) within our data structures and claim status reporting system. Our hope was to have any receiver of the data, echo back our our GURN, letting us know their File, ISA, GS and Transaction Control Numbers. Typically the receiver would very rarely if ever change the Transaction level Submitter/Receiver (NAIC code) data. Then we (and those in between) could build a table from those responses and determine how far the transaction got, and whether it's made it's final destination. We would keep such information on file for as long as the customer or Trading Partner Agreement required. This met with some difficulties, mostly due to the inability to maintian referencial integrity between secondary TP's and the reluctance of TP's to build this capability into thier responses (i.e. Unsolicited 277, or I here theres an 824 and other possible EDI sets like the 242 that could now handle this). Also, if COT's can be transative, why can't TPA's? How do payers handle TPA's with out-of-Network Providers today that wish to submit electronically? Ronald Bowron
