We've paused on taking applications for production data and onboarding existing applicants. This is temporary while we make improvements to our ID verification and onboarding process. We'll refresh our updates page when onboarding and applications resume. We'll also post an announcement in our Google Group. In the meantime, the sandbox environment is still available for testing.
A DPC Google Group has been created to provide answers to questions and to support providers and developers who are implementing Data at the Point of Care.
@@ -30,11 +39,11 @@
-
-
+
Blue Button 2.0 provides FHIR-formatted data for one individual Medicare beneficiary at a time, to registered applications with beneficiary authorization. See https://bluebutton.cms.gov/.
BCDA provides FHIR-formatted bulk data files to Medicare Shared Savings Program Accountable Care Organizations (MSSP ACOs) for all of the beneficiaries assigned to a given ACO. See https://bcda.cms.gov/.
@@ -43,11 +52,11 @@
-
-
+
Usefulness of the data to evaluate how helpful CMS claims data is for impacting treatment, provider burden, and quality of care for Fee-for-Service (FFS) providers at the point of care
Ease of implementation for vendors and providers to evaluate how easy it is to configure and get started with requesting and receiving claims data
@@ -59,11 +68,11 @@
-
-
+
Data at the Point of Care secures Protected Health Information (PHI) and Personally Identifiable Information (PII) and has multiple layers of protection, such as encryption in transit and at rest, security certification requirements of connecting vendors, auditing and analytics to look for suspicious activity, terms of service restrictions, public and private security keys, and IP address restriction.
Data at the Point of Care is built based on privacy requirements defined by HIPAA.
@@ -103,172 +112,4 @@
Any Fee-for-Service provider or Health IT vendor can request access to synthetic data via our sandbox
-
-
About Production Pilot:
-
-
-
-
- We're excited to invite you to apply to be a production pilot participant! You can email DPC to be added to the queue for production access.
-
-
-
-
-
-
- DPC is looking for healthcare organizations who meet the following criteria:
-
-
-
- You can answer questions about your healthcare organization, including but not limited to EHR and/or data vendor information, number of providers, provider specialties, and/or number of Medicare beneficiaries seen annually
-
-
- You can provide documentation explaining the workflows implemented in your DPC solution for attribution and the clinical display of data. This can be satisfied with workflow diagrams or written procedures.
-
-
- Attribution (what is your system/user's selection criteria in identifying the patients to be included in requests for data, how do you determine if a patient has an active treatment relationship with the assigned provider, etc.)
-
-
- Data Security processes (who makes the requests, how is that process protected, etc)
-
-
-
-
- You can attest that your software solution meets the security requirements for DPC, specifically one or more of the following requirements:
-
-
- Completed and holds an active ONC Health IT Certification
-
-
- Active HITRUST self-validation assessment (valid for one year from implementation if currently pursuing the HITRUST validated assessment)
-
-
- Active HITRUST Validated Assessment
-
-
- EHNAC Accreditation
-
-
-
-
- You can answer questions regarding your experience testing your solution in sandbox
-
-
- You can demonstrate your DPC solution to the DPC engineering and research team
-
-
-
-
-
-
-
-
- Here's a list of starter questions to help guide your plan for the demo. As we see your solution, additional technical questions may arise.
-
-
- Walk us through your end-to-end workflow.
-
-
- How do you attribute patients to practitioners?
-
-
- How will practitioner see the data in your system?
-
-
-
-
- How frequently will your organization make requests to the API? How quickly will you need the data returned?
-
-
- What is your retry logic for requests that fail?
-
-
- What will you do if you don't get data back for some of the requested patients? For example, data for patients outside of the 18 month lookback period for a given provider will not be returned at this time.
-
-
- How will the data be used? For example, are you using the data for aggregate population reporting, or for insights into the needs of an individual patient?
-
-
- Where does the application live?
-
-
- Would there be a separate instance if you bring on another practice during pilot or MVP?
-
-
-
-
- During onboarding in the early phases of pilot, we'll be providing keys directly to the practitioner organization to grant access to production via secure email - we will not be using the same web portal as our sandbox environment. Please consider how to best communicate with the practitioner to securely transfer secrets if necessary.
-
-
- Are you ready for breaking changes during pilot?
-
-
- As we introduce new features into pilot, how will you incorporate those changes into your solution?
-
-
-
-
- How did you test your DPC solution? What documentation did you use the most?
-
-
-
-
-
-
-
-
- Our goal with the production pilot is not to grant early access to DPC production data, but rather to test specific technical and workflow solutions in a production environment with actual users. The pilot phase of DPC is a learning experience for CMS as well as for our partner organizations, which means that we will make breaking changes to the code while organizations are working in production, and will be looking for feedback from our pilot participants to help us grow. A few limitations for you to know up front:
-
-
-
- Claims data access may be limited by the number of claims or the number of beneficiaries requested or returned during the pilot.
-
-
- New patient information will not be immediately available. At this time only patients with a claim within the last 18 months for the attributed provider will be accessible.
-
-
- DPC is not a final product yet. As we continue to gather feedback and do research, it is possible that significant changes may be made to the DPC API - participation in this pilot is a great opportunity to help influence the future direction of the API! We will communicate these changes to all of our production and sandbox community members as they come about, but we may identify the need to temporarily shut down production data access between now and our full release as part of our continued development efforts.
-
-
-
-
-
-
-
-
- DPC will onboard one organization at a time. Depending on the backlog of organizations, this may mean that your organization will sit in the queue for a few months before it is your turn to onboard. We will keep you updated as much as we can and ask that you continue to test your solution in the sandbox during that time as any changes to the production environment will be changed in the sandbox environment first.
-
-
-
-
-
-
- Good news: our sandbox environment matches the production environment, and we'll roll out new functionality in sandbox before sending it into production. Even if you are not able to participate in the production pilot at this juncture, please continue to test in the sandbox environment with synthetic data. Your feedback through the Google Group is invaluable to our researchers and engineers as we all work together to shape the future of DPC.
-
-
-
-
-
-
- Yes, you can inherit AWS’ HITRUST certification if your DPC solution meets the following requirements:
-
-
The DPC solution is contained entirely within AWS Services that have received a HITRUST certification. See AWS' list of HITRUST-certified services under HITRUST CSF.