Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create observation abstract class #148

Open
wdduncan opened this issue Nov 9, 2021 · 5 comments
Open

Create observation abstract class #148

wdduncan opened this issue Nov 9, 2021 · 5 comments

Comments

@wdduncan
Copy link

wdduncan commented Nov 9, 2021

The model has many types of observation classes. E.g.:

  • AlcoholExposureObservation
  • CancerGradeObservation
  • HistologicalCompositionObservation
    etc.

In scenarios like this, there is often an abstract parent class that the children inherit from. Wondering why this isn't the case here ...

From a more pragmatic standpoint, having such a parent class may allow for easier querying of all observations.

@bfurner
Copy link
Contributor

bfurner commented Nov 9, 2021

generally "inheritance" is useful in situations where there is need to extend attributes/methods of a base class, and "profiling" is used in situations where there is need to constrain attributes/methods of a base class.

Observation and the various Observation implementations (e.g. CancerGradeObservation) are trying to address a profiling, or constraining, use case. the "base" Observation entity defines a number of different "value" attributes to hold values of different data types (e.g. value_integer, value_string, value_codeable_concept, etc.) but a given implementation (e.g. CancerGradeObservation) only needs to implement the "value" attribute appropriate to its use case. in the case of CancerGradeObservation, this is value_codeable_concept which is typed as a CodeableConcept. in the case of DimensionalObservation, this is value_quantity which is typed as a Quantity. theoretically we could have a base class that defines a single 'value' attribute that can take more than one data type and then inherit from this base class and specify the particular data type at the child level.

happy to talk through this in an upcoming DMH meeting especially to see what is supported by LinkML

@wdduncan
Copy link
Author

wdduncan commented Nov 9, 2021

@bfurner Not sure I follow what you mean by "profiling". Do you have link to a design pattern? From what I could tell there are a common set of attributes that observation of attributes that are shared.

Regarding values please see comment #150.

@wdduncan
Copy link
Author

wdduncan commented Nov 9, 2021

@bfurner I just saw that there is a class Observation. Sorry ...

However, the documentation does not show any linkage between a specific kind of observation (e.g., alcohol exposure observation) and Observation (which is why I missed it).

Is there supposed to be one? By profiling maybe you mean something like composition, but I'm not sure. Or perhaps you mean something like an interface? If so, then having observation as a mixin would be useful.

@bfurner
Copy link
Contributor

bfurner commented Nov 9, 2021

@wdduncan see the following from FHIR: https://www.hl7.org/fhir/profiling.html

there currently is no linkage between the generic Observation and the "profiled" subtypes as this functionality isn't supported at this point in LinkML as far as i know.

in FHIR, there is a generic Observation (https://www.hl7.org/fhir/observation.html) that defines a value[x] that can take different value data types that get defined in individual profiles. for example, BodyWeight profiles Observation. https://www.hl7.org/fhir/bodyweight.html

@cmungall
Copy link
Contributor

cmungall commented Nov 9, 2021

I've put this on the agenda for the LinkML call, I don't want to give any recommendations here before being fully appraised by others

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants