Thought I'd chime in since I have some background with HL7...
Your plan seems reasonable, but I had a few additional suggestions.
1) What happened to attributes? Could we add one more case:
Assigning Authority (piece 9) = PROVIDER.ATTR
ID Type (piece 13) = <Attribute ID>
2) Minor point, but the difference between PROVIDER.ID and
PROVIDER.IDENTIFIER could get confusing. Perhaps consider changing
PROVIDER.ID to PROVIDER.PK?
3) I think it would be nice to be able to configure the values we'd
expect in the assigning authority field.
Also, does OpenMRS have copy of the HL7 specs? I didn't realize they
cost anything, but wow - $700?
I wouldn't mind helping with some of this work, if you have a ticket
that would be good for someone with some HL7 knowledge, but new to OpenMRS.
-Spencer
On 3/1/2012 1:33 PM, Darius Jazayeri wrote:
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
o legacy behavior: lookup by Person.personId, then find the
relevant provider
o if not found, throw an error, don't try to find a provider
* Assigning authority = ^PROVIDER.ID <http://PROVIDER.ID>^L
o (this means Universal Id = "PROVIDER.ID <http://PROVIDER.ID>"
and Universal Id Type = "L")
o Lookup provider by primary key id.
* Assigning authority = ^PROVIDER.IDENTIFIER^L
o (this means Universal Id = "PROVIDER.IDENTIFIER" and Universal
Id Type = "L")
o Lookup provider by identifier
* Assigning authority = ^PROVIDER.UUID^L
o (this means Universal Id = "PROVIDER.UUID" and Universal Id
Type = "L")
o Lookup provider by uuid
-Darius
On Thu, Mar 1, 2012 at 11:34 AM, Wyclif Luyima <[email protected]
<mailto:[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] <mailto:djazayeri%[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] <mailto:[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]
<mailto:[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] <mailto:[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] <mailto:[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
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[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]
