cdisc-org/DataExchange-ODM

on FHIR integration

Opened this issue · 0 comments

Hello,

since in #58 we have already discussed how ODM v2.0 is not supported in the library yet, I will ask a few questions on the FHIR integration standard, starting from the examples, assuming that ODM v2.0 will be supported in the near future.

The examples I will mainly refer to are the following two:

I will split and group the questions in their own specific section:

multiple FHIR servers

In the FHIR example (line#27) a item group is defined specifying the external FHIR source (LOINC) for data retrieval, while in the data retrieval from FHIR in ODM example no such external FHIR source is specified in the study definition:

  • why is that specification necessary in the former case, but not in the latter?
  • should the FHIR source be specified inside each item group definition or should it be defined once for the whole study?
  • is it possible to define multiple different FHIR sources from which the data for some items should be fetched?

The last question is quite interesting since no example shows how to do it or if it is even possible.

formal expressions

Another key difference between the two examples is that the FHIR example specifies a code block using the FHIR client in python, while the data retrieval from FHIR example uses some kind of built-in query format with the context set to FHIR:

  • are they interchangeable or when is it appropriate to use one in favour of the other?

In the client code block it is assumed that the library has already been imported, while it says server settings would need context:

  • where and when should the library be imported with respect to the ODM file?
  • what does it mean to put server settings in context, e.g., avoiding hardcoding the API base or oauth2 credentials;

Also, the code block establishes a client connection with the server there, meaning that if oauth2 authentication was needed for a specific FHIR server we should likely handle the authentication workflow there, before instantiating the client:

  • should the authentication or client instantiation workflow be repeated for each method definition or could it be centralized?
  • should multiple identical code blocks be written if a specific method had to fetch data from multiple FHIR sources?

As for the built-in query format case, I have similar concerns regarding authentication or having multiple FHIR sources.

Also, those method definitions assume the PATIENTID and BASE parameters to be passed to the method:

<MethodDef OID="MT.SNOMEDCT" Name="Method to retrieve the SNOMED-CT code of the Medical History Term">
  <Description><TranslatedText xml:lang="en" Type="text/plain">FHIR API call definition to retrieve Medical History SNOMED-CT code from FHIR 'Condition' resource</TranslatedText></Description>
  <MethodSignature>
    <Parameter Name="PATIENTID" Definition="Patient ID in the EHR system" DataType="text"/>
    <Parameter Name="BASE" Definition="Base (server address) of the FHIR EHR system" DataType="text"/>
    <ReturnValue Name="MHSNOMEDCT" Definition="Medical history SNOMED-CT code from the EHR system" DataType="text"/>
  </MethodSignature>
  <FormalExpression Context="FHIR">
    <Code>{BASE}//Condition?subject={PATIENTID}&amp;=format=xml/code/coding[system/@value='http://snomed.info/sct']/code/@value</Code>
  </FormalExpression>"
</MethodDef>

but when and where are those arguments injected in the method call?