Stream: C-CDA
Topic: Functional Status Observation template
Vassil Peytchev (Apr 21 2021 at 21:30):
I've got a question raised by a group which is trying to map some of the requirements for post-acute care systems into C-CDA structures. It is about the definition of the Functional Status Observation (v2) Entry.
The required Observation.code is 54522-8 , and there is a required value element. The first problem is that this LOINC code is a panel code, and as such the required observation.value cannot be reasonably satisfied. It seems that in this case a nullFlavor of NA is the appropriate value for this observation.
Within the functional status panel, there are actual assessments that can have values, so the second question is whether the assessments that are not on a scale (and therefore cannot be expressed as an Assessment Scale Observation components) can be expressed as just a Result Observations. An example is as follows:
<entry>
<observation classCode="OBS" moodCode="EVN">
<!-- Functional Status Observation (V2)-->
<templateId root="2.16.840.1.113883.10.20.22.4.67" extension="2014-06-09"/>
<id root="b63a8636-cfff-4461-b018-40ba58ba8b32"/>
<code xsi:type="CD" code="54522-8" displayName="Functional status" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC">
</code>
<text>Some narrative text</text>
<statusCode code="completed"/>
<effectiveTime value="20050501"/>
<value nullFlavor="NA"></value>
<entryRelationship type="COMP">
<observation>
<!-- Generic Result Observation (V3)-->
<templateId root="2.16.840.1.113883.10.20.22.4.2" extension="2015-08-01" />
<id root="7c0704bb-9c40-41b5-9c7d-26b2d59e234f" />
<code xsi:type="CD" code="83216-2" displayName="Sit to Lying" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<statusCode code="completed"/>
<effectiveTime value="20050501"/>
<value xsi:type="CD" code="LA27993-7" displayName="Independent - Resident completes the activity by him/herself with no assistance from a helper." codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"></value>
</observation>
</entryRelationship>
</observation>
</entry>
Any opinions why that is, or isn't a good approach?
Gay Dolin (Apr 23 2021 at 20:04):
HI Vassil, I think your example is an OK way to handle what you want to do. If indeed the LOINC rule about panel codes is a strong rule with non-lab LOINC (makes sense with lab LOINC).
But maybe it would be better to use the Functional status organizer (http://www.hl7.org/ccdasearch/templates/2.16.840.1.113883.10.20.22.4.66.html) that could appropriately use the LOINC panel code="54522-8" displayName="Functional status" in organizer/code and then have the component question/answers - which in reality probably will be a set of questions in a system rather than a single one (but could just have one). And maybe would be better as an ADL activity ... but I fear we may open a can of worms there too with the LOINC codes used....
In addition, if the rule you state in LOINC is a hard and fast rule in LOINC even for non lab LOINCs - we should check with the LOINC folks - because, then I think we have an errata in C-CDA.
In the IG, we have (as you stated), a "SHALL contain a value, and in addition a SHOULD be from SNOMED CT) with an example that shows functional status having a SNOMED CT answer.
Vassil Peytchev (Apr 24 2021 at 02:41):
Hi Gay,
If I am reading the specifications correctly, the Functional Status Organizer requires the Functional Status Observation, so we still have to deal with that (leave it hanging without a value or components, and have the Result observations as siblings?)
Your explanation of using a SNOMED code as a value clarifies the intent of the Functional Observation requirement, and I don't know if it would be forbidden by LOINC just because the LOINC code is a panel. Unfortunately this will create a burden on the systems providing the data - post-acute care providers are bound by CMS requirements to report the functional status using various LOINC codes, and use the LOINC answers (as in the example above). Having to map each LOINC code and answer to a SNOMED code is probably not feasible as a solution.
Gay Dolin (Apr 28 2021 at 17:15):
Certainly agree that the Functional Status templates in C-CDA need design changes overall - they were built in a time where there was "less focus" and implementer interest on the long term care domain. LOINC codes and panels for same have matured. I'm not sure we can call it an errata - given that was the knowledge at the time - but definitely would suggest entering a C-CDA JIRA tracker. There are lots of things converging in C-CDA (e.g web publishing and STU Comment --> JIRA mgt) but we do hope that we can do a new version ballot of priority areas sometime in the future. In the meantime - I wonder if you would like to discuss on the Examples Tsk force
Daniel Vreeman (May 05 2021 at 15:37):
There is/was an errata already...I submitted it back in Feb 2015 http://www.hl7.org/dstucomments/showdetail_comment.cfm?commentid=584. That LOINC should never have been used in this context and we created one "back in the day" that could be/should be (75276-6). Plus, this issue of not being able to send regular Observation results was noted in that same errata. I submitted the errata, but prior to that they were also discussed and approved at the Clinical LOINC meeting (2015 02). FYI, there are other errata in the tracker with similar issues (e.g. on the Advanced Directives Organizer).
Daniel Vreeman (May 05 2021 at 15:42):
Sorry, there is/was "STU Tracker" item posted, not an errata published.
Last updated: Apr 12 2022 at 19:14 UTC
