BB2-4266 - C4DIC Endpoint #1428
Draft
+653 −165
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
…ub.com/CMSgov/bluebutton-web-server into clewellyn-nava/BB2-4266/C4DIC-endpoint
…ub.com/CMSgov/bluebutton-web-server into clewellyn-nava/BB2-4266/C4DIC-endpoint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
JIRA Ticket:
BB2-4266
What Does This PR Do?
What Should Reviewers Watch For?
There is currently a failing unit tests because it expects the _format to be "json", but if you look at the https://sandbox.bluebutton.cms.gov/docs/openapi#/v1/fhirMetaData, it should /at least/ be application/json, and I propose it should be application/json+fhir everywhere we're making BFD calls.
Please look at the various TODO's, some of these are design decisions the team will have to make and live with, while some of them are proposed cleanups.
I have removed a lot of existing unnecessary code from when fhir server settings and fhir resource permissions were stored as objects in the database. I found no issues with my changes via unit tests and testclient testing, but take care to check permissions.
I've taken the liberty of sketching out what a drf ViewSet implementation of Patient would look like. Doing this made me realize some assumptions our API wrapper has that may need to be revisited if we go with the ViewSet, or push us away from it as a concept.
You should look to authenticate with a patient and mess with the scopes and URI to check that it works and doesn't work as expected.
If you're reviewing this PR, please check for these things in particular:
Validation
Unit tests pass, integration tests pass, local testclient works as expected. This shouldn't be a functional change.
For testing the C4DIC endpoint, you will need to authenticate with BBUser09995 (PW09995!@), as it has the C4DIC data populated.
What Security Implications Does This PR Have?
N/A
Any Migrations?
N/A