Stream: implementers
Topic: Apgar; one general profile or per time point?
Pieter Edelman (May 20 2019 at 13:21):
We're in the process of creating a profile on the Apgar score, a test which consist of five assessments which are combined into a total score to determine the clinical status of a newborn child. We want to record these separate assessments as well as the total score, using a profile on Observation:
Observation - valueQuantity ... total score - component - slice RespiratoryScore - slice AppearanceScore - slice PulseScore - slice GrimaceScore - slice MuscleToneScore
Each of the component assessments as well as the total are coded using their own LOINC code. Now, this test is repeated at 1, 5 and 10 minutes after birth, and although the assessments are the same at each time point, the different time points are distinguished using different LOINC codes.
So the question arises if it is better to create a singe profile which can accommodate the three different time points, or to create three different profiles for the three different time points.
Both approaches have their merits and drawbacks. A single profile means less clutter, but you would need to add slices or valueset bindings on the respective .code elements to make all the LOINC codes available, and then probably throw in some constraints to make sure that the matching codes are selected (for example, that the '1 minute' codes are used in a single instance). Also, we would like to make the code use extensible, so we'd need to find a way that at least one of the three codes is used but that other codes (from different code systems) are allowed as well on each .code element. The approach with three separate profiles would be much cleaner in this respect.
Any opinions on what would be the best approach? Ironically, the Apgar score is used quite a lot to demonstrate how to model scores in FHIR, but practical profiles seem to be thin on the ground.
Grahame Grieve (May 20 2019 at 13:22):
@Eric Haas
Lloyd McKenzie (May 20 2019 at 14:43):
My expectation is that each APGAR timepoint would be captured as a distinct Observation instances. You could have a distinct profile for each, but a single profile should probably be ok. The differentiation would be by the LOINC code of the root Observation.code.
Eric Haas (May 20 2019 at 15:02):
I have created several different example instances in the spec for Observation. Largely based on the LOINC L Form. I thnk you have to decide if you want distinct observations or a single with component observations like the examples referenced above. In my experience no matter what you do there will be vehement opposiition from somebody. :-)
Alexander Henket (May 20 2019 at 15:48):
Note that this would be one more example of multiple bindings for Observation.code (panel 1, 5, 10 minutes), and Observation.component.code unless you create a ValueSet for each set of 3.
Pieter Edelman (May 22 2019 at 08:04):
I think the difficulty lies not in instances, but in profiling - we'd like to make specific profiles for the Apgar score. Since each different time point needs six different LOINC codes (on Observation.code and on .component.code for each of the five components), if you'd want to create a single profile, you'd have to:
- enforce that the component.codes match the main Observation.code for time point
- enforce that for each of the six .codes, exactly one of three provided codings is used
- make sure that other codings may be added for each of the six .codes
I'm not sure how to do this in a clean way that's obvious to users of the profile, which would suggest three different profiles is the better option. But then again, this feels a bit like overkill.
Lloyd McKenzie (May 22 2019 at 14:33):
Short answer is you can do it with 3 simple profiles or one fairly complex profile (where you'll have invariants and need to define value sets for each of the codes)
Last updated: Apr 12 2022 at 19:14 UTC
