Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Medium
-
US Da Vinci CRD (FHIR)
-
2.0.1
-
Financial Mgmt
-
CRD Appointment
-
-
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
Issue Links
- mentioned in
-
Page Loading...