3

The FHIR schema defines very generic Resources that would sometimes represent several concepts in an implementation and the meaning of the resource is difficult/impossible to determine from the object itself. For example the Condition resource may represent a problem on a problem list, an admission diagnosis, a final diagnosis, a primary diagnosis, etc. The meaning of the Condition depends on know which of these it is. Is there a way to make this explicit in FHIR?

In some cases a Profile StructureDefinition could be used to distinguish between specializations of a Resource, but this doesn't work for things like final vs. admit diagnosis since these contain the same data (i.e. there is no discriminator) and so it is not a general solution.

Scott Thibault
  • 329
  • 2
  • 4
  • 12
  • how does the meaning differ? or is it just the use? A condition might be used from multiple places, and it's context matters. denormalising the context into the resource could make it less usable. Perhaps you could explain a little more...? – Grahame Grieve Oct 23 '15 at 19:47
  • You do need to have some context information to correctly interpret the meaning of the condition. I would like to make some of that context more directly available. I don't know how that would make it less useful. For example, a simple category field in the condition could give you some of that context. – Scott Thibault Oct 27 '15 at 15:22

1 Answers1

2

Profiles never change the meaning of an instance, they simply identify constraints that an instance adheres to. If you stripped out all profile ids from an instance, you could put them back if you had access to all of the eligible profiles and compared them against the instance.

Admission diagnosis or final diagnosis isn't a type of diagnosis, rather it's the relationship of a diagnosis to a particular encounter. A diagnosis that is the final diagnosis of one encounter might be the admission diagnosis for another. A Condition might be included on a problem List whether it's a complaint, symptom, finding or diagnosis. The notion of primary vs. secondary is also a relationship with respect to an encounter/billing. The primary diagnosis for encounter A might be a secondary diagnosis for encounter B.

Look at Encounter.admittingDiagnosis, Encounter.dischargeDiagnosis and Claim.diagnosis.sequence to differentiate admission/discharge and primary.

(It would probably be good to include this guidance on the Condition resource itself, so feel free to submit a change proposal using the link at the bottom of the spec :>)

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • I am aware of the encounter relations, but that does not really help differentiate the condition when I have just a list of conditions, which is what I would really like to do. Obviously one could follow the encounter reference and search the respective lists the condition, but that's not great. – Scott Thibault Oct 23 '15 at 16:32
  • Can you explain why differentiating whether a condition has been referenced as an admitting diagnosis or discharge diagnosis would be relevant to you when looking at a list of conditions? – Lloyd McKenzie Oct 23 '15 at 20:27
  • In research and monitoring applications we often start with a definition of the cohort of patients that we are interested. These definitions often involve statements like patients with a discharge diagnosis of X. – Scott Thibault Oct 27 '15 at 15:15
  • But how is the fact it's a discharge diagnosis vs. an admitting diagnosis vs. just a "diagnosis" relevant to your use-case (outside the context of a specific encounter) – Lloyd McKenzie Oct 27 '15 at 18:27
  • To build the cohort, I would be looking through all observations in the database looking for a final diagnosis of some sort. – Scott Thibault Oct 28 '15 at 18:19
  • But what constitutes a "final" diagnosis? A discharge diagnosis isn't necessarily a confirmed diagnosis, and an admitting diagnosis isn't unconfirmed. The reliability of the Condition assertion is communicated in verificationStatus. Would that not meet your use-case? – Lloyd McKenzie Oct 28 '15 at 21:57
  • The FHIR documentation describes the dischargeDiagnosis as a final diagnosis. But to the original point, it was just an example. The cohort definition could just as easily be patients with an admitting diagnosis of X or an encounter indication of Y. – Scott Thibault Nov 04 '15 at 13:43
  • Final doesn't necessarily mean "confirmed" :) In any case, if you're looking for diagnosis that are tied to an encounter, then you'll have to query through encounter. The same Condition might be a discharge diagnosis for one encounter and an admitting diagnosis for another, so it's not something that's really appropriate to live on the Condition itself. If the cohort requires an admitting diagnosis or discharge diagnosis (as opposed to 'suspected' or 'confirmed' diagnosis), then the cohort query will need to use both resources. – Lloyd McKenzie Nov 04 '15 at 17:40