Details
-
Change Request
-
Resolution: Persuasive
-
Medium
-
US Da Vinci DTR (FHIR)
-
1.0.0 [deprecated]
-
Clinical Decision Support
-
Formal Specification
-
-
Bob Dieterle / Jeff Brown : 12-0-2
-
Clarification
-
Non-substantive
Description
The formal specification page seems like a table of contents page, not an actual specification. It also has way too many child pages. (The 'Expectations of Application Behavior' is just a table of contents an needs to be eliminated.)
We don't want implementers to have to click around like crazy to find or search for content. Most content describing the spec should be on a single page, while having sub-pages for a few detailed items.
Finally, the content of the page isn't even defined in a logical order. The first thing a user who's trying to understand "How do I implement DTR?" definitely isn't a 'profiles' page.
The base page should describe the technical workflow:
- Optional SMART-app launch (with sub-guidance for launching from CDS Hooks, direct launch, or direct launch to resume a previous session)
- Retrieval of the relevant Questionnaire(s) using the operation - and retrieval of associated ValueSets and/or Libraries
- Use of the $next-question operation (if necessary)
- Rules around Questionnaire construction (profile on SDC), including embedding CQL
- Rules around data retrieval using CQL
- Data storage of work-in-progress on either EHR or payer system, including how resumption of work in progress will function.
- Data storage of completed forms on EHR (as QR or DocumentReference), including relevant extensions and how the EHR understands what they're to be used for.
Attachments
Issue Links
- mentioned in
-
Page Loading...