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