Provider Structure and Import Functionality

Provider Structure

Providers in popHealth are now defined as a tree structure, allowing for the calculation, examination, and reporting of CQM results in a hierarchical manner.

Provider information is imported into popHealth via OPML. OPML is a simple XML format for representing an outline, which we import into the Provider tree structure.

Each provider's data elements are imported from the XML attributes of the provider's respective entry in the OPML document. Currently, the provider's name and address fields are extracted from their respective XML attributes. Provider npi is sourced from the id XML attribute.

All other XML attributes that are not a member of 'tin', 'id', 'name', 'address', 'npi' are saved in the provider as cda_identifiers such that cda_identifier.root is the XML attribute name and cda_identifier.extension is the XML attribute value.

An example OPML entry and its resulting Provider are as follows:

OPML: <outline Facility="10" tin="" name="test facility" address="1 test case drive, Bedford MA 12345">

Provider (simplified JSON):

{
    "given_name" : "test facility",
    "address" : "1 test case drive, Bedford MA 12345",
    "cda_identifiers" : [
        {
            "root" : "Facility",
            "extension" : "10",
        }
    ]
}

Provider Association Functionality

When patient data is imported into popHealth via QRDA Category I documents, the patients are assigned ProviderPerformances that represent an association with a specific provider for a specific period of time (represented by a provider_id, a start_date and an end_date).

popHealth will initially try to match a patient to a provider based on the npi provided in the QRDA Category I document. In the case that the npi is not available in the QRDA Category I document or the npi does not match any extant providers, popHealth will attempt to find associated providers by cda_identifier.

In order to match a patient to a provider, we use the <assignedEntity> element in the QRDA Category I document. This element contains one or more <id> elements, each representing a cda_identifier with root and extension attributes.

The cda_identifiers for the patient are then matched against the cda_identifiers that were derived from the OPML when we imported our providers. The ProviderPerformances are then created for the patient, with the provider_id from the match, and the start_date and end_date provided in the QRDA Category I document.

When providers are missing

popHealth has the notion of an "orphan" provider. This is the provider to which patients will be assigned when a mapping to a provider can not be determined. There are two cases where this can happen:

• The QRDA Category I document does not contain any providers
• Providers listed in the QRDA Category I document are not in the popHealth database. popHealth will not create providers in its database from information in a QRDA Category I

The orphan provider will be a child of the root provider for the application.

Example

Example OPML and QRDA Cat I snippet can be found in this gist.