At least with HL7 v.2.5, the PV1 attending doctor segment is supposed to be XCN. We need to identify the HL7 version supported by our HAPI component. If it is lower than 2.5, I would say that we should upgrade it to 2.5. I disagree with Wyclif's proposal to embed the authority identifier in the ID under the maxim "IDs should carry no information".
I don't think we should focus solely on the forms use case where an implementation's own metadata is being fed back to itself. We also need to consider sending and receiving from labs and other health facilities. For this purpose, it is important that the authority be clear, not where it's stored. For PKs, regardless of table, the OMRS implementation is the authority. But if we are using payroll number or insurance number as the provider identification or an attribute, then MOH Payroll or National Insurance should be the authority, not the column reference. The mapping from authority to column reference should be internal to the implementation. For this reason, I would prefer something like the first two options of the backwards compatible way. From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Thursday, March 01, 2012 11:31 AM To: [email protected] Subject: [OPENMRS-DEV] PV1 providers in R01 messages in 1.9 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 _________________________________________ 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]
