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

Coverage profile seems somewhat wonky

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci HRex (FHIR)
    • current
    • Clinical Interoperability Council
    • HRex Coverage Profile
    • Hide
      1. Coverage.payer becomes 1..1
      1.  

      Coverage.beneficiary changes the target profile from US Core Patient to hrex-patient-demographics which will be based on core patient and will have mandatory, birth date, family name and 1..* given names as well as must support address (with same mustSupport elements as US-core), gender and birth-sex.  Will have an invariant requiring at least one of gender or birth sex.  Will also have a single mustSupport identifier sliced to be a member number that is 0..1.  We will require this be present for the 'new' coverage and be absent for the 'old' coverage

      1.  

      Coverage.identifier becomes 0..1 with Coverage.identifier.value being 1..1, mustSupport

      1.  

      Coverage.class will have a 0..1 mustSupport slice by class.type, where class.type is set to 'group' and value is mandatory mustSupport

      1.  

      We'll add an invariant requiring either identifer.value or subscriberId
      Patient.identifier should be mustSupport, 0..* and should be clear that it's a member number.  Once we've got a unique number for the patient, we're going to want to share it.  Will need to make clear that we expect a member number to be present for the 'new' payer, but not for the 'old' payer patient.  If shared post-member-match (e.g. as part of prior auth or EOB) then identifier would be present

      1. Will add Coverage.dependent as must support
      Show
      Coverage.payer becomes 1..1   Coverage.beneficiary changes the target profile from US Core Patient to hrex-patient-demographics which will be based on core patient and will have mandatory, birth date, family name and 1..* given names as well as must support address (with same mustSupport elements as US-core), gender and birth-sex.  Will have an invariant requiring at least one of gender or birth sex.  Will also have a single mustSupport identifier sliced to be a member number that is 0..1.  We will require this be present for the 'new' coverage and be absent for the 'old' coverage   Coverage.identifier becomes 0..1 with Coverage.identifier.value being 1..1, mustSupport   Coverage.class will have a 0..1 mustSupport slice by class.type, where class.type is set to 'group' and value is mandatory mustSupport   We'll add an invariant requiring either identifer.value or subscriberId Patient.identifier should be mustSupport, 0..* and should be clear that it's a member number.  Once we've got a unique number for the patient, we're going to want to share it.  Will need to make clear that we expect a member number to be present for the 'new' payer, but not for the 'old' payer patient.  If shared post-member-match (e.g. as part of prior auth or EOB) then identifier would be present Will add Coverage.dependent as must support
    • Bob Dieterle / Jay Lyle : 13-0-0
    • Correction
    • Non-compatible
    • Yes

    Description

      Issues:

      1. Coverage.payer is 1...  It's not clear why we'd *ever have more than 1 payer for a single coverage
      2. Coverage.beneficiary is 1..1 and US Core Patient, which it resolves to says Patient.identifier is 1..1.  However, we won't always have an identifier for the beneficiary, sometimes we've only got an identifier for the member
      3. Patient.identifier says that Identifier.system is mandatory, but in general we'll have no clue what the system is for a particular member or subscriber identifier
      4. With beneficiary, we'd be having both Patient.identifier and subscriberId, which presumably would be the same thing.
      5. Insurance cards typically capture the notion of 'Group' so you know what plan is being talked about, but that's supposed to go in Coverage.class.value, and neither class nor value are even mustSupport.
      6. Coverage.identifier is 0..*, with no constraints - it's not clear why there'd ever be more than one, and we need to make clear that .value is mandatory but we might not have the rest

      After talking things over with Bob, my recommendation is as follows:

      Coverage.payer becomes 1..1

      Coverage.beneficiary changes the target profile from US Core Patient to hrex-patient-demographics which will be based on core patient and will have mandatory gender, birth date, family name and 1..* given names as well as must support address (with same mustSupport elements as US-core)

      Coverage.identifier becomes 0..1 with Coverage.identifier.value being 1..1, mustSupport

      Coverage.class will have a (?1..1?) mustSupport slice by class.type, where class.type is set to 'group' and value is mandatory mustSupport

      We'll add an invariant requiring either identifer.value or subscriberId

      Attachments

        Activity

          People

            Unassigned Unassigned
            lloyd Lloyd McKenzie
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: