Bulk data: thoughts on attribution lists and groups - smart-on-fhir/smart-on-fhir.github.io GitHub Wiki

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

1. How to create new Groups for use with Bulk Data's $export operation
2. How to determine the attribution list of patients associated with a particular provider (i.e., "a roster")

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:

Param	Value or meaning	Comments
Group.type	person	this is a group of people (Patients)
Group.actual	true	this is a specific group of real individuals
Group.active	true	this is a group for active use
Group.member[].entity	reference to a Patient resource.	If the client knows the server-specific FHIR resource ID for the relevant patients, these references can be direct, as in {"reference": "Patient/123"}. However, a very common scenario will be an external client that knows some information about the patient (e.g., an insurance identifier, an MRN, and a set of demographics) without knowing a server-specific FHIR resource id). In this case, the client can create a relative reference to a contained resource, as in {"reference": "#contained-patient-001}, with all of the relevant details conveyed in `Group.contained[].
Group.characteristic.code	--	For attribution groups, the fixed Coding.value of attributed-to is used (Coding.system: TBD).
Group.characteristic.value	reference to an Organization or Practitioner	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?

See definitions for POST above.

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).