Updates healthcare shared components

[brendankowitz]

Description

This pull request migrates the project from using the MediatR library to the Medino library for in-process messaging and notifications. All usages, references, and documentation have been updated accordingly. Additionally, the minimum version of the shared healthcare package has been updated. The most significant changes are summarized below.

Dependency and Package Management:

• Replaced the MediatR NuGet package with Medino in all project and props files, and updated the shared healthcare package version from 10.0.68 to 11.0.3. (Directory.Packages.props [1] [2]; src/Microsoft.Health.Fhir.Api/Microsoft.Health.Fhir.Api.csproj [3]

• Updated third-party notices to reflect the switch from MediatR 9.0.0 to Medino 3.0.2. (THIRDPARTYNOTICES.md THIRDPARTYNOTICES.mdL542-R543)

Codebase Migration to Medino:

• Replaced all using MediatR; statements with using Medino; across the codebase and tests. (src/Microsoft.Health.Fhir.Api/Features/ApiNotifications/ApiNotificationMiddleware.cs [1] src/Microsoft.Health.Fhir.Api/Features/BackgroundJobService/HostingBackgroundService.cs [2] src/Microsoft.Health.Fhir.Api/Features/ExceptionNotifications/ExceptionNotificationMiddleware.cs [3] src/Microsoft.Health.Fhir.Api/Features/Health/ImproperBehaviorHealthCheck.cs [4] src/Microsoft.Health.Fhir.Api/Features/Health/StorageInitializedHealthCheck.cs [5] src/Microsoft.Health.Fhir.Core.UnitTests/Features/Operations/BulkDelete/BulkDeleteProcessingJobTests.cs [6] src/Microsoft.Health.Fhir.Core.UnitTests/Features/Operations/BulkUpdate/BulkUpdateProcessingJobTests.cs [7] src/Microsoft.Health.Fhir.Core.UnitTests/Features/Operations/Export/CancelExportRequestHandlerTests.cs [8]

• Updated all code and tests to use PublishAsync instead of Publish for publishing notifications with the Medino mediator. (src/Microsoft.Health.Fhir.Api/Features/ApiNotifications/ApiNotificationMiddleware.cs [1] src/Microsoft.Health.Fhir.Api/Features/ExceptionNotifications/ExceptionNotificationMiddleware.cs [2] src/Microsoft.Health.Fhir.Core.UnitTests/Features/Operations/BulkUpdate/BulkUpdateProcessingJobTests.cs [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]

Documentation and Comments:

• Updated all class and method documentation to reference Medino instead of MediatR. (src/Microsoft.Health.Fhir.Api/Features/ApiNotifications/ApiResponseNotification.cs [1] src/Microsoft.Health.Fhir.Api/Features/ExceptionNotifications/ExceptionNotification.cs [2]

Related issues

Addresses [issue #].

Testing

Describe how this change was tested.

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• When changing or adding behavior, if your code modifies the system design or changes design assumptions, please create and include an ADR.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)

In general, the fix for a "useless upcast" is to remove the explicit cast and let the compiler apply the implicit conversion. This keeps the code simpler without affecting functionality.

Here, on line 492, we have resources.AddRange(((IEnumerable<Patient>)patients).Reverse());. The explicit cast to IEnumerable<Patient> is unnecessary because patients is a Patient[], which already implements IEnumerable<Patient>, and Reverse() is an extension method on IEnumerable<T>. The best minimal fix is to remove the cast and call Reverse() directly on patients, relying on type inference and implicit conversion. No additional imports or helper methods are needed, and existing behavior (adding the reversed patient sequence to resources) remains identical.

Concretely:

• In test/Microsoft.Health.Fhir.Shared.Tests.E2E/Rest/Search/SortTests.cs, locate the resources.AddRange(((IEnumerable<Patient>)patients).Reverse()); line.
• Replace it with resources.AddRange(patients.Reverse());.
• No other code or imports need to be changed.

To fix a useless upcast, remove the explicit cast and rely on the existing implicit conversion. Here, patients is a Patient[], which already implements IEnumerable<Patient>. List<Resource>.AddRange takes IEnumerable<Resource>, and because Patient derives from Resource, the array can be used directly without any cast.

The specific change is in test/Microsoft.Health.Fhir.Shared.Tests.E2E/Rest/Search/SortTests.cs at line 564. Replace:

resources.AddRange(((IEnumerable<Patient>)patients).Reverse());

with:

resources.AddRange(patients.Reverse());

No additional methods, imports, or definitions are needed. The behavior remains the same: patients is enumerated in reverse order and each Patient (a Resource) is added to the resources list.

To fix this issue, we should remove the useless assignment to the local variable response. We want to preserve the await of the asynchronous method to ensure program logic and timing remains unchanged. Thus, instead of assigning to a variable, we should simply await the operation on its own. All remaining code is unchanged, since none relies on the value assigned to response. Edits are needed for both of the affected methods in the file: remove the assignment and just await the method call.

The best fix is very simple: remove the assignment of the result of _createExportRequestHandler.HandleAsync to the unused local variable response. Instead, simply await the method directly (without capturing its result), preserving proper sequencing and exception propagation, but eliminating unnecessary unused assignment. Only the assignment line itself (CreateExportResponse response = await ...) needs to be replaced with an awaited call without the variable and type declaration. No additional imports, methods, or definitions are needed.

To fix the problem, you should remove the assignment to the variable response while retaining the awaited call to _createExportRequestHandler.HandleAsync(...), in order to preserve any expected side effects or exceptions that may result from calling it. Specifically, in file test/Microsoft.Health.Fhir.Shared.Tests.Integration/Features/Operations/Export/CreateExportRequestHandlerTests.cs, in method GivenARequestWithFilters_WhenConverted_ThenTheFiltersArePopulated, replace:

CreateExportResponse response = await _createExportRequestHandler.HandleAsync(request, _cancellationToken);

with:

await _createExportRequestHandler.HandleAsync(request, _cancellationToken);

No additional imports, methods, or definitions are required.

---

To fix the problem, remove the unnecessary assignment to the local variable while still invoking _createReindexRequestHandler.HandleAsync(request, CancellationToken.None) so the test continues to exercise the code path and potentially throw exceptions. Since the test only cares that an exception is thrown (and the associated errorMessage), there is no need to capture the return value at all.

Concretely, in test/Microsoft.Health.Fhir.Shared.Tests.Integration/Features/Operations/Reindex/ReindexJobTests.cs, within the GivenOutOfRangeReindexParameter_WhenCreatingAReindexJob_ThenExceptionShouldBeThrown method, replace the line:

CreateReindexResponse response = await _createReindexRequestHandler.HandleAsync(request, CancellationToken.None);

with a statement that simply awaits the task:

await _createReindexRequestHandler.HandleAsync(request, CancellationToken.None);

No additional imports, methods, or definitions are required, and existing functionality is preserved because the method is still executed and any thrown exceptions are still caught and asserted.

[brendankowitz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).