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