FHIR Chat · Laterality Value Set(s) · terminology

Stream: terminology

Topic: Laterality Value Set(s)


view this post on Zulip Mark Kramer (Oct 23 2019 at 17:44):

There seem to be two value sets that could be used for laterality: http://hl7.org/fhir/ValueSet/bodysite-laterality and http://hl7.org/fhir/ValueSet/bodystructure-relative-location. Neither is ideal because they both contain inactive SNOMED-CT codes (419161000 and 419465000). The first is missing some laterality concepts and the second has some non-laterality concepts. The question is: should we fix the existing laterality value set or create our own?

view this post on Zulip Grahame Grieve (Oct 23 2019 at 17:51):

for mCode? or for something else?

view this post on Zulip Mark Kramer (Oct 23 2019 at 17:51):

It is for mCODE, yes.

view this post on Zulip May Terry (Oct 23 2019 at 17:53):

Our primary interest is for mCODE, although I can see it affecting other use cases (e.g.: Surgery and Radiology procedures) which might need to specify laterality.

view this post on Zulip Grahame Grieve (Oct 23 2019 at 17:53):

so fixing the source in FHIR won't help on your timeframe. That means that you have to define your own. But we don't want to add yet another value set. So can CIMI, OO, and II work together to agree on the right value set? These are both example value sets, so I expect that they're very easily changed

view this post on Zulip Grahame Grieve (Oct 23 2019 at 17:54):

but do you want laterality or relative location? they are not the same thing

view this post on Zulip Mark Kramer (Oct 23 2019 at 20:22):

We currently have laterality and anatomical orientation as two separate elements. We don't have a concept of relative location, but we use a concept of location relative to a landmark, which is a more complex concept involving a landmark type, landmark body location, and a distance and direction from that landmark to the body site of interest. In cancer, the landmark could be the left nipple, the distance 5 cm, and direction could be 11 o'clock.

view this post on Zulip Grahame Grieve (Oct 23 2019 at 20:24):

is that consistent with the BodyStructure resource?

view this post on Zulip Eric Haas (Oct 24 2019 at 20:49):

What mark is doing aligns more with openEHR and the original bodysite resource: http://hl7.org/fhir/2015Jan/bodysite.html

view this post on Zulip Lloyd McKenzie (Oct 25 2019 at 00:32):

It should come more in-line with the current BodyStructure resource (or the BodyStructure resource should evolve to meet @Mark Kramer's needs. We don't want to be using extensions to define body location when we have a resource specifically intended for that purpose.

view this post on Zulip Mark Kramer (Oct 25 2019 at 00:48):

@Grahame Grieve we have to change BodyStructure considerably to fit our needs. It doesn’t give much advantage to start from there. Extending bodySite is more logical.

view this post on Zulip Mark Kramer (Oct 25 2019 at 00:50):

Giving the implementer a choice between a single code or an extension that references a different resource seems very awkward.

view this post on Zulip Mark Kramer (Oct 25 2019 at 00:51):

It seems much better to say the code is always in body site and there may be an extension that modifies or enriches the meaning of that code

view this post on Zulip Grahame Grieve (Oct 25 2019 at 01:02):

I think you should discuss with the OO committee on #Orders and Observation WG - this isn't really a terminology issue, and they are the ones who defined it that way. I agree with Lloyd: we do not want implementation guides published through HL7 ignoring the existing models and creating alternative realities

view this post on Zulip Lloyd McKenzie (Oct 25 2019 at 01:04):

@Mark Kramer , given that you're talking about a tumor or lesion that's going to need multiple Observations (and maybe Procedures) tied to it over time, you really should be using the resource. That's the only way you can link everything that's been said about/done to the tumor/lesion over time. If you're not happy with how BodyStructure defines things, extend it as needed and submit change requests.

view this post on Zulip Mark Kramer (Oct 25 2019 at 01:35):

@Lloyd McKenzie, a tumor could be viewed as body structure or a condition. Multiple Observations can be tied to a BodyStructure, (through focus), but Procedures can only be tied to Condition | Observation | Procedure | DiagnosticReport | DocumentReference.

view this post on Zulip Lloyd McKenzie (Oct 25 2019 at 02:00):

Procedures can be tied to BodyStructure in the same way that Observations can - one of the main reasons for BodyStructure was to allow repeated observations of the same tumor/lesion/fetus/etc. The Condition may well be associated with multiple tumors/lesions. (Or in the case of pregnancy, multiple fetuses)


Last updated: Apr 12 2022 at 19:14 UTC