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

focus CRD Appointment profile on anticipated usage

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci CRD (FHIR)
    • 2.0.1
    • Financial Mgmt
    • CRD Appointment
    • Hide

      We will split the 'Appointment' profile into two: Appointment with order and Appointment without order.

      The current profile will be the one "without order" and will set basedOn(CRDServiceRequest) 0..0.

      For the "with order" profile, will make basedOn 1..*.  Will drop coverageInformation, identifier, serviceCategory, serviceType, specialty, appointmentType, reasonReference from being mustSupport.

      In both profiles, will loosen cardinality on requestedPeriod and start and end, but add an invariant saying you must have either 'start + end' or must have at least one requestedPeriod with a start and end.

      Will drop FMM from 2 to 1 for both.

      Show
      We will split the 'Appointment' profile into two: Appointment with order and Appointment without order. The current profile will be the one "without order" and will set basedOn(CRDServiceRequest) 0..0. For the "with order" profile, will make basedOn 1..*.  Will drop coverageInformation, identifier, serviceCategory, serviceType, specialty, appointmentType, reasonReference from being mustSupport. In both profiles, will loosen cardinality on requestedPeriod and start and end, but add an invariant saying you must have either 'start + end' or must have at least one requestedPeriod with a start and end. Will drop FMM from 2 to 1 for both.
    • Enhancement
    • Compatible, substantive

    Description

      The CRD Appointment profile has several Must Support elements that are tied to example or preferred bindings that are not likely to be consistently populated by providers or used by payers.

      On previous calls when I've asked payers if any of them anticipate support for returning coverage guidance on an appointment-book CRD that only has elements from Appointment, none have responded. Instead, the industry seems to be focused around looking to Appointment.basedOn to grab the associated ServiceRequest and return coverage guidance on that using the Appointment's start, end, and participants as required context.

       

      To make this profile closer to how people want to use it, we should:

      • Remove the must support from elements we don't anticipate being used: coverage-information, identifier, serviceCategory, serviceType, specialty, appointmentType, reasonReference
      • Add must support to basedOn
      • Change the cardinality on start from 1..1 to 0..1, end from 1..1 to 0..1, and requestedPeriod from 1..1 to 0..*, and state that either start or requestedPeriod must be populated (a workflow normally wouldn't populate both like the profile currently requires).
      • Update the CRD Appointment profile's maturity from 2 to 1, as I haven't seen anyone test it at connectathon.

      Attachments

        Activity

          People

            Unassigned Unassigned
            kjohnsen Kyle Johnsen
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: