According to http://www.interfaceware.com/hl7-standard/hl7-field-XCN.html ...
XCN has a field called Assigning Authority, but it happens to be in a different position than in a CX. Built into the ORU^R01 Handler are a few authorities for local identifiers. Incoming HL7 messages that want to use a local ID should use those identifiers and we should reference them. The last option (if looking up the provider by assigning authority does not work) can be a last-ditch effort to find the provider by personId, and that is just for backwards-compatibility. Jeremy Keiper OpenMRS Core Developer AMPATH / IU-Kenya Support 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 > _________________________________________ 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]
