Burke, Ben, and I just discussed this, and here's how we want to treat the
assigning authority field.
We want to support the following options:
- Assigning authority = null
- legacy behavior: lookup by Person.personId, then find the relevant
provider
- if not found, throw an error, don't try to find a provider
- Assigning authority = ^PROVIDER.ID^L
- (this means Universal Id = "PROVIDER.ID" and Universal Id Type =
"L")
- Lookup provider by primary key id.
- Assigning authority = ^PROVIDER.IDENTIFIER^L
- (this means Universal Id = "PROVIDER.IDENTIFIER" and Universal Id
Type = "L")
- Lookup provider by identifier
- Assigning authority = ^PROVIDER.UUID^L
- (this means Universal Id = "PROVIDER.UUID" and Universal Id Type =
"L")
- Lookup provider by uuid
-Darius
On Thu, Mar 1, 2012 at 11:34 AM, 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]
