FHIR Chat · Extensions - Coding · implementers

Stream: implementers

Topic: Extensions - Coding

jassy (Jul 15 2016 at 22:31):

I'd like to know how to create extensions for Coding in resources. For example, in resource ClaimResponse.item.adjudication.category, I like to add a code "coins". Should I just add a unique "system" with "code" in the resource directly, or should I create it through extension and what it will look like? Thanks
"item": [
{
"adjudication": [
{
"category": {
"system": "http://example/ValueSet/adjudication",
"code": "coins"
},
}
]
}
]}

Andy Stechishin (Jul 15 2016 at 22:39):

@jassy

Andy Stechishin (Jul 15 2016 at 22:42):

@jassy The adjudication category value set is defined as extensible, so adding another code in your profile should be permissable.

I am interested to know where 'coins' would fit in with total, copay, eligible, deductible, etc.

jassy (Jul 15 2016 at 23:01):

@Andy Stechishin I will look into profile additions. Regarding the reason of the additions, "coins (coinsurance)" is a very common and different type from "copay". It may be a good candidate to be included in the codeset.

Andy Stechishin (Jul 15 2016 at 23:06):

@jassy Indeed and I would suggest that as a ballot comment or just create a tracker. I did need to check that the value set was not example (which is only for building out the examples and not intended to be 'production quality') but in this instance it is extensible

Aleksandra Pavlyshina (Aug 20 2016 at 10:40):

I'm wondering how to use this Extension: The adoption status of the patient (http://hl7.org/fhir/StructureDefinition/patient-adoptionInfo) which is "Code indication the adoption status of the patient. Context of Use: Use on element: Patient".
In our application, we need to capture a question "Are you adopted? Yes/No".
First, it will be stored to a QuestionnaireResponse with answer of type valueCodeableConcept (system http://hl7.org/fhir/ValueSet/v2-0136, values "Yes/No").
Then what is the correct way to represent a patient's answer via this extension (if this extension was created for this purpose, probably it was intended to capture a patient's status to adopt a child)?
1) To store only the answer but it looks weird (e.g. adoptionInfo = Yes or No) as Yes/No answers are not a status.

"extension": [
 {
     "url": "http://hl7.org/fhir/StructureDefinition/patient-adoptionInfo",
     "valueCodeableConcept": {
         "coding": [
             {
            "system": "http://hl7.org/fhir/ValueSet/v2-0136",
             "code": <Y/N>,
             "display": <Yes/No>
            }
         ]
    }
 }]

2) Or to store the statement itself that the patient was adopted, and only in case of the positive answer, and also store as an Observation with LOINC code = 54128-4 "Adopted" and valueCodeableConcept = Yes/No from http://hl7.org/fhir/ValueSet/v2-0136?

"extension": [
 {
     "url": "http://hl7.org/fhir/StructureDefinition/patient-adoptionInfo",
     "valueCodeableConcept": {
         "coding": [
             {
            "system": "http://snomed.info/sct",
             "code": "160496001",
             "display": "Adopted (finding)"
            }
         ]
    }
 }]

Robert McClure (Aug 22 2016 at 17:09):

@Aleksandra Pavlyshina I suspect there is not perfectly correct answer to this, but IMO the fact that a patient is adopted is a finding, just like the fact that they are female. So I would choose that you use your last example with SCT concept 160496001. By doing this it simplifies finding this information in the patient reciord, compared to having to know what was the observation (or question) that holds the answer you want. As for the LOINC observable 54128-4 "Adopted" - I think this is bad form and would be just like crafting an observable "Female" or even "Diabetic".

Aleksandra Pavlyshina (Aug 23 2016 at 12:20):

@Robert McClure In our application, there is a Home Assessment consisting of a bunch of questions like:

