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

General Feedback - NCPI Condition using Observation rather than Condition is confusing #66

Open
mholck opened this issue Oct 29, 2024 · 5 comments
Assignees
Labels
Phenotype/Condition Module Tasks or issues related to the Phenotype/Condition Module

Comments

@mholck
Copy link

mholck commented Oct 29, 2024

What were you reviewing?

NCPI Condition Profile

Feedback:

Why is NCPI Condition profiling Observation rather than Condition? I get that it is an assertion but Condition can be used for asserted conditions as well and Condition already has things like OnsetAge, AbatementAge, Stage, and BodySite that are being added to Observation by the NCPI Condition profile. If we continue to use Observation perhaps it should be renamed to not confuse implementors or overload the term Condition.

Review Date:

Oct. 11, 2024

@mingward
Copy link

mingward commented Nov 13, 2024

We agree with mholck above. May we propose that we use both Condition and Observation? Use Conditions for medical conditions such as HPO terms. And observations for other subject and phenotypic and observable values and measurements?
Another issue of using the IG2 proposed NCPI condition is raised here: #72

@JamedFV JamedFV added the Phenotype/Condition Module Tasks or issues related to the Phenotype/Condition Module label Nov 15, 2024
@RadixSeven
Copy link

RadixSeven commented Dec 10, 2024

Summary of some discussion - Main reason not to use Condition is that one cannot say "someone does not have condition".

@mingward
Copy link

Indeed to Eric's comment above.

Also trying to capture the discussion at 11am FHIR meeting today: Robert mentioned an option in which we use both NCPI Condition profile(based on FHIR Observation) and Condition:

  • A. We put all clinical condition and phenotype data in NCPI Condition(based on FHIR Observation)
  • B. We also put all positive assertions in Condition. This (B) can be optional. But if repositories can do this, it may benefit users of the data, especially if on a FHIR implementation, fetching the condition data from Observation is not as easy and fast.

By the way, just a note here in case anyone is curious. Condition resource page also listed two exceptions of handling "Assertions of Condition Absence". Here is the specific link: https://www.hl7.org/fhir/condition.html#:~:text=Generally,%20electronic%20records%20do%20not%20contain

@mingward
Copy link

What do people think of the language below in https://www.hl7.org/fhir/observation.html under section "10.1.2 Boundaries and Relationships ":
The Observation resource should not be used to record clinical diagnosis about a patient or subject that are typically captured in the Condition resource or the ClinicalImpression resource.

@RadixSeven
Copy link

@mingward That is consistent with what I observed in Assertions of Condition Absence. FHIR intends us to put positive assertions in Condition and negative assertions in Observation. But we are recording something subtly but significantly different from their assertions, so their guidance does not hold completely. We need to decide what to do with our data in a way that will be most legible to our users.

Condition vs Observation

The Condition resource is intended to record one occurrence of a medical condition in the context of health seen as a process. It says when it starts and when it abates (if it has abated). The same pregnancy is intended to be in only one Condition resource per patient. That resource should be updated when the subject gives birth to have the status "refuted" and to set the abatement[x] field. Two Condition resources would imply two different pregnancies.

However, Observation resources are intended to be point-in-time assertions. Though the effectivePeriod field allows for some time-extended semantics, the standard does not intend for users to update the Observation resource to track the ongoing development of whatever was observed.

Observation matches our semantics better

Our research subjects' diagnoses are closer to Observation than to clinical diagnoses intended to persist throughout the patient's care. They record merely that someone in the study asserted that was present in the subject at the time covered in the study. However, they are not intended to be used in ongoing care.

The semantics are different. If ResearchStudy S1 says that Person P1 has Condition C1 and ResearchStudy S2 says the same thing, two Condition resources might imply two occurrences. On the other hand, two Observation resources do not. They record two observers making similar observations.

Imagine further a hypothetical study with two variables, "Pregnant at visit 1" and "Pregnant at visit 2." The variables can take the values "Pregnant" and "Not Pregnant." If we capture these as two Condition resources, that would typically mean two pregnancies. However, that is different from what the study is recording.

So, I believe that what we are capturing is not "clinical diagnosis about a patient or subject that are typically captured in the Condition resource or the ClinicalImpression resource." The FHIR standard assumes these diagnoses persist and are reused. Instead, we record a point-in-time assertion by a clinician. So, Observation would seem to be the appropriate receptacle.

Further steps

Although Observation matches better, its matching is a subtle point that is easy to miss, and a simple reading of the standard would deny us the use of Observation. This could be a real usability problem since users might look in Condition. And if we did put it there, they might be confused because of the durative semantics of Condition.

Whatever representation we decide on will differ from the standard in some respects. To avoid misunderstanding, we should prominently note the deviation in the IG.

We might want to run this by the Orders and Observations committee to see if we can insert an exception into the next FHIR version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Phenotype/Condition Module Tasks or issues related to the Phenotype/Condition Module
Projects
Development

No branches or pull requests

4 participants