search

IHE / ITI.mXDE

Provides the means to access data elements extracted from shared structured documents. Enabling the deployment of health data exchange infrastructures where fine-grained access to health data coexists and complements the sharing of coarse-grained documents.
https://profiles.ihe.net/ITI/mXDE/index.html
Creative Commons Attribution 4.0 International
1 stars 0 forks source link

mXDE_001: Transform Considerations #1

Open JohnMoehrke opened 1 year ago

JohnMoehrke commented 1 year ago

Should there be guidance that the FHIR Resource created or updated should include ANY and ALL original identifiers. For example a C-CDA entry level data can have an id, this id should be preserved in the FHIR Resource.

JohnMoehrke commented 1 year ago

carequality section connection guide 15.1

JohnMoehrke commented 1 year ago

C-CDA templates are pretty strict about requiring entry elements having id's on them. For example--you asked about lab results. Lab results are packed in a nested packaging structure where the outer part of the structure (the organizer) has an id (CONF-1198-7127), and the inner structural parts have id's too (CONF:1198-7137).

JohnMoehrke commented 1 year ago

Have heard excuse to not include internal id because that internal id is not useful to external parties. It might not be useful as a way to query, but it is very useful to de-duplicate the data. Therefore even internal id values should be included so as to enable de-duplication

JohnMoehrke commented 1 year ago

I think we always assumed that the mXDE transform would preserve as much original detail when creating the FHIR Resource that QEDm exposes, but there have been some discussions that these transforms are not preserving original assigned identifiers. The rational I have heard is that these original assigned identifiers are often not known to be globally unique, and that they are identifiers that are only usable within the original system. That is to say that they are being removed because the expectation is that the ultimate QEDm client couldn't use the values. I assert that this is a fallacy. It is not wrong as stated, but realistically it is wrong on a data provenance and/or data de-duplication perspective. If a consuming application has received data from multiple pathways, these original assigned identifiers can be used to correlate the data as duplicates (de-duplication). Thus although they are not directly useable, they are still useful. ----- THUS, should mXDE have guidance to preserve these identifiers? If so, is there other data transform policies/processes that should also be included? I recommend these would not be 'shall' requirements, but rather "transformation considerations".