care-gaps non-document mode

[Capt-Mac]

Description

The issue with the "document" structure of the 'care-gaps' service is that the level of detail isn't always required for every use case of the operation. There are use cases where a user just needs to know who has a specific "gap-status" and have minimal evidence support of a 'Measure Report' resource that determined the "gap" state for the subject.

This ticket is to propose that we introduce a "non-document" mode of "care-gaps" service that allows for minimal response structure for downstream use cases of the service that don't need the large amount of detail.

The current response body of the operation into Parameters resource:

• Parameter
• • Bundle -> 1 Per-Subject
• • • BundleEntries
• • • • Composition
• • • • DetectedIssue(s) -> 1 per Measure
• • • • MeasureReport(s) -> 1 per Measure
• • • • EvaluatedResources -> Many Resources from MeasureReport.evaluatedResource values
• • • • Section Author Resource (Organization)
• • • • Reporter Resource (Organization)

Proposed Solution

Update the 'care-gaps' operation to have an additional optional parameter that controls whether the service returns "non-document" response structure or "document" response structure. The parameter would be "isDocumentMode", which would default to "true" to return current 'document' structure unless requested otherwise, so not to interrupt current users of operation.

I also propose that with this "non-document" mode we add additional context to the "detectedIssue" to surface metaData that would make it more useful for downstream processes to identify Measure related care-gaps. Current Detected Issue does not provide enough detail here and requires the Measure Report resource to surface.

• (MeasureReport.period->DetectedIssue.identifiedPeriod): this indicates that the Measure 'Detected Issue' is relevant to the 'measurement period' of the Measure Report and doesn't necessarily indicate relevance outside of that period.
• (Measure.id ->DetectedIssue.implicated): this exposes the resource that identified the 'DetectedIssue', exposing this will allow for any persisted 'DetectedIssue' resources to be searchable by related Measure resource.

Contain 'Measure Report' resource in 'Detected Issue' instead of two separate resources to minimize qty of resources that would require persistence. This allows for an all in one resource to identify 'care-gap' status and evidence for why they have that status.

• (Measure Report -> DetectedIssue.contained): this will contain the entire Measure Report resource within the 'Detected Issue'
• (DetectedIssue.contained.MeasureReport.id -> DetectedIssue.evidence.detail): this would place a '#' prefixed reference to the contained 'Measure Report' resource.

New structure would look like:

• Parameter
• • Bundle -> 1 Per-Subject
• • • BundleEntries
• • • • DetectedIssue(s) -> 1 per Measure