• Does the patient need ambulatory assistance in their home? Yes/No
• Does the patient need assistance with cooking meals? Yes/No
  Each unfavorable answer should result in creating later an Issue (in Issue/Goal/Action/Outcome model).
  My initial thought was to capture this assessment as QuestionnaireResponse and then create ClinicalImression (representing Home Assessment) with multiple Observations representing answers to the questions, e.g. SNOMEDCT code = 301887005 | Needs assistance at home (finding) or 400986007 | Needs help with cooking (finding), and valueCodeableConcept = Yes/No from http://hl7.org/fhir/ValueSet/v2-0136, so that we could create and bind our Issues (Conditions) to the corresponding Observations. But now I see that this indeed is a bad form for observables. How do you think what would be a correct approach in this case? And what would be a correct approach in general for such findings done in a form of some statement (like "Unsafe stairs in house (finding)", "Hazards in the home (finding)")?

Robert McClure (Aug 24 2016 at 23:06):

@Aleksandra Pavlyshina the approach I would take is that the observable you are performing is a couple of things that have to do with Activities of Daily Living. I'm not saying you need to actually encode that but it helps put things into perspective. So you are providing a series of findings based on that general observation perspective. Your questionare is essentially a series of pairs of identified findings. Sometimes the pairs are pretty easy to determine and even find in SCT, such as 400986007 | Needs help with cooking (finding) pairs with 710763006 | Independent in cooking (finding). But I suspect others would be a bit more difficult to craft. But once you've done this you can see how recording each as a finding provides the patient data store with much more accesable and rich content. Do you agree?
425205008 | Unsafe stairs in house could be a simple "unpaired finding" but you also have 301588006 | Able to manage stairs (finding) that provides additional information. I'd agree that it's not a direct opposite of the former, but understanding that you are looking to record findings, not yes/no to complex "states" gives you some freedom, plus there are a host of other concepts in that area of SCT that provide more "stairs assessment" so could be allowed as nuanced answers in the questionair.
Thoughts?

Aleksandra Pavlyshina (Aug 25 2016 at 20:42):

