{"id":44269498,"url":"https://github.com/cmsgov/dpc-app","last_synced_at":"2026-05-05T18:01:49.061Z","repository":{"id":37849922,"uuid":"169102492","full_name":"CMSgov/dpc-app","owner":"CMSgov","description":"Data @ the point of care application","archived":false,"fork":false,"pushed_at":"2026-02-03T23:10:33.000Z","size":58351,"stargazers_count":49,"open_issues_count":9,"forks_count":18,"subscribers_count":18,"default_branch":"main","last_synced_at":"2026-02-04T04:22:28.872Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://dpc.cms.gov/","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"cc0-1.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/CMSgov.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":".github/CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2019-02-04T15:45:48.000Z","updated_at":"2026-02-03T21:42:39.000Z","dependencies_parsed_at":"2024-11-06T03:18:32.861Z","dependency_job_id":"dd74622b-24ae-4353-ab46-fee23d42361d","html_url":"https://github.com/CMSgov/dpc-app","commit_stats":null,"previous_names":[],"tags_count":217,"template":false,"template_full_name":null,"purl":"pkg:github/CMSgov/dpc-app","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CMSgov%2Fdpc-app","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CMSgov%2Fdpc-app/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CMSgov%2Fdpc-app/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CMSgov%2Fdpc-app/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/CMSgov","download_url":"https://codeload.github.com/CMSgov/dpc-app/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CMSgov%2Fdpc-app/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29313081,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-10T17:48:59.043Z","status":"ssl_error","status_checked_at":"2026-02-10T17:45:37.240Z","response_time":65,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-02-10T19:03:42.007Z","updated_at":"2026-02-10T19:03:44.891Z","avatar_url":"https://github.com/CMSgov.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# User Guide\nThis document serves as a guide for running the Data at the Point of Care (DPC) API on your local environment. \n\n\n[![Build Status](https://travis-ci.org/CMSgov/dpc-app.svg?branch=main)](https://travis-ci.org/CMSgov/dpc-app)\n[![Maintainability](https://api.codeclimate.com/v1/badges/46309e9b1877a7b18324/maintainability)](https://codeclimate.com/github/CMSgov/dpc-app/maintainability)\n[![Test Coverage](https://api.codeclimate.com/v1/badges/46309e9b1877a7b18324/test_coverage)](https://codeclimate.com/github/CMSgov/dpc-app/test_coverage)\n\n\n\n\u003c!-- TOC --\u003e\n## Table of Contents\n* [What Is DPC?](#what-is-dpc)\n* [Components](#components)\n  * [Main Services](#main-services)\n  * [Shared Modules](#shared-modules)\n* [Local Development Setup](#tech-environment)\n   * [Required Dependencies](#required-dependencies)\n   * [Recommended tools](#recommended-tools)\n   * [Installing and Using Pre-Commit](#installing-and-using-pre-commit)\n   * [Quickstart](#quickstart)\n * [Managing Encrypted Files](#managing-encrypted-files)\n   * [Re-encrypting files](#re-encrypting-files)\n * [Starting the Database](#starting-the-database)\n * [Building the DPC API](#building-dpc)\n     * [How the API Works](#how-the-api-works)\n     * [Option 1: Full integration test](#option-1-full-integration-test)\n     * [Option 2: Manually](#option-2-manually)\n  * [Running the DPC API](#running-the-dpc-api-via-docker)\n      * [Running the DPC API via Docker](#running-the-dpc-api-via-docker)\n     * [Generating a golden macaroon](#generating-a-golden-macaroon)\n     * [Manual JAR execution](#manual-jar-execution)\n  * [Seeding the Database](#seeding-the-database)\n  * [Testing the Application](#testing-the-application)\n    * [Demo client](#demo-client)\n    * [Manual testing](#manual-testing)\n    * [Smoke tests](#smoke-tests)\n  * [Generating the Source Code Documentation via JavaDoc](#generating-the-source-code-documentation-via-javadoc)\n  * [Building the Additional Services](#building-the-additional-services)\n    * [Postman collection](#postman-collection)\n  * [Code Coverage](#code-coverage)\n  * [Local Debugging](#local-debugging)\n  * [Debugging Integration Tests](#debugging-integration-tests)\n  * [Other Notes](#other-notes)\n    * [BFD transaction time details](#bfd-transaction-time-details)\n  * [Troubleshooting](#troubleshooting)\n  * [More about DPC](#more-about-dpc)\n\u003c!-- TOC --\u003e\n\n\n## What Is DPC?\n\nDPC is a pilot application programming interface (API) whose goal is to enable healthcare\nproviders to deliver high quality care directly to Medicare beneficiaries. See \n[DPC One-Pager](https://dpc.cms.gov/assets/downloads/dpc-one-pager.pdf) and the [DPC Website](https://dpc.cms.gov/) to learn more about the API.\n\n## Components\n\n#### Main Services\n\nThe DPC application is split into multiple services.\n\n| Service|Type|Description|Stack|\n|-------------------------------------|---|----------------------------------------------------------------------------------------|---|\n| [dpc-web](/dpc-web)                 |Public Portal| Portal for managing organizations (Sandbox only, and soon to be deprecated)            |Ruby on Rails|\n| [dpc-admin](/dpc-admin)             |Internal Portal| Administrative Portal for managing organizations (Sandbox only, and soon to be deprecated) |Ruby on Rails|\n| [dpc-portal](/dpc-portal)           |Public Portal| Portal for managing organizations                                                      |Ruby on Rails|\n| [dpc-api](/dpc-api)                 |Public API| Asynchronous FHIR API for managing organizations and requesting or retrieving data     |Java (Dropwizard)|\n| [dpc-attribution](/dpc-attribution) |Internal API| Provides and updates data about attribution                                            |Java (Dropwizard)|\n| [dpc-aggregation](/dpc-aggregation) |Internal Worker Service| Polls for job batches and exports data for singular batches                            |Java (Dropwizard + RxJava)|\n\n#### Shared Modules\n\nIn addition to services, several modules are shared across components.\n\n|Module Name|Description|Stack|\n|---|---|---|\n|[dpc-bluebutton](/dpc-bluebutton)|Bluebutton API Client|Java|\n|[dpc-macaroons](/dpc-macaroons)|Implementation of macaroons for authentication|Java|\n|[dpc-queue](/dpc-queue)| Provides an interface for managing export jobs and batches|Java|\n|[dpc-common](/dpc-common)|Shared utilities for components|Java|\n|[dpc-testing](/dpc-testing)|Shared utilities for testing|Java|\n|[engines](/engines)|Shared engines|Ruby|\n\n## Local Development Setup\n###### [`^`](#table-of-contents)\n\n### Required Dependencies\n\nWhen running the applications locally, you'll want to run everything through Docker. This simplifies the process of spinning up multiple services, connecting them together, and upgrading tooling versions over time.\n\nIn that scenario, you only need the following dependencies:\n\n- Install [Ansible Vault](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#)\n- Install [Docker Desktop](https://docs.docker.com/install/) (make sure to allocate more than the default 2Gb of memory)\n- Install [Pre-commit](https://pre-commit.com/) with [Gitleaks](https://github.com/gitleaks/gitleaks)\n\nIf you want to build applications locally, you'll need the following tools:\n\n- Ruby and `bundler`\n- Java 17 and Maven (`mvn`)\n\nIn addition, it's helpful to have the following installed for more specific scenarios:\n- Running [postman tests](#postman-collection): Node.js (includes `npm`)\n\n### Recommended tools\n\nFor development, we recommend the following tooling:\n\n- Code Editor: JetBrains [Intelli-J Idea IDE](https://jetbrains.com/idea) or [Visual Studio Code](https://code.visualstudio.com/)\n- Database browser: [PgAdmin](https://pgadmin.org) or [Postico](https://postico.com) *(MacOS)*\n- API browser and testing tool: [Postman](https://www.postman.com/downloads/)\n\n### Installing and Using Pre-commit\n\nAnyone committing to this repo must use the pre-commit hook to lower the likelihood that secrets will be exposed.\n\n#### Step 1: Install pre-commit\n\nYou can install pre-commit using the MacOS package manager Homebrew:\n\n```sh\nbrew install pre-commit\n```\n\nOther installation options can be found in the [pre-commit documentation](https://pre-commit.com/#install).\n\n#### Step 2: Install the hooks\n\nRun the following command to install the gitleaks hook:\n\n```sh\npre-commit install\n```\n\nThis will download and install the pre-commit hooks specified in `.pre-commit-config.yaml`.\n\n### Quickstart\n\nThe fastest way to get started with building and running the applications is to follow [the Quickstart guide](/QuickStart.md). However, you can see below for more granular details.\n\n## Managing Encrypted Files\n###### [`^`](#table-of-contents)\n\nThe files committed in the `ops/config/encrypted` directory hold secret information, and are encrypted with [Ansible Vault](https://docs.ansible.com/ansible/2.4/vault.html).\n\nBefore building the app or running any tests, the decrypted secrets must be available as environment variables.\n\nIn order to encrypt and decrypt configuration variables, you must create a `.vault_password` file in the root directory. Contact another team member to gain access to the vault password.\n\nRun the following to decrypt the encrypted files:\n\n```sh\nmake secure-envs\n```\n\nIf decrypted successfully, you will see the decrypted data in new files under `/ops/config/decrypted` with the same names as the corresponding encrypted files.\n\n### Re-encrypting files\n\nTo re-encrypt files after updating them, you can run the following command:\n\n```\n./ops/scripts/secrets --encrypt \u003cfilename\u003e\n```\n\nNote that this will always generate a unique hash, even if you didn't change the file.\n## Starting the Database\n###### [`^`](#table-of-contents)\n\n\nDPC requires an external Postgres database to be running. While a separate Postgres server can be used, the `docker-compose` file includes everything needed, and can be started like so: \n\n```bash\ndocker compose up start_core_dependencies\n```\n\n**Warning**: If you do have an existing Postgres database running on port 5342, docker-compose **will not** alert you to the port conflict. Ensure any local Postgres databases are stopped before starting docker-compose.\n\n## Building the DPC API\n###### [`^`](#table-of-contents)\n\n### How the API Works\n\nBy default, the API components will attempt to connect to the `dpc_attribution`, `dpc_queue`, and `dpc_auth` databases on the localhost as the `postgres` user with a password of `dpc-safe`.\n\nAll of these databases should be created automatically from the previous step. When the API applications start, migrations will run and initialize the databases with the correct tables and data. If this behavior is not desired, set an environment variable of `DB_MIGRATION=0`.\n\nDefault settings can be overridden, either directly in the module configurations or via `local.application.env` file in the project resources directory. \nFor example, modifying the `dpc-attribution` configuration:\n\n```yaml\ndatabase:\n  driverClass: org.postgresql.Driver\n  url: \"jdbc:postgresql://localhost:5432/dpc-dev\"\n  user: postgres\n```\n\n**Note**: On startup, the services look for a local override file (local.application.env) in the root of their *current* working directory. This can create an issue when running tests with IntelliJ. The default sets the working directory to be the module root, which means any local overrides are ignored.\nThis can be fixed by setting the working directory to the project root, but needs to be done manually.\n\n### There are two ways to build DPC:\n\n##### Option 1: Full integration test\n\nRun `make ci-app`. This will start the dependencies, build all components, run integration tests, and run a full end-to-end test. You will be left with compiled JARs for each component, as well as compiled Docker containers.\n\n##### Option 2: Manually\n\nRun `make docker-base` to build the common, baseline Docker image (i.e., `dpc-base:latest`) used across DPC services.\n\nNext, in order to make the decrypted environment variables accessible to Maven, run `make maven-config`.\nThis command will convert the contents of `ops/config/decrypted/local.env` to Maven flags which can be viewed in `.mvn/maven.config` if successful.\n\nThen, run `mvn clean install` to build and test the application. Dependencies will need to be up and running for this option to succeed.\n\nRunning `mvn clean install` will also construct the Docker images for the individual services. To skip the Docker build, pass `-Djib.skip=True`.\n\nIf a build failure is encountered when running `mvn clean install`, attempt to resolve this by separating the build process into two steps by running `make api` followed by `mvn install`.\n\nNote that the `dpc-base` image produced by `make docker-base` is not stored in a remote repository. The `mvn clean install` process relies on the base image being available via the local Docker daemon.\n\n## Running the DPC API\n###### [`^`](#table-of-contents)\n\nOnce the JARs are built, they can be run in two ways, either via [`docker-compose`](https://docs.docker.com/compose/overview/) or by manually running the JARs.\n\n### Running the DPC API via Docker \n\nClick on [Install Docker](https://www.docker.com/products/docker-desktop) to set up Docker.\nThe application (along with all required dependencies) can be automatically started with the following command: `make start-app`. \nThe individual services can be started (along with their dependencies) by passing the service name to the `up` command.\n\n```bash\ndocker compose up {db,aggregation,attribution,api}\n``` \n\nBy default, the Docker containers start with minimal authentication enabled, meaning that some functionality (such as extracting the organization_id from the access token) will not work as expected and always returns the same value.\nThis can be overridden during startup by setting the `AUTH_DISABLED=false` environment variable. \n\nWhen running locally, you'll need to update the docker-compse.yml file by adding:\n```yaml\nports: \n  - \"5432:5432\"\n```\n\nin the `db` node e.g.\n```yaml\ndb: \n  image: postgres:16 \n  ports: \n    - \"5432:5432\"\n```\n### Generating a golden macaroon\n\nGolden macaroons are automatically generated and configured upon startup for the frontend applications. To generate your own for use, run the command below:\n\n`curl -X POST -w '\\n' http://localhost:9903/tasks/generate-token`\n\n### Manual JAR execution\n\nAlternatively, the individual services can be manually executing the `server` command for the various services.\n\nWhen manually running the individual services, you'll need to ensure that there are no listening port collisions. By default, each service starts with the same application (8080) and admin (9900) ports. We provide a sample `application.local.conf` file which contains all the necessary configuration options. This file can be copied and used directly: `cp application.local.conf.sample application.local.conf`.\n\n**Important Note**: The API service requires authentication before performing actions. This will cause most integration tests to fail, as they expect the endpoints to be open. Authentication can be disabled in one of two ways: \n* Set the `ENV` environment variable to `local` (which is the default when running under Docker).\n* Set `authenticationDisabled=true` in the config file (the default from the sample config file).   \n\nNext, start each service in a new terminal window, from within the `dpc-app` root directory. \n\n```bash\njava -jar dpc-attribution/target/dpc-attribution.jar server\njava -jar dpc-aggregation/target/dpc-aggregation.jar server\njava -jar dpc-api/target/dpc-api.jar server\n```\n\nBy default, the services will attempt to load the `local.application.env` file from the current execution directory. \nThis can be overridden by passing `ENV={dev,test,prod}`, which will load `{dev,test,prod}.application.env` file from the service resources directory.\n\n**Note**: Manually specifying a config file will disable the normal configuration merging process. \nThis means that only the config variables directly specified in the file will be loaded, no other `application.env` files will be processed. \n\n* You can check that the application is running by requesting the FHIR `CapabilitiesStatement` for the `dpc-api` service, which will return a JSON-formatted FHIR resource.\n    ```bash\n    curl -H \"Accept: application/fhir+json\" http://localhost:3002/v1/metadata\n    ```\n\n## Seeding the Database\n###### [`^`](#table-of-contents)\n\n**Note**: This step is not required when directly running the `demo` for the `dpc-api` service, which partially seeds the database on first execution.\n\nBy default, DPC initially starts with an empty attribution database, which means that no patients have been attributed to any providers and thus nothing can be exported from BlueButton2.0.\n\nIn order to successfully test and demonstrate the application, there needs to be initial data loaded into the attribution database.\nWe provide a small CSV [file](src/main/resources/test_associations.csv) which associates some fake providers with valid patients from the BlueButton2.0 Sandbox.\n\nThe database can be automatically migrated and seeded by running `make seed-db` or by using the following commands:\n\n**Note:** For instances where one cannot set up the DPC due to authorization issues, follow the steps in the [manual table setup document](DbTables.md) to populate the necessary tables manually. \n\n```bash\njava -jar dpc-attribution/target/dpc-attribution.jar db migrate\njava -jar dpc-attribution/target/dpc-attribution.jar seed\n``` \n\n## Testing the Application\n###### [`^`](#table-of-contents)\n\n### Demo client\n\nThe `dpc-api` component contains a `demo` command, which illustrates the basic workflow for submitting an export request and modifying an attribution roster.\nIt can be executed with the following command:\n\n`java -jar dpc-api/target/dpc-api.jar demo`\n\n**Note**: The demo client expects the entire system (all databases and services) to be running from a new state (no data in the database).\nThis is the default when starting the services from the docker-compose file.\nWhen running the JARs manually, the user will need to ensure that the `dpc_attribution` database is truncated after each run. \n\nThe demo performs the following actions:\n\n1. Makes an export request for a given provider. This request fails because the provider is not registered with the application and has no attributed patients.\n1. Generates an attribution roster for the provider using the [test_association.csv](src/main/resources/test_associations.csv) file.\n1. Resubmits the original Export request.\n1. Polls the Job endpoint using the URL returned from the Export request and waits for a completed status.\n1. Outputs the download URLs for all files generated by the Export request.\n\n### Manual testing\n\nThe recommended method for testing the services is with the [Postman](https://www.getpostman.com) application.\nThis allows easy visualization of responses, as well as simplifies adding the necessary HTTP headers.\n\nSteps for testing the data export:\n\n1. Start the services using either the `docker-compose` command or through manually running the JARs. If running the JARs manually, you will need to migrate and seed the database before continuing. \n1. Make an initial GET request to the following endpoint: `http://localhost:3002/v1/Group/3461C774-B48F-11E8-96F8-529269fb1459/$export`.\nThis will request a data export for all the patients attribution to provider: `3461C774-B48F-11E8-96F8-529269fb1459`.\nYou will need to set the Accept header to `application/fhir+json` (per the FHIR bulk spec).\n1. The response from the Export endpoint should be a **204** with the `Content-Location` header containing a URL which the user can use to to check the status of the job. \n1. Make a GET request using the URL provided by the `/Group` endpoint from the previous step.\n Which has this format: `http://localhost:3002/v1/Jobs/{unique UUID of export job}`.\n You will need to ensure that the Accept header is set to `application/fhir+json` (per the FHIR bulk spec).\n You will need to ensure that the Prefer header is set to `respond-async`.\n The server should return a **204** response until the job has completed.\n Once the job is complete, the endpoint should return data in the following format (the actual values will be different):\n \n     ```javascript\n    {\n        \"transactionTime\": 1550868647.776162,\n        \"request\": \"http://localhost:3002/v1/Job/de00da66-86cf-4be1-a2a8-0415b21a6a9b\",\n        \"requiresAccessToken\": false,\n        \"output\": [\n            \"http://localhost:3002/v1/Data/de00da66-86cf-4be1-a2a8-0415b21a6a9b.ndjson\"\n        ],\n        \"error\": []\n    }\n    ```\n    The output array contains a list of URLs where the exported files can be downloaded from.\n1. Download the exported files by calling the `/Data` endpoint with URLs provided (e.g., `http://localhost:3002/v1/Data/de00da66-86cf-4be1-a2a8-0415b21a6a9b.ndjson`).\n1. Enjoy your glorious ND-JSON-formatted FHIR data.\n\n\n### Smoke tests\n\nSmoke tests are provided by k6.\nThey can be run locally with `make smoke/local`. Errors may occur if the docker images have not been built. See the load testing [README](dpc-load-testing/README.md#smoke-tests) for more details.\n\n## Generating the Source Code Documentation via JavaDoc \n###### [`^`](#table-of-contents)\n\nThe entire project's code base documentation can be generated in HTML format by using the Java's\nJavaDoc tool. The [Intelli-J Idea](https://jetbrains.com/idea) integrated development environment makes this easy to do. Navigate to the **Tools\u003eGenerate JavaDoc** menu item, specify the scope of the documentation and the output location, and you'll be able to view an interactive document outlining the code members.\n\n\n## Building the Additional Services\n###### [`^`](#table-of-contents)\n\n- Documentation on building the DPC Portal is covered in the specific [README](dpc-portal/README.md).\n- Documentation on building the DPC Website is covered in the specific [README](dpc-web/README.md).\n\n\n### Postman collection\n\nNote: Prior to running the tests, ensure that you've updated these Postman Environment variables: \n- organization-id\n- client-token\n- public-key\n- private-key\n\nOnce the development environment is up and running, you should now be able to run some calls to the API via the DPC Postman Collections. Below, are some useful endpoints for verifying a functional development environment:\n- Register single patient\n- Register practitioner\n- Get all groups\n- Add patient to group\n- Create export data request\n\n\n## Code Coverage\n###### [`^`](#table-of-contents)\n\n- Run `make unit-tests` to use Jacoco to generate local code coverage reports.  Within each module, the human-readable report can be found at `module/target/site/jacoco/index.html`.  The machine-readable version that gets loaded to SonarQube is `jacoco.xml` in the same directory.\n- Stand up a local version of SonarQube inside a Docker container as described [here](https://docs.sonarsource.com/sonarqube/latest/try-out-sonarqube/).  Essentially, just run the following command `docker run -d --name sonarqube -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true -p 9000:9000 sonarqube:latest`.\n  - Login to SonarQube at http://localhost:9000 with login:pass of admin:admin.\n  - Setup a new project as described in the link above.\n- Run the following command to load your coverage data into SonarQube, inserting your project key, name and token...\n    ```\n    mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar \\\n      -Dsonar.projectKey={YOUR PROJECT KEY} \\\n      -Dsonar.projectName='{YOUR PROJECT NAME}' \\\n      -Dsonar.host.url=http://localhost:9000 \\\n      -Dsonar.token={YOUR PROJECT TOKEN}\n    ```\n- Your code coverage results should now be in your local version of SonarQube.\n\n## Local Debugging\n###### [`^`](#table-of-contents)\n\nIf you're running locally through Docker and you want to use your debugger there are two steps.\n- Open up port 5005 on whichever service you want to debug\n  - Add the following to docker-compose.yml under api, aggregation, or attribution.\n    ```    \n    ports:\n        - \"5005:5005\"\n    ```\n- Instead of using `make start-dpc` or `make start-app` to start the application, use `make start-dpc-debug` or `make start-app-debug`.\n  - They'll both do a clean compile of the app with debug information and start each service with the debug agent.\n- Now you can attach your debugger to the running app on port 5005.\n  - If you're using IntelliJ, there are instructions [here](https://www.jetbrains.com/help/idea/attaching-to-local-process.html#attach-to-remote).\n\n\n## Debugging Integration Tests\n###### [`^`](#table-of-contents)\nIf you want to run and debug integration tests through IntelliJ there are a few steps you have to do first.  The same concepts should apply to VS Code, but you'll have to figure out the details yourself.\n- When running a test in the IDE, IntelliJ creates a temporary debug configuration.  We need to make sure our secure env variables get included.\n  - Go to Run -\u003e Edit Configurations\n  - Click Edit Configuration Templates and select JUnit\n  - At the bottom, add a new .env file and point it to `ops/config/decrypted/local.env`\n- We need to start our dependent services, so run `make start-it-debug`\n  - This will recompile dpc with debug extensions included and start containers for dpc-attribution, dpc-aggregation, and a db.\n- Now you should be able to run any of the integration tests under dpc-api by clicking on the little green arrow next to their implementation.\n  - Need to debug a test?  Right click on the triangle and select debug.\n  - If running ExpirationJobTest results in a port collision error, you can stop the attribution service in Docker and try running the test again. \n- If you have to debug one of the dependant services, for instance because an IT is calling dpc-attribution and getting a 500, and you can't figure out why, follow the instructions under [Local Debugging](#local-debugging) to open up the dependant service's debugger port in docker-compose, then rerun `make start-it-debug`.\n  - Now you can attach your debugger to that service and still run integration tests as described above.\n  - You'll have one debugger tab open on an IT in dpc-api and another on the dependant service, allowing you to set break points in either and examine the test end to end.\n\n#### Running Integration Tests Against the BFD Sandbox\nWant to run your integration tests against the real BFD sandbox instead of using the MockBlueButtonClient?  In docker-compose.yml, under the aggregation service, set the USE_BFD_MOCK env variable to false and then rerun `make start-it-debug.`\n\nNote: Many of our integration tests are written for specific test data that only exists in our MockBlueButtonClient.  If you switch to the real BFD sandbox these tests will fail, but if you want a true end to end test this is the way to go.  A list of synthetic patients in the sandbox can be found [here](https://github.com/CMSgov/beneficiary-fhir-data/wiki/Synthetic-Data-Guide).\n\n## Other Notes\n###### [`^`](#table-of-contents)\n\n### BFD transaction time details   \n\nWhen requesting data from BFD, you must ensure that the `_since` time in the request is after the current BFD transaction time.\n\nThe BFD transaction time comes from the Meta object in the bundled response (Bundle.Meta.LastUpdated).\n\nAccording to FHIR, BFD must return a bundle (which may be empty but still contain the required metadata) even if the patient ID doesn't match.\n\nTherefore, using a fake patient ID which is guaranteed not to match is an easy way to get back a lean response with the valid BFD transaction time:\n\n```json\n{\n  \"resourceType\": \"Bundle\",\n  \"id\": \"dc6f27bd-0448-43aa-a067-c120f85199a6\",\n  \"meta\": {\n    \"lastUpdated\": \"2021-06-08T01:55:08.681+00:00\"\n  },\n  \"type\": \"searchset\",\n  \"total\": 0,\n  \"link\": [\n    {\n      \"relation\": \"self\",\n      \"url\": \"https://exampleURL/Patient/?_id=blah\u0026_lastUpdated=le2021-06-22T09%3A31%3A28.837731-05%3A00\"\n    }\n  ]\n}\n```\n\n## Troubleshooting  \n###### [`^`](#table-of-contents)\n\nPlease see the [troublshooting document ](Troubleshooting.md) for more help.\n\n## More About DPC\n###### [`^`](#table-of-contents)\n### Project Vision\nThe project vision is available at [https://dpc.cms.gov](https://dpc.cms.gov).\n\n### Agency Mission\n\nSee [https://www.cms.gov](https://www.cms.gov) for this project's agency's mission.\n\n### Team Mission\n\nDPC operates under the [Data Analytics and Systems Group](https://www.cms.gov/research-statistics-data-and-systems/data-analytics-and-systems-group).\n\n### Core Team\nTeam members are listed on our [community page](./COMMUNITY.md).\n\n### Contributing\nContributions should follow [our policy](./CONTRIBUTING.md).\n\n### Community Guidelines\nSee the [Code of Conduct](./CODE_OF_CONDUCT.md) for community guidelines.\n\n### Policies\nContributions to this project must comply with [Section 508](https://www.section508.gov/) accessibility standards.\n\n### Public Domain\nThis project is subject to the [Creative Commons Zero 1.0 International License](./LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcmsgov%2Fdpc-app","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcmsgov%2Fdpc-app","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcmsgov%2Fdpc-app/lists"}