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

Compiled comments on Search from Zulip

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Triaged (View Workflow)
    • Priority: Medium
    • Resolution: Persuasive with Modification
    • Specification:
      US CARIN Blue Button (FHIR)
    • Raised in Version:
      0.1
    • Work Group:
      Financial Mgmt
    • Related Page(s):
      (profiles)
    • Grouping:
    • Resolution Description:
      Hide

       

      A pull down named Search Capabilities under a tab, FHIR Artifacts, will be defined.  It will include the following:

      The EOB Resource is the focal Consumer-Directed Payer Data Exchange (CDPDE) Resource.  Several Reference Resources are defined directly/indirectly from the EOB:  Coverage, Patient, Organization (Payer), Practioner, Organization (Facility), PractionerRole, Location. 

       

      The Coverage Reference Resource SHALL be returned with data that was effective as of the date of service of the claim; for example, the data will reflect the employer name in effect at that time.  However, for other reference resources, payers MAY decide to provide either the data that was in effect as of the date of service or the current data*.*  All reference resources within the EOB will have meta.lastUpdated flagged as must support.  Payers SHALL provide the last time the data was updated or the date of creation in the payers system of record, whichever comes last.  Apps will use the meta.lastUpdated values to determine if the reference resources are as of the current date or date of service.

      When an EOB references another resource (e.g., Patient or Practitioner), the reference may be versioned or versionless. Payers SHALL use versioned references whenever they maintain point-in-time data (data that was effective as of the date of service or date of admission on the claim), but MAY use versionless references when they do not maintain versioned data. Clients MAY request referenced resources as part of an EOB search (by supplying the _include parameter) or directly using read or vread. Payers SHALL support both approaches, and SHALL return the same content for referenced resources in either case.

       

      Resource Type Supported Profiles The server SHALL support the following search parameters _includes
      (SHALL)
      Supported Operations
      (SHALL)
      ExplanationOfBenefit ●      CARIN BB ExplanationOfBenefit Profile;
      ●      CARIN BB ExplanationOfBenefit Inpatient Facility Profile;
      ●      CARIN BB ExplanationOfBenefit Outpatient Facility Profile; 
      ●      CARIN BB ExplanationOfBenefit Pharmacy Profile
      ●      CARIN BB ExplanationOfBenefit Professional NonClinician Profile 
      Required search parameters:
      ●      _id,
      ●      patient,
      ●      _lastUpdated*
      ●      type (Claim Type)**
      ●      identifier (Business / Claim Identifier of EOB
      ●      service-date***
       
       
         
       
       
      Coverage CARIN BB Coverage Profile     read
      Conditional: vread
      Patient CARIN BB Patient Profile     read
      Conditional: vread    
      Organization CARIN BB Organization Profile        read
      Conditional: vread
      PractitionerRole CARIN BB  PractitionerRole Profile        read
      Conditional: vread
      Practitioner CARIN BB  Practitioner Profile        read
      Conditional: vread
      Location CARIN BB Location Profile        read
      Conditional: vread

       

      *_lastUpdated

       A new logical CPCDS new data element, EOBLastUpdated,that defines the date the EOB was created or updated, whichever is later will be defined. The payer could choose how they want to map it to this CPCDS element. Map to meta.lastUpdated.  Cardinality is 1..1. Search parameter uses the logical EOBLastUpdated field. 

       **type

      A search parameter will be defined:  "name": "type", "type": "token", "description": "The category of claim", "expression": "ExplanationOfBenefit.type"

       ***service-date

      The goal of service-date is to simplify the search, so that a client doesn't need to know that for inpatient and outpatient institutional EOB dates they need to search by billablePeriod.period.start, for a pharmacy EOB by servicedDate, and for a professional and non-clinician EOB - by servicedPeriod.period.start. Change the cardinality of these data elements to 1..1. 

       

      search by service-date definition: 

       "expression": "ExplanationOfBenefit.billablePeriod | ExplanationOfBenefit.serviced as Date |  ExplanationOfBenefit.serviced as Period",

       "xpath": "f:ExplanationOfBenefit/f:billablePeriod | f:ExplanationOfBenefit/f:serviced/f:servicedDate | f:ExplanationOfBenefit/f:serviced/f:servicedPeriod"

       

      Show
        A pull down named Search Capabilities under a tab, FHIR Artifacts, will be defined.  It will include the following: The EOB Resource is the focal Consumer-Directed Payer Data Exchange (CDPDE) Resource.  Several Reference Resources are defined directly/indirectly from the EOB:  Coverage, Patient, Organization (Payer), Practioner, Organization (Facility), PractionerRole, Location.    The Coverage Reference Resource SHALL be returned with data that was effective as of the date of service of the claim; for example, the data will reflect the employer name in effect at that time.  However, for other reference resources, payers MAY decide to provide either the data that was in effect as of the date of service or the current data*.*  All reference resources within the EOB will have meta.lastUpdated flagged as must support.  Payers SHALL provide the last time the data was updated or the date of creation in the payers system of record, whichever comes last.  Apps will use the meta.lastUpdated values to determine if the reference resources are as of the current date or date of service. When an EOB references another resource (e.g., Patient or Practitioner), the reference may be versioned or versionless. Payers SHALL use versioned references whenever they maintain point-in-time data (data that was effective as of the date of service or date of admission on the claim), but MAY use versionless references when they do not maintain versioned data. Clients MAY request referenced resources as part of an EOB search (by supplying the _include parameter) or directly using read or vread. Payers SHALL support both approaches, and SHALL return the same content for referenced resources in either case.   Resource Type Supported Profiles The server SHALL support the following search parameters _includes (SHALL) Supported Operations (SHALL) ExplanationOfBenefit ●      CARIN BB ExplanationOfBenefit Profile ; ●      CARIN BB ExplanationOfBenefit Inpatient Facility Profile ; ●      CARIN BB ExplanationOfBenefit Outpatient Facility Profile;  ●      CARIN BB ExplanationOfBenefit Pharmacy Profile ;  ●      CARIN BB ExplanationOfBenefit Professional NonClinician Profile   Required search parameters: ●      _id, ●      patient, ●      _lastUpdated* ●      type (Claim Type)** ●      identifier (Business / Claim Identifier of EOB ●      service-date***             Coverage CARIN BB Coverage Profile     read Conditional: vread Patient CARIN BB Patient Profile     read Conditional: vread     Organization CARIN BB Organization Profile        read Conditional: vread PractitionerRole CARIN BB  PractitionerRole Profile        read Conditional: vread Practitioner CARIN BB  Practitioner Profile        read Conditional: vread Location CARIN BB Location Profile        read Conditional: vread   *_lastUpdated  A new logical CPCDS new data element, EOBLastUpdated,that defines the date the EOB was created or updated, whichever is later will be defined. The payer could choose how they want to map it to this CPCDS element. Map to meta.lastUpdated.  Cardinality is 1..1. Search parameter uses the logical EOBLastUpdated field.   **type A search parameter will be defined:  "name": "type", "type": "token", "description": "The category of claim", "expression": "ExplanationOfBenefit.type"  ***service-date The goal of service-date is to simplify the search, so that a client doesn't need to know that for inpatient and outpatient institutional EOB dates they need to search by billablePeriod.period.start, for a pharmacy EOB by servicedDate, and for a professional and non-clinician EOB - by servicedPeriod.period.start. Change the cardinality of these data elements to 1..1.    search by service-date definition:   "expression": "ExplanationOfBenefit.billablePeriod | ExplanationOfBenefit.serviced as Date |  ExplanationOfBenefit.serviced as Period",  "xpath": "f:ExplanationOfBenefit/f:billablePeriod | f:ExplanationOfBenefit/f:serviced/f:servicedDate | f:ExplanationOfBenefit/f:serviced/f:servicedPeriod"  
    • Change Category:
      Correction
    • Change Impact:
      Compatible, substantive

      Description

      Changes which seemed to have consensus: 

      eob-date -> service-date

      Also a clarifying note about _lastUpdated

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              mark_roberts Mark Roberts
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: