-
Notifications
You must be signed in to change notification settings - Fork 154
Provider Structure and Import Functionality
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",
}
]
}
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.
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 OPML and QRDA Cat I snippet can be found in this gist.