To switch using samples/templates/default-azuredeploy.json in the PR CI pipeline, we must publish that template in the deploy build artifact.

We do not have a proper logging sink for a default deployment.

This will no longer be needed.

The documentation for creating AAD registrations is currently embedded in the deployment instructions. It should be split out in a separate markdown file (referenced from the deployment instructions). There should also be instructions for Azure CLI.

Currently the /health/check endpoint returns the message, "Successfully connected to CosmosDB." We should not expose the backend technology used for data storage.

Going to the following URL in a browser causes them to not display the actual operation outcome. Seems to behave in Postman

http://localhost:53727/metadata?throw=internal&_format=xml

We need a command line script for AAD registrations using Azure CLI

Each API we should honor the permission based on the role of the user is in.

Acceptance:

• Verify user can perform CRUD operation on resources that their role has access to.
• Verify user cannot perform CRUD operation on any resources that their role does not have access to.

There should be links to the deployment instructions from the main README. The deployment instructions should be broken into basic template deployment instructions and links to instructions for AAD app registrations (both PowerShell and Azure CLI).

Current default-azuredeploy.json should only deploy source code when a repo URL and branch name is supplied.

The following operations are considered writes: Create, Update, Delete

A write should be limited given the permissions such that it will succeed if:
Update: The filter for the permission would match the new resource and the existing resource
Create: The new resource matches the filter
Delete: The existing resource matches the filter

NOTE: There is an issue with data leakage when an update is attempted and the user doesn't have permission to read the existing resource. If the user knows the policies in force and crafts the resource in such a way that the new one would be allowed, they could determine if the existing resource contains filtered data

Acceptance:

• A user can update an existing resource when the new and old resource both match the filter
• A user cannot update an existing resource when the new resource doesn't match the filter
• A user cannot update an existing resource when the old resource doesn't match the filter
• A user can create a resource if the resource matches the filter
• A user cannot create a resource if the resource doesn't match the filter
• A user can delete a resource if the resource matches the filter
• A user cannot delete a resource if the resource doesn't match the filter

When invalid Content-Type is supplied ("ContentType: application/json+fhir), the call fails with empty OperationOutcome.

It should contain valid OperationOutcome explaining why the call has failed.

Enable search capability on reference search parameters with [parameter]=[id] and [parameter]=[url].

http://hl7.org/fhir/search.html#reference

Example:

{
resourceType: "Observation",

...// Stuff

subject: {
    "reference": "Patient/1234"
}
...// Stuff

}

These should work (and are currently supported by HAPI):

GET https://my-fhir-server/Observation?subject=1234
GET https://my-fhir-server/Observation?subject=Patient/1234

Acceptance:

• Verify that search using [parameter]=[id] works correctly.
• Verify that search using [parameter]=[type]/[id] works correctly.
• Verify that search using [parameter]=[url] works correctly against resource which contains full or relative URLs.

Compartment should be indexed on documents as they are stored. The current 5 compartments are documented here:
https://www.hl7.org/fhir/compartmentdefinition.html

This does not include re-indexing existing data.

Acceptance:

• Verify additional index is created for document to support efficient compartment search.

Add the following blood pressure Observation to a new FHIR server:
https://www.hl7.org/fhir/observation-example-bloodpressure.json
The systolic component is 107 and diastolic component is 60.
How if I do this search:
http://localhost:53727/Observation?component-code-value-quantity=http://loinc.org|8480-6$lt107
I expect to not get any results, because it is searching for systolic values less than 107. Instead, it returns the resource, because it is matching on the diastolic component.

Move code snippet from Markdown file to standalone script.

This is a test-only middleware component that pollutes the codebase and config. Replace with an E2E test that customizes the middleware pipeline.

We need to support reference search with resource type specified as modifier.

GET [base]/Observation?subject:Patient=23

Read APIs (read, vread, search) should honor the permissions based on the role the user is in.

Acceptance:

• A user can only read resources that match the permission filters for their roles
• A user is unable to read a resource that doesn't match the permission filter.

Current naming of Authorization parameters is Security:Authentication:*, e.g. Security:Authentication:Mode, etc. It may make sense to rename to Security:Authorization:*

Currently, we are using open source IdentityServer in the FHIR server project so that we can run local integration tests. Since our main goal is to support AAD, we need to evaluate and see if we want to take the hard dependency on AAD (in which case, we might need scripts and what not to be able to setup application for convenience) or if we want to continue support IdentityServer as well as AAD (in which case, we will have to create generic interfaces to abstract some of the difference between the two).

Acceptance:

• Review the finding and the recommendation with the rest of the team.

There are some common properties used by all project now. Simplify the csproj file by using props file to share some of these settings.

• The current Microsoft.Health.Fhir.Web project should really called something like Microsoft.Health.Fhir.SampleServer.
• The module approach for service configuration taken in the project is not the standard practice in asp.net core and has too much code that would need to be updated/modified for different environments. Instead, the project should be really lean with code like:

services.AddFhir().AddCosmosDB().AddAuthrorization(...);

1. The order of members is not deterministic, potentially leading to the output file marked being as modified in a developer's local repo.
2. #73 exposed erratic behavior, stemming from the fact that the CSharpCompilation could most system types.

A hard delete can only occur if the filter matches the existing resource.

Acceptance:

• A user can hard delete a resource if the resource matches the filter
• A user cannot hard delete a resource if the resource doesn't match the filter

Right now, the parallel execution is disabled because search test needs to setup the data (by deleting known resources first). This is invasive since it's deleting all Patients or all Observation resources and requires the tests to be executed serially. One thing we could do is to attach custom identifiers to the search tests and update the search tests to include this identifier in the search itself. The downside is that string search becomes string search + token search (for identifier) but it should speed up the tests and will not accidentally wipe off data if executed against wrong database.

The following role configuration will throw a 500 error on startup:

{
    "name": "clinician",
    "resourcePermissions": [
        {
            "actions": [
            ]
        }
    ]
},

Expected:

To get a configuration error.

Error message:

The code currently tries to automatically register all classes that implements IProvideCapability as transient. We should remove this logic because:

1. Different component has different lifetime (they are not all transient)
2. For component that is manually registered, the runs twice, which could result in unexpected behavior.

This file now refers to a template that no longer exists. We should remove it.

We need documentation and a template for automated deployment of FHIR server.

In addition to the "default" Azure deployment template, we need one that deploys into and ASE with an App Gw in front. This will guarantee only HTTPS access and also be the more likely production deployment scenario.

We need to be able to assign users to roles and extract that role information from the claim so that the appropriate authorization permissions can be applied.

This user story only implements the infrastructure to be able to evaluate authorization permissions based on role but does not actually involve implementing the authorization check itself.

Acceptance:

• Verify that the roles can be extracted from AAD and IdentityServer claims and the permission assigned to the roles are evaluated.

System.Net.Security has a security advisory and must be updated to a version > 4.0.0
aspnet/Announcements#239

a) Add a sample RolePermissionJson to the Fhir.Core project
b) Deserialize into a RoleConfiguration object during startup and have it available in memory during runtime.
c) Unit Tests

