XCN-9 using something like "^provider.id^L" or "^provider.uuid^L"
-Burke On Thu, Mar 1, 2012 at 2:34 PM, Wyclif Luyima <[email protected]> wrote: > Darius is spot on, we can use the 9th component of the XCN. Sorry for my > limited HL7/HAPI knowledge. > So i guess everyone agrees that we take this route. > > Wyclif > > > On Thu, Mar 1, 2012 at 2:03 PM, Darius Jazayeri > <[email protected]>wrote: > >> According to the HL7 2.5 spec, PV1's Attending Doctor is an XCN (which >> means " extended composite ID number and name for persons"). >> >> And indeed our code treats this as an XCN: >> XCN hl7Provider = pv1.getAttendingDoctor(0); >> >> And XCN has "Assigning Authority" as its 9th component. (Its datatype is >> HD = hierarchic designator.) >> >> So, we really *should* be able to use this field. >> >> -Darius >> >> On Thu, Mar 1, 2012 at 10:52 AM, Wyclif Luyima <[email protected]>wrote: >> >>> We certainly need to figure out a way to determine if the value is an >>> identifier Vs providerId vs personId, but from my recent attempts, >>> assigning authority is not supported for XCN so we might not be able to use >>> it for this purpose. >>> If we can't seem to get around this, how about if we say the id should >>> be prefixed with what describes it i.e identifier/personId/providerId, if >>> the prefix doesn't exist then it is assumed to be a personId to support >>> messages from old legacy code. >>> >>> Wyclif >>> >>> >>> On Thu, Mar 1, 2012 at 1:24 PM, Ben Wolfe <[email protected]> wrote: >>> >>>> Is the authority allowed to be any text? Or should be preface this >>>> with a 99 or some other openmrs-specific string? >>>> >>>> Wyclif, what if a provider has an identifier that is the same as an >>>> existing person_id ? That current implementation would fail. >>>> >>>> Is this a bug in HAPI that is fixed in a later version? IIRC, we're >>>> using a hapi version from 3-4 years ago. >>>> >>>> Ben >>>> >>>> >>>> On Thu, Mar 1, 2012 at 12:55 PM, Wyclif Luyima <[email protected]>wrote: >>>> >>>>> I tried reading in the assigning authority while working on TRUNK-2893 >>>>> and noticed that the library we are using to parse the HL7, in the case of >>>>> XCNs it interpretes what we expect to be the assigning authority as the >>>>> given name, basically it always returns null when you try to get the >>>>> assigning authority for XCN, it is for the CE that it gets the assigning >>>>> authority. >>>>> >>>>> My view is and this is what i implemented(we can change it) in the >>>>> initial commit for TRUNK-2893, is to assume it is a personId or provider >>>>> identifier, i.e for the ID number you can specify the personId or >>>>> provider >>>>> identifier and this will still take care of HL7 messages from old legacy >>>>> code gracefully. So the Orur01 handler first checks for a provider >>>>> associated to a person with a personId matching the passed in value if it >>>>> is a number otherwise it defaults to looking up one with a matching >>>>> provider identifier. >>>>> >>>>> Wyclif >>>>> >>>>> >>>>> On Thu, Mar 1, 2012 at 11:31 AM, Darius Jazayeri >>>>> <[email protected]>wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Per TRUNK-3108 <https://tickets.openmrs.org/browse/TRUNK-3108>, >>>>>> incorrectly merged into >>>>>> TRUNK-2843<https://tickets.openmrs.org/browse/TRUNK-2843> >>>>>> : >>>>>> >>>>>> In 1.9 we've added a Provider object, but our ORUR01Handler class has >>>>>> not yet been updated to take this into account. Currently, the formentry >>>>>> and xforms modules pass a value for a PV1's provider field like "1^Super >>>>>> User (1-8)", and we interpret the first number as a person_id (pk of the >>>>>> person table), and ignore the name. This is now problematic, because not >>>>>> every person necessarily has a provider associated with them, and some >>>>>> may >>>>>> have more than one. >>>>>> >>>>>> The correct new behavior seems like it would be to instead interpret >>>>>> the first number as a provider_id (pk of the provider table). The >>>>>> downside >>>>>> of this is that R01 messages produced by all existing code would give you >>>>>> the wrong providers. >>>>>> >>>>>> A slightly-hackier, but backwards-compatible way would be to let the >>>>>> authority field of the XCN tell how to interpret the value passed in: >>>>>> >>>>>> - no authority : "legacy mode". Treat as person id (pk of person >>>>>> table) >>>>>> - authority = PROV_ID : Treat as provider id (pk of provider >>>>>> table) >>>>>> - authority = PROV_IDENTIFIER : Treat as provider.identifier >>>>>> (user-specified identifier for the provider) >>>>>> - authority = PROV_ATTR_3 : Look for a provider who has an >>>>>> attribute whose providerAttributeType is 3, and whose value is what's >>>>>> given >>>>>> >>>>>> Thoughts? Alternatives? >>>>>> >>>>>> -Darius >>>>>> ------------------------------ >>>>>> Click here to >>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>>>> OpenMRS Developers' mailing list >>>>> >>>>> >>>>> ------------------------------ >>>>> Click here to >>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>>> >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
