Thursday, August 22, 2019

FHIR Scaling to a Nation

Most discussions about FHIR are simple interaction diagrams like this:


Many Sources (n != 1)


The Real story needs to consider that the "Source" above is a single box representing 10,000 potential source systems that hold data about the patient: (map is a static view of CareQuality network)

More important is that the above map only represents Clinical sources. There are also Payer sources, and many more...

So there is a real scale problem with the above.

If we look at the use-case of Treatment needing to get a current view of data. We could imagine that EACH of these Sources will publish a FHIR endpoint and publish US-Core based Common Clinical Data Set (CCDS). Thus your Source system will need to query them all.

The diagram is not all that more complex as in a sequence diagram we just add a loop. But we all need to understand that loop is multiplied by all sites that indicate the patent has data

Combining Many Sources


You will note that EACH Consumer system needs to do some detailed combination of the results.

  1.  Hope all provide well constrained (e.g. US-Core)
    • need to be robust to variations
  2.  Combine current data from many sources, 
    • leverage any List indicating reconciled at that site
    • hope republished data preserved original id
    • resolving duplicates 
    • leverage any Provenance indicating duplicate resolution
  3.  resolving invalidated deactivate
    •  watching age and Provenance
  4.  harmonize vocabulary differences
  5.  Provide Provenance back to source REST resources

Not everyone will publish US-Core level resources

Reality is that many of the sites won't provide US-Core level access, but will only provide Documents. Best-case is that it is a On-Demand Medical Summary, which does cover the same data and does provide only current data. But may be a set of discharge summary, or episode documents.

So one might need to combine REST access with Document content.  One could optimize to NOT pull documents from sites that provided REST access to current data.

I show this being implemented by an Intermediary. I am not proposing a common Intermediary, although that is possible. I suspect that these Intermediary will have organizational customization. That is that the Consumer organization will want to control the algorithm and output. Thus the Intermediary is likely as many as there are Consuming organizations. This might be able to be generalized for a region. But the more one moves it to a central position, the more one creates potential Privacy concerns.




NOT fully discussed here 


I did not address how the sub-set of sites that have data on this patient are discoverd. There likely needs to be some level of Federated search, or centralized Record Locator, or a combination of both.

I did not address how security is addressed. There could be a national managed security infrastructure, but that is another kind of scale problem. It is possible, but not addressed in this article.

I did not address how Privacy is addressed. I expect that this will continue to be a Source side management. That is that each Source manages their responsibility to protect the data and to release it as appropriate according to the Consent they have on file. There likely is a need for "Point-of-Care Consent".

Likely many more too

----------------------------------- websequence diagram source ---------------------------

title Interop tendency

participant Source
participant Intermediary
participant Consumer

note left of Source: Broad tendency

loop Current Details
note right of Source: Many sources for each site patient Visited
Source->Consumer: FHIR REST
note right of Source
 Note that results can include 
 DocumentReference to documents flow
end note
end

loop Discharge or Episode or Problem or CarePlan or Notes
note right of Source
 Targeted to one document sources or all
 Clinical Documents cover 5 Principles 
 * Persistence
 * Wholeness 
 * Stewardship  
 * Context 
 * Potential for authentication
 Documents could be CDA or FHIR documents
 Not optimial but may be TEXT or PDF 
 Transport can be XD* or MHD (FHIR DocumentReference)
end note
Source->Consumer: FHIR/CDA Document

end


loop Population on a cohort
note right of Source: Many sources

Source->Consumer: FHIR Bulk access
end

note left of Source
 Comprehensive view 
 using Intermediary
end note
opt Reconcilled
Consumer->+Intermediary: Request for data
loop over all sites with current
Source->Intermediary: REST
note left of Intermediary
 Hope all provide well constrained (e.g. US-Core)
 Combine current from many sources, 
 * leverage any List indicating harmonized
 * resolving duplicates, 
 ** leverage any Provenance indicating duplicate resolution
 * resolving invalidated deactivate
 ** watching age and Provenance
 * harmonize vocabulary differences
 Provide Provenance back to source REST resources
end note
end
loop over all sites with Documents 
note left of Intermediary: e.g. IHE mXDE Profile
Source->Intermediary: Document
note left of Intermediary
 Decompose Documents
 Combine document data with current
 Provide Provenance back to source Document
end note 
end
Intermediary->-Consumer: FHIR REST
end

1 comment:

  1. Scale outside healthcare is proven for REST in use cases with many clients to one server (N-1). In health IT we need both to scale (N-M).

    ReplyDelete