@Robert McClure I do agree. So, if my understanding is right, I need to find a corresponding concept for Observation.code and two most appropriate concepts for Yes/No answers, e.g. for the question 'Does the patient need assistance with grooming?' there will be Finding related to ability to perform personal grooming activity (finding) SCTID: 704433000 and answers Difficulty performing personal grooming activity (finding) SCTID: 704439001 for 'Yes' and Able to perform personal grooming activity (finding) SCTID: 704441000 for 'No', and Observation.category will be 'survey'. Probably I need to specify the original question in the Observation as codableConcept.text?
Can I ask you what do you thing about the approach in general: to store asnwers in a QuestionnaireResponse, then create Observations and reference them in the ClinicalImpression.investigations.item (e.g. for this case it can have ClinicalImpression.investigations.code = 'Activity of daily living needs assessment (procedure) SCTID: 422533001'), then for unfavorable Observations create Conditions (category = 'problem' from http://argonautwiki.hl7.org/index.php?title=Problems_and_Health_Concerns) and reference the corresponding Observations?

Robert McClure (Aug 25 2016 at 22:45):

Actually, no, you don't want to use the SCT grouping code Finding related to ability to perform personal grooming activity (finding) SCTID: 704433000 as the observable. That code is a "finding" but really is there simply to group the codes it subsumes. What you really want is to represent an observation, we say an "observable." While SCT does have observables, we want to use LOINC codes if possible. There are a couple in LOINC but this places us squarely into an area that is muddy at the moment - in fact the clinical LOINC meeting happening at this moment will discuss this tomorrow. So I might have a more authoritative answer next week, would that work?

Are you doing this for use in the US? I ask because there is another wrinkle - the IMPACT act dictates that CMS wants many ADL-type assessments plus skin and wound assessments to be uniformly collected. This is part of the discussion going on at the LOINC meeting. So if you want to use this in the USA, you should work to align with what ever IMPACT is doing.

Aleksandra Pavlyshina (Aug 26 2016 at 08:29):

@Robert McClure Yes, this definetly would work, thank you very much for your help. Yes, we are doing this for use in the US (palliative care management application).

Robert McClure (Aug 30 2016 at 19:20):

@Aleksandra Pavlyshina The LOINC meeting last week clarified the use of individual concepts (an observable question in this case) drawn from a surevey instrument (a panel.) They clarified that an individual question that is part of a survey instrument CAN be used to represent that observation made outside of the survey. There are two requirements that must be satisified when this is done (this is true of the use of a single code, or the entire survey): 1) The instrument using the LOINC concept (such as the tool you are creating) must include attribution of the survey as the source of the code (in addition to LOINC in general) (see https://loinc.org/downloads/files/hl7-lint-setup/loinc-and-relma-copyright-and-terms-of-use), 2) If the observable has a Normative answer set, the recorded result must be drawn from the normative list. This means if you find a LOINC observable that matches your needs, you can use it to represent "the question asked/observation noted." Of note, when someone follows your guide and makes patient records based on it, when they record the LOINC codes in patient data, they don't have to carry the survey attrribution in the file.

If you find that the LOINC observable you want (remember it must align with the meaning you want to represent) is in LOINC BUT it has a normative answer list you don't want to use, you will need to request a new LOINC code.

Based on the ADL template in C-CDAR2 r2.1 and this discussion we have tentitvely proposed new LOINC codes for the following "self care" observables:
Bathing
Dressing
Toileting
Feeding or Eating
Transferring
Ambulation

The presumed answers for any of these will be the following set of SCT codes:
SCT code FSN Display
371150009 Able (qualifier value) able
371153006 Independently able (qualifier value) independent
371155004 Able to and does (qualifier value) able to and does
371152001 Assisted (qualifier value) assisted
371154000 Dependent (qualifier value) dependent
371151008 Unable (qualifier value) unable
371156003 Does not, dependent (qualifier value) does not
371157007 Has difficulty doing (qualifier value) difficulty
385640009 Has difficulty doing (qualifier value) does

I'm not clear (yet) as to how well this LOINC proposal that directly aligns with C-CDAR2 r2.1, aligns with what the IMPACT act will expect, but I hope they will align.

Grahame Grieve (Aug 30 2016 at 20:56):

"The instrument using the LOINC concept (such as the tool you are creating) must include attribution of the survey as the source of the code" - it's not clear to me what that actually means. can you expand?

Robert McClure (Sep 01 2016 at 20:50):

@Grahame Grieve This is what I have been told by the LOINC committee. I'll have to do some sluthing to determine the particulars but I understand that this is described in the LOINC IP expectations and I suspect it would say something like "These codes are a part of the xxx survey instrument" plus whatever that instrument has as it's attribution string.

Grahame Grieve (Sep 01 2016 at 21:27):

I don't know how they expect that to work in CDA and FHIR....

Robert McClure (Sep 10 2016 at 17:07):

Well, you should have a sit down with Dan, and the IHTSDO folks, plus we at the HTA need to hear your thoughts. You've a very creative set of folks so I'm sure you'll figure something out ;-)

Grahame Grieve (Sep 12 2016 at 18:09):

we prefer to solve real problems, not manufactured ones. My opinion is that the definitions of the codes should establish the linkage, and it should not be necessary to mention this fact in the instrument where the codes are being used

Robert McClure (Sep 15 2016 at 19:24):

@Grahame Grieve That simply makes no sense. I have no idea how "the definitions of the codes should establish the linkage" solves this requirement.
@Daniel Vreeman We should discuss. Seems there is no interest in documenting the provenance of LOINC questionair codes here on FHIR objects.

Grahame Grieve (Sep 15 2016 at 20:10):

so I use code LOINC xxx-x which is associated with a particular survey instrument in an observation - and observe a value for that code. that's the context we're talking about, right?

Last updated: Apr 12 2022 at 19:14 UTC