2024-08-13 Postable Remittance Meeting - Da Vinci (2024)

AI Notetakers

Da Vinci values the direct involvement of participants in meetings and provides meeting notes for those who are unable to attend. Recording of calls without permission is not permitted. While Da Vinci and HL7 contemplate further policies about AI technologies, participants are asked to refrain from using AI notetakers on Da Vinci calls. AI notetakers will be dismissed. Da Vinci will continue to seek member and HL7 feedback on this topic.

Save the Date! HL7 September Connectathon, Plenary, and WGM+ (Atlanta, GA)

• Connectathon: Sept 21-22, 2024
  • 2024 - 09 Connectathon 37
• Plenary and WGM+: Sept 23-27, 2024
• Early bird registration available through Aug 30, 2024

September Ballot Cycle: Da Vinci PDex, HRex, and DEQM are included in the September Ballot Cycle

• Consensus group sign up closes Aug 15th
• Voting and commenting occurs Aug 16th - Sept 16th

• Updates to the IG
• Implementer Questions

Postable Remittance CI-Build -http://build.fhir.org/ig/HL7/davinci-pr/

• • Search for Remittance by Claim
  • Search for Remittance by Patient
  • Search for Remittance by Payment
  • Download Remittance

Postable Remittance Technical Specification

Availity Questions:

• Consider adding Payer Name/ID, Patient First and Last Name, Claim Filing Indicator or Claim Frequency Code as optional parameters for claim and patient search

• Add Patient Account Number or Medical Record Number to the patient search instead of Provider-generated claim ID - may help reduce/eliminate additional filtering

• Consider adding Payer Name/ID and Payment Type/Claim Status Code (Processed as Primary, Secondary, etc..) as optional parameters for the payment search

• Recommend using Check Date instead of Payment Date - Payment Date may be misleading and mistaken as date the EFT posted to a bank account

• Want to understand the scenario a user may know the Charge Amount of a specific claim to use in the search

• Account for special characters in the Check/EFT #s

• Consider formatting for No Pay check numbers in the search and workflow - search is inclusive or users have to enter the exact Check/EFT # of NO-PAY-123456

• Add a payer identifier as optional parameter to more easily know where the payment came from, i.e., claim filing indicator or standard payer identifier if available

• • Creation of Supporting Documentation (FAQs)
    • Base 64 coding and zipping, does that alter the transaction?

• • • Privacy/Data Sharing [Permissioning]: When can I share data with others (non-NSG)
    • Payer "owns" the 835 data b/c they originate it. It is up to them to decide who to share with (contractual/business)

• • Electronic transactions/portals/X12 835 HIPAA transaction

• • • Is the FHIR request for a Postable Remit transaction that would be governed under HIPAA.
    • Is FHIR transport wrapper around an EDI transaction not acceptable?
    • Is the use of a wrapper for a duplicate 835 Okay
    • FFS LOB recreation of a copy of a pdf Postable Remit

Questions to Discuss:

1. 1. Are shared TINs allowed to receive a copy of the missing remits via FHIR? Is this permissoning question for the covered entities themselves as they establish API contracts?
   2. Folks are good with sending 835 in FHIR but have a question on whether sending the FHIR transaction with PDF remit is allowed
   3. Some payers send 835s but don't save the 835s. When they send out 835s, they convert the data into PDFs and save them. Given this, there is no way to send a duplicate copy of the 835s in response to a Postable Remit FHIR API request – these payers could send a copy of the PDF remit in FHIR in response to a Postable Remit FHIR API request, but the original remit they sent out was an 835, is responding to the FHIR request with PDF remit allowed?
   4. According to the FHIR specs, the X12 835 file will need to be base64 encoded in the API output. Alternatively, also as a part of the FHIR spec, the x12 835 file can be downloaded via a URL without encoding. However, regardless of using base64 encoding and/or using URL without encoding, we’d like the file to be zipped in case the file size is large. The team doesn’t consider the encoding and zipping a form of “changing” the 835 file, but we think it is probably necessary to give Michael a heads up about the encoding and zipping to make sure CMS/NSG doesn’t have a concern. (It sounds like, today, files are already getting encrypted while getting transferred via HTTPs, so the encoding is not a new concept.)