Stream: CARIN IG for Blue Button®
Topic: NUBC Point Of Origin
Melissa Benzie (Nov 30 2020 at 14:38):
The ExplanationOfBenefit 'supportingInfo:pointoforigin' slice has a required binding to the NUBC Point Of Origin code system: http://hl7.org/fhir/us/carin-bb/STU1/ValueSet-AHANUBCPointOfOriginForAdmissionOrVisit.html. Specifically that value set definition specifies the 'FL 15 - Point of Origin for Admission or Visit'. This code system contains duplicate codes for Newborn and Non-Newborn values.
For Example, these 2 values use the same code:
5 - TRANSFER FROM A SKILLED NURSING FACILITY (SNF), ASSISTED LIVING FACILITY (ALF), .. (NON-NEWBORN)
5 - NEWBORN - BORN INSIDE THIS HOSPITAL (NEWBORN)
The IG only defines one system uri: https://www.nubc.org/CodeSystem/PointOfOrigin, so how should we handle this when the codes are duplicate in this case?
Spencer Kathol (Nov 30 2020 at 17:01):
I don't have access to the primary nubc documentation, but from what I turned up on google, it seems like if Admission Type (http://hl7.org/fhir/us/carin-bb/STU1/ValueSet-AHANUBCPriorityTypeOfAdmissionOrVisit.html) is actually 2 code sets in one... If Admission Type is 4 (Newborn), then the newborn-specific codes are in effect for Point of Origin. Otherwise the non-newborn code set is used.
http://valueoptions.com/providers/Forms/Administrative/Tips_for_Completing_the_UB04.pdf
Scott Favre (Nov 30 2020 at 17:43):
Right, but that still leaves conflicting codes in the https://www.nubc.org/CodeSystem/PointOfOrigin code system. We can't have two codings with a code of 5 in the same code system.
Spencer Kathol (Dec 01 2020 at 10:28):
Right... I expect this will present a challenge for many platforms, but that's how I'm interpreting the spec as currently written. It seems strange that nubc made the decision to overload codes in that code system.
Scott Favre (Dec 01 2020 at 15:33):
Quoting the FHIR spec at https://www.hl7.org/fhir/datatypes.html#Coding
If two codings have the same system, version and code then they have the same meaning.
So 'supportingInfo:pointoforigin' is currently impossible to implement as specified since there are two different meanings for 5.
We need either a different system for the newborn-specific codes or a different code. Mangling the code to something like 5-newborn is a terrible idea, using a different system seems like it is much more correct (they are even listed in different tables in the very useful PDF you posted).
Could we use something like https://www.nubc.org/CodeSystem/PointOfOrigin/Newborn for those codes?
It won't address any issues of data from a EOB feed/db being ambiguous, but would make it possible to express in FHIR.
Scott Favre (Dec 01 2020 at 15:55):
I suppose we could make the 5 and 6 codes ambiguous themselves by combining the displays like "transfer from a snf/newborn born inside this hospital" then consuming systems would need to look at "supportingInfo:admtype.code" to determine what a 5 or 6 means.
Robert McClure (Dec 02 2020 at 03:53):
Folks, stumbled onto this. When you have an issue like this reach out to the vocab community - we're here to help ;-). Since this is an external code system HTA is also on the field (@Carol Macumber .) Since I can't really see the content completely (thanks for the http://valueoptions.com/providers/Forms/Administrative/Tips_for_Completing_the_UB04.pdf link!) I'm making some guess here but I think the right solution will be to recognize that the POA filed really uses two different code systems for exchange, based on if the patient is a newborn or not. NUBC (AHA) made an assumption that each field had only one code system and we assumed they were right, but you found out they were not in this case. Can you also tag the person that did the work on this IG? I'll tag @MaryKay McDaniel because she's always a help here...
Melissa Benzie (Dec 02 2020 at 13:31):
thanks @Robert McClure . tagging @Amol Vyas , not sure who else may be responsible for this particular IG requirement.
Carol Macumber (Dec 02 2020 at 14:15):
The NUBC Point of Origin code system information registered with HTA was adjusted based on comments by AHA. @Terrence Cunningham could you comment as the newborn vs non-newborn coverage in FL15 came up in the comments that @Pat Taylor shared with HTA. Thanks in advance.
MaryKay McDaniel (Dec 02 2020 at 19:16):
Hi all,
I'm really not trying to be dense or come across snippy, but I'm not following the ask or suggested fix.
I understand the issue = one 'value' has 2 definitions. The code doesn't change, the definition of the code does. This is not the only code system/code set within the claims world to do this... The definition is based on more than 1 item. In this case:
If the Priority (Type) of Admission = “4” (definition “Newborn”)
Then a “5” in the Point of Origin for Admission or Visit description is “Born Inside This Hospital”
Else "5" = Transfer from a Skilled Nursing Facility (SNF)....
Not defending or condeming what we have - it is what we have and we work with it today.
I'm not sure I understand the question, "The IG only defines one system uri: https://www.nubc.org/CodeSystem/PointOfOrigin, so how should we handle this when the codes are duplicate in this case?" How do you handle it where?
And is the ask for the IG developers to create a 2nd value set from the original code system - one for newborn admissions and one separate? The code - "5" will be the same but because it comes from 2 separate value sets you could derive the definition?
Thanks for any clarity!
MK
Scott Favre (Dec 02 2020 at 20:01):
And is the ask for the IG developers to create a 2nd value set from the original code system - one for newborn admissions and one separate? The code - "5" will be the same but because it comes from 2 separate value sets you could derive the definition?
Almost. Because there are distinct meanings for 5 and 6 there are actually two code systems for FL15 (one for newborn and one for nonnewborn).
So we would need a separate code system for newborn (only contains the 5 and 6 codes with their "born in hospital"/"born outside hospital" definitions).
To be super explicit without completely sharing the source file:
https://www.nubc.org/CodeSystem/PointOfOrigin would contain the 1-9 and A-Z non-newborn codes (5 = "transfer from SNF", 6= "transfer from another facility")
https://www.nubc.org/CodeSystem/PointOfOrigin-Newborn would contain just 5="born inside this hospital" and 6="born outside this hospital"
The value set http://hl7.org/fhir/us/carin-bb/ValueSet/AHANUBCPointOfOriginForAdmissionOrVisit would then contain all of the codes from both code systems.
Melissa Benzie (Dec 03 2020 at 15:21):
MaryKay McDaniel said:
I'm not sure I understand the question, "The IG only defines one system uri: https://www.nubc.org/CodeSystem/PointOfOrigin, so how should we handle this when the codes are duplicate in this case?" How do you handle it where?
As a consumer of the Fhir ExplanationOfBeneifit resource, when we read in the supportingInfo.pointoforigin codeable concept, how do we differientiate which NUBC code that the duplicate code (5) refers to? Reading your explanation above, It sounds like we would need to also look at the supportingInfo.admittype codeable concept and do some logic that is specific to NUBC coding.
Paul Knapp (Dec 03 2020 at 18:32):
This valueset should refer to the two codesystems noted above then each of the code '5's would have its respective codesystem so that together there is no ambiguity.
Pat Taylor (Dec 22 2020 at 13:10):
The CARIN team's recommendation is as follows. A Jira ticket will be entered requesting the change.
-Define a new Codesystem: 'Point of Origin - Newborn' with the verbiage that ‘This code system consists of the following: FL 15 - Point of Origin for Admission or Visit for Newborn and Non-newborn’
- Modify the PointOfOrigin Value Set in the Carin-BB IG to contain:
- all codes from the current 'Point of Origin' Code System
- all codes from the new 'Point of Origin - Newborn' Code System
Constrain the combinations of Type Of Admission and PointOfOrigin by adding an invariant that:
- if 'Type of Admission' = 4, then the Code System of the value in the PointOfOrigin slice must be from 'PointOforigin-Newborn'
- if 'Type of Admission != 4, then the Code System of the value in the PointOfOrigin slice must be from 'PointOfOrigin'
As use of the NUBC codes and descriptions requires a license, implementers who wish to use the descriptions will populate their terminology servers accordingly.
@Melissa Benzie @Scott Favre @Robert McClure @Carol Macumber @MaryKay McDaniel @Paul Knapp @Saul Kravitz @Amol Vyas
Pat Taylor (Feb 25 2021 at 17:00):
@Melissa Benzie @Scott Favre @Spencer Kathol
FHIR-30370 was written to add a new external code system define: 'Point of Origin - Newborn' in addition to the current code system and add an invariant that defines which should be used based on the Type of Admission.
The HL7 Terminology Authority has defined a new code system, AHA-NUBC-PointOfOrigin-Newborn. Additionally, to reduce confusion, the current code system, AHA-NUBC-PointOfOrigin was renamed to AHA-NUBC-PointOfOrigin-Nonnewborn. Reference https://confluence.hl7.org/pages/viewpage.action?pageId=104570446 and https://confluence.hl7.org/pages/viewpage.action?pageId=97452061.
What are the thoughts of the implementer community -- while renaming the current code system will negatively impact implementations, will the specificity it provides reduce confusion in the long run? @Carol Macumber @MaryKay McDaniel @Amol Vyas @Corey Spears @Mark Roberts
Corey Spears (Feb 26 2021 at 00:12):
@Pat Taylor, I do not believe this would be a breaking change. While it does change some of the internal references inside the implementation guide, the link you provided did not suggest changing the CodeSystem URL. This means instances of the resources will look the same as they would without the name change.
Corey Spears (Feb 26 2021 at 00:12):
I think a Jira ticket will need to be added for the name change.
Last updated: Apr 12 2022 at 19:14 UTC
