Bulk data: thoughts on attribution lists and groups
As work on https://github.com/smart-on-fhir/fhir-bulk-data-docs proceeds, we're making progress toward a standards-based way to export data for groups of patients, all at once. The Bulk Data specification leaves some important things out of scope -- especially things that are important for interactions between clinical and financial data systems. Two issues that it would be good to tackle alongside the bulk data specification
- How to create new
Groups for use with Bulk Data's
- How to determine the attribution list of patients associated with a particular provider (i.e., "a roster")
How to create new
Groups for use with Bulk Data's
For a financial/administrative system to construct a targeted
$export query, there needs to be some clear way to define a Group of patients whose data is to be exported. These groups could be established based on clinical indications, enrollment in a particular payment or disease management plan, assignment to a specific care manager, or other (more or less arbitrarily intricate) assignment logic. Thus, rather than trying to communicate a logical set of rules for group definition, we'll have more impact if we start by defining an "enumeration-based" way to define groups -- i.e. to have a client tell a server "here are all the patients who should be in a specific group," and provide a way to update this enumeration over time. As a quick sketch, we should be able to support a way for clients to create and maintain attribution-list groups via:
Create Group via
|Param||Value or meaning||Comments|
||this is a group of people (Patients)|
||this is a specific group of real individuals|
||this is a group for active use|
||reference to a
||If the client knows the server-specific FHIR resource ID for the relevant patients, these references can be direct, as in
||--||For attribution groups, the fixed Coding.value of
||reference to an
||For attribution groups, this defines the Organization or Practitioner to whom the patient is attributed. It is used as a search parameter to find the right Group by a FHIR client.|
Note: This approach does not attempt to solve the general problem of patient matching. In the case where a client does not know the server-specific resource id for a patient, the client should follow best practices in conveying data to support a patient matching algorithm on the server side. For example: when conveying Patient demographics and identifiers using
Group.contained, a client should put emphasis on shared identifiers like an insurance number and medical record number. Sensitive general-purpose identifiers like social security numbers should be omitted. Demographics such as name and zip code should be included when available to support matching and confirmation of correctness on the sever side.
Open questions: Can we expect this operation to be synchronous, or will there likely be slow-running parts and/or manual review? If it's async, how do we convey to the client that the request has been received and the server/host organization is working to reconcile and complete?
Update Group via
See definitions for
Review the current definition of the Group via
After posting an initial definition or an update, the client can
GET the Group to determine its current members as known to the server. In the
GET response, all references should be conveyed with server-specific resource ids. In other words, the Group is returned to the client once all matching/reconciling has been completed.
See https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/Bulk-Data-for-an-Attributed-Patient-Population for details on how a clinical provider can fetch data from a payer for an attributed population.
- Should/could the bulk data reasonably identify the attribution methodology/rationale responsible for why each beneficiary is part of the group? (E.g. ‘voluntarily aligned’ beneficiaries might not have had any services performed by the NPI/TINs in the ACO, but would still be attributed to them).