Aggregation implemented by each primary system due to usage of XDS infrastructure (Marco Studer, Cistec AG)

[ig-feedback]

ch.fhir.ig.ch-vacd#4.0.0-ballot /Use-Case-1-Impfdokumentation-sichten.html

According to the use case description, a primary system needs to request / download the vaccination documents (Immunization Administration, Vaccination Record) using the XDS transactions ITI-18 / ITI-43 as these documents shall be stored in the existing XDS infrastructure of the different communities. The primary system has to merge the retrieved documents, i.e. has to implement the aggregator functionality itself.

The implementation of this aggregation functionality in each primary system is for sure not ideal in terms of probability for aggregation errors as well as economic efficiency. Wouldn't it be better to offer this functionality by the community systems or a centralized system, e.g. by introducing a FHIR store or at least an API for downloading / uploading vaccination documents? An advantage would be the possibility to ensure correctness of the vaccination document (validation) by the community component / centralized system.

XDS allows to upload different documents with different confidentiality levels. Additionally the patient can change the confidentiality for each document. This might lead to issues in the vaccination context as the primary system might retrieve incomplete data. This issue could also be solved not using the XDS approach for structured vaccination data.

Storing vaccination documents in XDS means there will be links between documents on two different layers:
(a) An XDS document entry can replace another XDS document entry.
(b) FHIR vaccination documents/entries can point to other FHIR vaccination documents/entries.
Uploading a new version of a XDS document (a) might lead to problems resolving the links in the FHIR documents (b).

Marco Studer, Cistec AG

[ralych]

The problem of duplication information is known and accepted. There does not exist a solution to solve the problem.

the exchange format ch-vacd has to function also external of EPR or general IHE XDS infrastructure.

[studerm]

The issue is mainly targeting the EPR usage as the FHIR IG use cases are only describing the usage within the EPR. It's somehow hard to understand why a solution with obvious drawbacks is accepted for the very first introduction of structured data in the EPR. Dealing with the complexity is delegated to all content consumers (primary systems) instead of offered by a centralized component (single implementation). Introducing a FHIR infrastructure and maybe even storing the CH:VACD data in a centralized system might faciliate a more suitable solution. There are already ideas of introducing a FHIR store according to discussions during this years Projectathon.

[ralych]

Work is done