Skip to content

Conversation

colby-seyferth-nava
Copy link
Contributor

@colby-seyferth-nava colby-seyferth-nava commented Sep 16, 2025

🎫 Ticket

https://jira.cms.gov/browse/BCDA-9415

🛠 Changes

Updated the V3 CapabilityStatement:

  • Add Parameter documentation for _type and _since for both Patient and Group resources
  • update the operation name for patient-export and group-export (change to just "export")
  • Add _typeFilter parameter details for ExplanationOfBenefit _tag (adjudication-level) filtering

ℹ️ Context

Guidance changes in the STU3 veresion of the Bulk Data IG to correct for the operation name. This updates our capabilityStatement to have the correct value for v3.

In addition to updating the operation name, we were also lacking documentation about our supported filtering parameters. Added documentation for _type, _since, _typeFilter, and the _typeFilter subquery: ExplanationOfBenefit._tag parameter

🧪 Validation

Hit the /metadata and confirm the new elements are returned in the CapabilityStatement resource for only the demo/v3 endpoint

v1 and v2 should be unchanged.

unit tests pass

@colby-seyferth-nava colby-seyferth-nava marked this pull request as ready for review September 16, 2025 04:58
@colby-seyferth-nava colby-seyferth-nava requested a review from a team as a code owner September 16, 2025 04:58
SearchParam: []*fhircapabilitystatement.CapabilityStatement_Rest_Resource_SearchParam{
restResourceSearchParam("_since", fhircodes.SearchParamTypeCode_DATE, "Return resources updated after the date provided for existing enrollees and all resources for newly attributed enrollees."),
restResourceSearchParam("_type", fhircodes.SearchParamTypeCode_STRING, "Comma-delimited list of FHIR resource types to include in the export. By default, all supported resource types are returned."),
restResourceSearchParam("_typeFilter", fhircodes.SearchParamTypeCode_STRING, "Use a URL-encoded FHIR subquery to further-refine group export results."),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to validate if the params are properly URL encoded?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ya, good question: we do some validation here:

// validate _typeFilter params

If we do update the validation, I think it'd be in a follow-up / outside the scope of this ticket, which is focused on updates to the CapabilityStatement

{
Type: &fhircapabilitystatement.CapabilityStatement_Rest_Resource_TypeCode{Value: fhircodes.ResourceTypeCode_EXPLANATION_OF_BENEFIT},
SearchParam: []*fhircapabilitystatement.CapabilityStatement_Rest_Resource_SearchParam{
restResourceSearchParam("_tag", fhircodes.SearchParamTypeCode_STRING, "Filter claims by adjudication status: either Adjudicated or PartiallyAdjudicated"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we validate _tag against allowed values ("Adjudicated", "PartiallyAdjudicated")?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the discussion with BCDA and BFD, I think that is going to be the strategy: explicitly checking and validating each parameter before we pass to BFD.

So yes, we should. But it should also be in a follow-up ticket/PR

@bhagatparwinder bhagatparwinder merged commit 9ff4dce into main Sep 22, 2025
6 checks passed
@bhagatparwinder bhagatparwinder deleted the colby/BCDA-9415 branch September 22, 2025 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants