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

Define RelatedPerson Profile

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci Patient Cost Transparency (PCT) (FHIR)
    • 0.1.0 [deprecated]
    • Financial Mgmt
    • STU
    • (NA)
    • 7.0.2
    • Hide

      Based on research, there are variations on the resources used to define subscriber through FHIR IGs. In PCT, we intend to leave subscriber as US Core Patient to remain compliant with Da Vinci HRex for STU1 unless there is a compelling reason not to at this time.

      Will remove MS from Coverage.subscriber, defaulting to what is in HRex, since all that is needed is subscriberId. 

      Note that the definition of Patient includes "other health-related services" as being in scope, and being a subscriber fits that scope. 

      Also, since it is unlikely that DOB and gender info will be available for the subscriber when not the patient, will add guidance to omit Patient.birthDate (it is 0..1 in US Core Patient and ok to omit when not available) and to use the code "unknown" for Patient.gender and document that the receiving system should not use that code for subscriber matching purposes (if unknown, don't try to match on gender). 

      Show
      Based on research, there are variations on the resources used to define subscriber through FHIR IGs. In PCT, we intend to leave subscriber as US Core Patient to remain compliant with Da Vinci HRex for STU1 unless there is a compelling reason not to at this time. Will remove MS from Coverage.subscriber, defaulting to what is in HRex, since all that is needed is subscriberId.  Note that the definition of Patient includes "other health-related services" as being in scope, and being a subscriber fits that scope.  Also, since it is unlikely that DOB and gender info will be available for the subscriber when not the patient, will add guidance to omit Patient.birthDate (it is 0..1 in US Core Patient and ok to omit when not available) and to use the code "unknown" for Patient.gender and document that the receiving system should not use that code for subscriber matching purposes (if unknown, don't try to match on gender). 
    • Rick Geimer/Mark Scrimshire : 9-0-1
    • Clarification
    • Non-substantive

    Description

      The GFE data element list defines subscriber fields.  These are to be provided when the patient is not the subscriber.  Define a RelatedPerson Resource for these elements.

      Attachments

        Activity

          People

            Unassigned Unassigned
            taylorpatriciab Patricia Taylor
            Patricia Taylor
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: