Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Me/dpc 4324 hapi jpa eval #2339

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from
Draft

Conversation

MEspositoE14s
Copy link
Contributor

@MEspositoE14s MEspositoE14s commented Nov 29, 2024

🎫 Ticket

https://jira.cms.gov/browse/DPC-4324

Note:

This is strictly a proof of concept that will never be merged. It doesn't need to be reviewed fully, but if you choose to, don't let the large number of changes scare you off. The majority of them are deletes from removing dpc-attribution.

🛠 Changes

Completely removed dpc-attribution and replaced it with an off the shelf FHIR server.

ℹ️ Context

The ticket was to evaluate what FHIR services are currently available in the market and see if we could use them to improve our system. This PR shows the approximate level of effort required to completely remove dpc-attribution and replace it with an off the shelf FHIR server. This being a PoC, there are a number of caveats, though:

  • I made as few configuration changes as possible on the FHIR server. We're essentially running the stock HAPI FHIR JPA server with no changes. In situations where dpc-attribution was adding non-standard FHIR functionality, I either moved that functionality to dpc-api or ignored it if it wasn't required to get our tests passing.
  • A lot of the changes made were in our integration tests. We do some hackey stuff setting them up and tearing them down.
  • I didn't write any new tests or port the end to end Postman tests.
  • This PoC shouldn't be taken as an endorsement of this particular FHIR server, just the overall approach of replacing dpc-attribution with one. I only went with HAPI because it's completely free and already comes containerized.

Benefits to this approach

  • We no longer have to maintain dpc-attribution. No more writing code to convert between FHIR objects and Hibernate entities.
  • Instant R4 support.
  • Instant paging support on the back end. Our existing PoC for paging on the front end should be fully functional with a few minor tweaks.
  • Improved performance. Can bundle transactions together and handle batch submissions.
  • Multitenancy if we decide to implement it.

Negatives

  • While this particular FHIR server is free and open source, most aren't.
  • This approach would require extensive testing to make sure that nothing changes from the customer's perspective, and if it does that it's for the better.
  • Moving our existing data into the FHIR server will be a slog.

🧪 Validation

Run make ci-app locally and all of the tests should pass. You can also run the full api locally and fire queries at it with Postman.

@MEspositoE14s MEspositoE14s requested a review from a team November 29, 2024 21:10
@@ -4,7 +4,7 @@ services:
image: postgres:14
command: postgres -c 'max_connections=250'
environment:
- POSTGRES_MULTIPLE_DATABASES=dpc_attribution,dpc_queue,dpc_auth,dpc_consent,dpc-website_development,bcda,dpc-portal_development
- POSTGRES_MULTIPLE_DATABASES=dpc_attribution,dpc_queue,dpc_auth,dpc_consent,dpc-website_development,bcda,dpc-portal_development,hapi
Copy link
Contributor

Choose a reason for hiding this comment

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

Might as well remove dpc_attribution...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Doh!

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.

2 participants