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 > _________________________________________ 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]
