Observation Resource for Oncology use case

#1

Hi there,
I have a use case where I need to transfer Oncology data (more precisely tumor data) to FHIR structures. Since there are some deviations from the mCode standard, I have chosen to create my own profiles.

In my case, the user interface has a form where various fields about the tumor are entered. For example, some of them: “TNM Classification type”, “Tumor TNM – value”, “Histological grade of the tumor”, “Date of detection of distant metastases”, “Tumor stage FIGO” and many others - a total of 15 different fields.

I have found that the most appropriate FHIR resource to store these data fields would be Observation. And I also have found the fact that in FHIR, every ‘statement’ that can be made and used independently is put into its own separate instance.

In this case, I would end up with 15 different Observation documents in JSON format, which incurs some data overhead. Is there any way or approach to reduce the number of instances to be created? If I understand correctly, it is not possible to use slice and assemble these 15 elements within one observation.

1 Like
#2

Multiple Observations is the norm - because any one of those statements might need to be sent and retrieved independently in the future. This does incur some overhead, but it’s balanced by the improved flexibility in use of the data.

3 Likes
#3

How about define a profile specifically for Tumor, and do slicing in “component” element to put various fields about the tumor inside component’s element. Such as this example of Observation profile for BloodPressures that will record the systolic & diastolic measurements. ProfilingAcademyTasks | BloodPresssureLOINC - SIMPLIFIER.NET

#4

Observation.component is intended for information that isn’t stand-alone from each other, it’s not for arbitrary grouping. Most of the examples provided sounded like independent assertions rather than qualifiers or inseparable parts, so using component wouldn’t be appropriate.