Acceptance:

• Verify that the server can read and understand the authorization setting config file.
• Verify that the server throws error if the authorization setting config file is invalid.

We need to make sure the FHIR NuGet package is debuggable and the source is linked correctly for open source community.

Acceptance:

• Verify that user can debug published FHIR server NuGet packages using Visual Studio.

Because compartment is now indexed, I should be able to do a search based on compartment.

https://www.hl7.org/fhir/compartmentdefinition.html#use

Acceptance:

• Verify GET [base]/Patient/[id]/Observation returns all observations for the patient
• Verify the logic works for all compartments

Investigate what work is needed and how to fit B2C with the current authentication architecture.

We need a documentation describing how authentication mechanisms are architected and implemented, how customers can manage roles and users, and how customers can manage roles and permissions.

Acceptance:

• Verify that there is a markdown file describing the authentication architecture, how to manage roles and users, and how to configure roles and permissions.

http://localhost:53727/Observation?component-value-quantity=lt109 => 200
http://localhost:53727/Observation?component-value-quantity=ll109 => 500

The second should return a 400

Going to the following URL returns json instead of xml

http://localhost:53727/metadata?throw=middleware&_format=xml

We should have documentation for how RBAC works.

Acceptance:

• Verify that there is a documentation describing how RBAC works.

Based on spec: http://hl7.org/fhir/search.html#reference

Servers SHOULD reject a search where the logical id refers to more than one matching resource across different types.

Add this resource to a FHIR server:
https://www.hl7.org/fhir/diagnosticreport-example.json
note the field "issued": "2011-03-04T11:45:33+11:00",

Perform the search:
/DiagnosticReport?issued=2011-03-04T10:45:33
It matches. Cool.

Now try this one:
/DiagnosticReport?issued=0-03-04T10:45:33
You get a 500.

Now this one:
/DiagnosticReport?issued=201111111-03-04T10:45:33
It actually matches the document!
So does this one:
/DiagnosticReport?issued=2011jasdlka-03-04T10:45:33

Rename BinaryExpression to FieldComparisonExpression and consolidate StringExpression into FieldComparisonExpression.

Also rename FieldName to SearchIndexEntryFieldName.

Proposal:

Invalid search syntax:
/Observation?component-value-quantity=http://loinc.org|8480-6$lt107|http://unitsofmeasure.org|mm[Hg]$ (invalid trailing $) => 400 (current is 403)

Invalid search parameter name: /Observation?xyz=http://loinc.org|8480-6$lt107|http://unitsofmeasure.org|mm[Hg] => 400 (current is 200 with ignored parameter as reflected in self link)

/DiagnosticReport?subject.name=peter => 403 (which is the current behavior)

ASP.NET core now has tooling to install a trusted localhost TLS certificate, so we should start using https for all local development.

Given a service where the following returns a single item:
http://localhost:53727/Observation?component-value-quantity=eq107
Then this should also find the item:
http://localhost:53727/Observation?component-value-quantity=ap105
But it does not.

From http://hl7.org/fhir/stu3/search.html#prefix:

the value for the parameter in the resource is approximately the same to the provided value.
Note that the recommended value for the approximation is 10% of the stated value (or for a date, 10% of the gap between now and the date), but systems may choose other values where appropriate