-
Type:
Change Request
-
Resolution: Persuasive with Modification
-
Priority:
Medium
-
US Da Vinci DTR (FHIR)
-
STU3
-
Financial Mgmt
-
(profiles) [deprecated]
-
2.2 - Relation to Co
-
-
Bob Dieterle / Larry Decelles: 16-0-3
-
Enhancement
-
Non-substantive
Proposed Wording: The paragraph contained in this section is an excellent example of how various FHIR IGs and Artifacts (not just CRD) work together in a use case - including DTR, CRD, CQL, CDS Hooks, and SMART.
I suggest changing the title of this section to something like "Example of Workflow and Interaction Between Various FHIR IGs Related to Coverage, Documentation Requirements and Payer Rules" (original text: "DTR differs from CRD mostly in its ability to run rules and auto fill forms and templates. The CRD portion of the full workflow might be responsible for verifying with the payer that a given device request requires documentation, and then consolidating the necessary links for the DTR app to be run. In most cases, the CRD application would return a CDS hooks card populated with a SMART launch link for the DTR app, a link to a questionnaire resource, and a device request resource ID. While CRD may verify that documentation rules are required, it does not involve any actual authorization or validation of the rule. The DTR app is responsible for taking the provided rule and checking if available EHR data satisfies the requirements, as well as allowing manual population of missing data.
Summary:
I suggest changing the title of this section to something like "Example of Workflow and Interaction Between Various FHIR IGs Related to Coverage, Documentation Requirements and Payer Rules"
- is voted on by
-
BALLOT-10484 Affirmative - Walter Suarez : 2019-Sep-FHIR IG DTR R1
- Closed