Proposal

Expand the options on how to provide a reason for the procedure based on practical implementations by allowing the reason for a Procedure to be captured according to one of the following:

·        Procedure.reasonCode

·        Procudure.reasonReference

·        Procedure.basedOn(CarePlan)

·        Procedure.basedOn(ServiceRequest) __ w/ ServiceRequest.reasonCode or reasonReference

·        Proceudre.encounter(Encounter) __ w/ Encounter.reasonCode or reasonReference

The options include reasons that apply to the procedures performed directly, based on/as a result of (CarePlan and ServiceRequests) or part of (Encounter) the resource referenced

A particular type of procedure may use only one of these, or various, e.g., surgery procedures would typically be rationalized by the Encounter during which they are performed and the Procedure’s reason attributes, but in various settings and configurations never by a ServiceRequest.  SDOH interventions, as they need to be specifically ordered first would typically be rationalized by the ServiceRequest.  I.e., it should not be required that any procedure supports all methods of providing a reason, rather just the one or ones that make sense for that type of procedure.  Particularly, requiring any procedure to have been preceded by ServiceRequest, which encompasses more than just a reason for the procedure, is for a number of procedures not appropriate.

We suggest that this be part of an interim 6.2.0 update to clearly indicate that this is specific to USCDI v3, as it focuses on the addition of Reason of Referral in USCDI v3, thus can be more easily eligible to be used to certify to USCDI v3.  If it were to be put together with 7.0.0 in support of USCDI v4 there should be clarity that this can be “pre-adopted”, thus not requiring to immediately support all of FHIR US Core 7.0.0 that would fully support USCDI v4.

Background

When starting to validate our procedures using Inferno based on USCDI v3 we noticed that Procedure.basedOn(ServiceRequest) had to be demonstrated for any procedure, not just SDOH interventions.  This did not align with our understanding, particularly considering:

·        USCDI v3 defines the Reason of Referral to be scoped to referrals and consultations, yet it is documented under Procedure implying the intent is to be the reason for the procedure.  In many implementations a referral and consultation would be considered a type of encounter or appointment during which one or more procedures may occur, but not the procedure itself.  A request by the HITAC to clarify that the Reason of Referral should be clarified. Without that clarification and conflicting perspectives, the data element would seemingly be an attribute of the Procedure, not another data class that typically represents and encounter or vitis.

·        Not all “procedures” as HL7 defines them are necessarily exposed __ as Procedures as they may actually result in notes, observations, diagnostic reports, and/or documents including these and other data in clinical documentation, while they would appear as CPT encoded charges only for financial purposes.  Providers would not expect either of these, and accordingly have their systems configured to not appear as FHIR Procedures.

·        Many “procedures” are also never ordered using FHIR ServiceRequest as a documented first step, rather they may just be performed.  For example, surgical procedures would not have a ServiceRequest present at all times or ever.

A reason for the Procedure can therefore not be assumed to be available for any procedure using ServiceRequest, but would have been documented in other places such as on the Procedure directly (.reasonCode or reasonReference), or indirectly through the Encounter during which it as performed.