Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-36167

Meet regulatory requirements more narrowly, don't model FHIR after x12

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Medium Medium
    • US Da Vinci PAS (FHIR)
    • 1.1.0
    • Financial Mgmt
    • Formal Specification
    • Hide

      The intent of this implementation guide is to meet the HIPAA requirement to use the X12 278 (217) as syntax and semantics to request a prior authorization and return the response. Until this regulation changes PAS must be capable of supporting this requirement.

      See Section 2.1

      As well, the profiles have, via resolutions on other tickets, been loosened a bit so that the X12 limitations on cardinality, as an example, are not embedded in the profiles.  We still have the requirement to package the required data elements for X12, but we have tried our best to make the profiles more usable for the exception process.

      Show
      The intent of this implementation guide is to meet the HIPAA requirement to use the X12 278 (217) as syntax and semantics to request a prior authorization and return the response. Until this regulation changes PAS must be capable of supporting this requirement. See Section 2.1 As well, the profiles have, via resolutions on other tickets, been loosened a bit so that the X12 limitations on cardinality, as an example, are not embedded in the profiles.  We still have the requirement to package the required data elements for X12, but we have tried our best to make the profiles more usable for the exception process.
    • Bob Dieterle/Mary Kay McDaniel: 10-1-1

    Description

      It's evident that the requirement to conform the PAS Claim and ClaimResponse profiles to X12 significantly complicates and confuses the PAS data model, while also not only failing to simplify the interoperability exchange to the elements required, but also carries forward undesirable aspects from X12.

      This is too important to get wrong. You're re-creating X12 in json.

      The spec clearly and expertly defines the requirements for the use of X12, and describes some mechanisms for working around this requirement, while also pointing to a future without X12 via the current CMS exception.

      I propose that the current guide fails to narrowly target the specific X12 requirement, and further, if/when the X12 requirement is lifted, any PAS integrations will still be tied to X12 due to this guide's current data modeling approach. In short, you're defining the long-term data model based upon the short-term, transitory needs. 

      Since only the "ASC X12N/005010X217 - Health Care Services Review - Request for Review and Response (278)" is actually required, you should use simple FHIR to both transport additional information and to inquire after a request. The 278 request should be simple, and trivial with primarily only a reference to the forthcoming PAS Request Bundle. The PAS Request Bundle should not be modeled after X12, and should not be transformed to X12. Both the provider and the payer should be capable of understanding the PAS FHIR.

      Such an approach would enable much needed simplification of the Claim and ClaimResponse resources, and would allow us to not carry forward X12 complexity and mistakes.

      Attachments

        Activity

          People

            Unassigned Unassigned
            Isaac.Vetter Isaac Vetter
            Andrew Barbieri, Rachael McCormick (Inactive)
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: