Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Medium
-
US QI Core (FHIR)
-
4.1.1
-
Clinical Quality Information
-
QICore Service Not Requested
QICore ServiceRequest -
Must Support
-
-
Abdulah Rafiqi/Ben Hamlin 13-0-0
-
Enhancement
-
Non-compatible
Description
QI-Core includes an extension for .statusReason but is is unbound and it is not Must Support. The ServiceNotRequested profile does not reference it, instead referencing the extension doNotPerformReason. The reference to .statusReason extension in QI-Core ServiceRequest seems to be superfluous and should be removed.
Regarding ServiceRequest, the following changes are necessary since US Core 5.0.0 now includes a new US Core ServiceRequest Profile on which the QI-Core profile should be based:
US Core 5.0.0 has a new ServiceRequest Profile. QI-Core ServiceRequest should build off of US Core ServiceRequest:
ServiceRequest.status - Must Support with Required binding to RequestStatus - Same binding as QI-Core 4.1.1
ServiceRequest.intent - Must Support with Required binding to RequestIntent - Same binding as QI-Core 4.1.1
US Core adds Slices for Category because it also accommodates SDOH categories. QI-Core should inherit the same modeling:
Slices for Category Must Support - Codeable Concept with Example binding to ServiceRequestCategoryCodes
And slice category:score Must Support with Required binding to US Core ServiceRequestCategory ----- QI-Core 4.1.1 does not require category. The new ballot should add a Must Support for category as designed in US Core.
ServiceRequest.code Must Support with Extensible binding to USCoreProcedureCode ------ QI-Core 4.1.1 has a preferred binding to the same value set. Update the QI-Core binding to Extensible to match US Core
AND - US Core guidance includes Profile specific implementation guidance:
See the SDOH guidance page for more information when exchanging Social Determinants of Health (SDOH) Service Requests.
The ServiceRequest.category binding must support at a minimum the US Core ServiceRequest Category Codes. However, this valueset can be treated as extensible and other category codes can be used instead.
The ServiceRequest.code valueset is broad to accommodate a wide variety of use cases and should be constrained to a subset for a particular use case or domain. (for example, LOINC for laboratory orders.)
ServiceRequest.subject is Must Support with Must Support reference to US Core Patient ---- This is not changed from QI-Core ServiceRequest.subject (also MS)
ServiceRequest.occurrence[x] has 3 options: ---- QI Core 4.1.1 has MUST Support on Occurrence[x] but does not indicate which of the 3 options or all are Must support) - For QI-Core ALL should have MS flags
occurrencePeriod (Must Support)
occurrenceDateTime (NOT must support)
occurrenceTiming (Not must support)
ServiceRequest.authoredOn Must Support for dateTime, cardinality 1..1 ---- same as QI-Core 4.1.1 - no change
ServiceRequest.requester Must Support with references (Practitioner - MS, Organization - not MS, Patient - not MS, PractitionerRole - not MS, RelatedPerson - Not MS, Device - Not MS) ----- QI-Core 4.1.1 does not include MS on ServiceRequest.requester - Add MS on ServiceRequest.requester and MS on Practitioner.
Attachments
Issue Links
- relates to
-
FHIR-35100 ServiceRequest.statusReason is not bound to a value set yet it is an extension added for use by QI Core
-
- Published
-