When a resource can have multiple values of a particular type (e.g., identifier, code, _tag, _security), one of the questions that has come up for me was the interpretation of :not.
This is made more challenging by virtue of the fact that different implementations handle it differently.
From a use case perspective, which is more interesting:
Given that patients often have multiple identifiers would you rather than:
Patient?identifier:not=999999999
Return a patient that did not have any identifier=999999999, or would you rather it returned a patient if any one of their identifiers was not 999999999? Frankly, I want the former.
Similarly for code, if Condition has an ICD-10 and SNOMED code, would you ask for Conditions that are not SNOMED code for Heart Attack to include all conditions that had any other code, or that ensured NO value of Code was the SNOMED code for heart attack. I want the latter.
This is the rationale behind a recent clarification in FHIR STU4, coming hot and heavy off the presses (see GET [base]/Composition?section:not=48765-2).
I'm all in favor of this, although I must admit to having had some struggles interpreting it. That's what ballots are for though.
Keith
This is made more challenging by virtue of the fact that different implementations handle it differently.
From a use case perspective, which is more interesting:
Given that patients often have multiple identifiers would you rather than:
Patient?identifier:not=999999999
Return a patient that did not have any identifier=999999999, or would you rather it returned a patient if any one of their identifiers was not 999999999? Frankly, I want the former.
Similarly for code, if Condition has an ICD-10 and SNOMED code, would you ask for Conditions that are not SNOMED code for Heart Attack to include all conditions that had any other code, or that ensured NO value of Code was the SNOMED code for heart attack. I want the latter.
This is the rationale behind a recent clarification in FHIR STU4, coming hot and heavy off the presses (see GET [base]/Composition?section:not=48765-2).
I'm all in favor of this, although I must admit to having had some struggles interpreting it. That's what ballots are for though.
Keith
No comments:
Post a Comment