Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

(2020-01 Da Vinci Risk Based Contract Member Identification)

TestScript(s)

https://github.com/dbcg/connectathon

Synthea generated test patients: https://github.com/projecttacoma/fhir-patient-generator:

Security and Privacy Considerations

The scenarios and reference implementations here run using open (i.e. unsecured) connections. Systems SHALL NOT use PHI in any form, or data derived directly from PHI.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Tasks Leading to the Connectathon (Used for Track Preparation)

  1. Identifying the 3 or so measures that have the FHIR measure resource and cql completed
    1. 8/6: will use the three cancer screening measures
  2. Identify or create via Synthea a set of patients with and without clinical data.
    1. 8/6: will use the Synthea patients for the three cancer screen measures (see links under TestsScripts)
  3. Create a “list” of these patient and their identifiers
    1. 8/6: create a list by selecting from the Synthea patients
  4. Identify the profiles associated with these patients that Member Attribution need, e.g., Coverage resource
    1. 8/6: discuss with Dragon
  5. Create a FHIR bundle or other FHIR artifact for the member attribution team to load into the Member Attribution server
    1. 8/6: discuss with Dragon
  6. Test the member attribution operation based on these patients and retrieve this list of patients. Confirm that we provided the correct data to return the list of patients.
    1. 8/6: discuss with Dragon
  7. Determine how the MA member attribution data may need to be “massaged” to be use used in the $care-gaps operation. Additionally, determine if any necessary data may be missing.
    1. 8/6: discuss with Dragon

  Reference Implementation tasks:

  1. Evaluated resources tracking populations
    1. Need to expose it to the measure report
    2.  Spike to assess if this is doable by the Connectathon 
  2. Validate the return bundle conforms to the profile  
  3. Subject being a patient or a group (group is not supported) 
  4. Status (open or closed, and both as default)
  5. A specific measure (right now is only using topic … "measure" is not currently supported) or a list of specific measures
  6. Creation of detectedIssue for care gaps report
  7. Organization
  8. Practitioner

TestScript(s)

https://github.com/dbcg/connectathon

https://github.com/projecttacoma/fhir-patient-generator (random generated test data):

Security and Privacy Considerations

The scenarios and reference implementations here run using open (i.e. unsecured) connections. Systems SHALL NOT use PHI in any form, or data derived directly from PHI.$care-gaps operation

  • $care-gaps with organization

GET [base]/Measure/$care-gaps?periodStart=2020-01-01&periodEnd=2020-07-01&organization=exampleTIN

how to determine the patients to return? is it only Patient.managingOrganization?

  • $care-gaps with organization and provider

GET [base]/Measure/$care-gaps?periodStart=2020-01-01&periodEnd=2020-07-01&organization=exampleTIN&practitioner=exampleNPI

how to determine the patients to return? is it: 

- Patient.generalPractitioner = <organization> and Patient.generalPractitioner = <Provider> 

- Patient.generalPractitioner = PractitionerRole.organization = <Organization>  and PractitionerRole.practitioner = <Provider>