Hi all.
I’m posting this comment to the IL group even tho the discussion today was on an SHR community call. (My sense is that this is an IL orchestration issue).
On today’s call we discussed the idea that we might be able to harvest demographic content from an inbound care encounter document and automate the creation of an EMPI record based on this content. There are pros and cons to this idea.
One of the biggest PROS of doing this is that it is opportune. If we have all the content we need to create an EMPI record and the content has been sent to us from a trusted source, this could be considered a more pragmatic option than returning an exception message to the POS indicating the the client was “not found” in the EMPI.
One of the biggest CONS is that automatically creating an EMPI record potentially does an “end run” around whatever are the governance processes associated with setting up a person in the EMPI. If there are any financial implications (e.g. health insurance) to the existence of the EMPI record, we would need to ensure that whatever governance applied to the manual (people-executed) process also applied to the automated (system-executed) process. (e.g. in Ontario, Canada, where I live – the EMPI is the Ontario Health Insurance Plan enrollee database).
It was clear that enriching the “save encounter” workflow to automatically insert EMPI records would squarely put us into the territory of the CR community. For that reason, I’m cross-posting this to the archtitecture community with the hopes that folks from that group, and others, can wade in with their comments. Quite generically – if we find we have an inbound document, of any kind, that fails its ID resolution processes (client, health worker, facility, terminology); should we try to “fix” it or should we return an exception to the POS?
In order for the clinical data contained in these care encounter summaries to be stored in the OpenHIE, we’d need to have an identity, so this would be a necessary process.
If the question is, “is it possible?” then the answer is yes.
If the question is, “is it feasible?” then the answer is “it depends.”
I depends on how accurately, completely, and reliably the demographics are present in the care summary document. To the extent the data are accurately and reliably present, then it’s a function of how the demographics are extracted and fed to the CR.
Hi all.
I’m posting this comment to the IL group even tho the discussion today was on an SHR community call. (My sense is that this is an IL orchestration issue).
On today’s call we discussed the idea that we might be able to harvest demographic content from an inbound care encounter document and automate the creation of an EMPI record based on this content. There are pros and cons to this idea.
One of the biggest PROS of doing this is that it is opportune. If we have all the content we need to create an EMPI record and the content has been sent to us from a trusted source, this could be considered a more pragmatic option than returning an exception message to the POS indicating the the client was “not found” in the EMPI.
One of the biggest CONS is that automatically creating an EMPI record potentially does an “end run” around whatever are the governance processes associated with setting up a person in the EMPI. If there are any financial implications (e.g. health insurance) to the existence of the EMPI record, we would need to ensure that whatever governance applied to the manual (people-executed) process also applied to the automated (system-executed) process. (e.g. in Ontario, Canada, where I live – the EMPI is the Ontario Health Insurance Plan enrollee database).
It was clear that enriching the “save encounter” workflow to automatically insert EMPI records would squarely put us into the territory of the CR community. For that reason, I’m cross-posting this to the archtitecture community with the hopes that folks from that group, and others, can wade in with their comments. Quite generically – if we find we have an inbound document, of any kind, that fails its ID resolution processes (client, health worker, facility, terminology); should we try to “fix” it or should we return an exception to the POS?
Warmest regards,
Derek.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
@Derek, thanks for posting this and I agree this issue is more in the realm of the IL community.
I think we all understand that it would be possible to create a new patient while saving a clinical document, however, the questions is if that something that we want to do? Requiring that the PoC must always register a patient with the client registry before saving an encounter add more complexity to the PoC (but perhaps rightly so). As Derek states, there are certain actions that need to be taken when a patient is registered so perhaps this should be an explicit step. On the other hand, if we do end up receiving clinical documents that we cannot save in the SHR as a matching patient doesn’t exist in the CR, then we will end up with a large queue of these errors in our exception handling mechanism that potentially already contain all the data that we need (patient demographics and clinical document).
At this point I’m still in favour of keeping workflows as is (ie requiring a PoC to explicitly register a new person before sending encounters) as this makes sense from the data governance point of view and also keep the save encounter workflow simpler.
What do others think?
Cheers,
Ryan
···
On Tue, Mar 11, 2014 at 7:33 PM, Shaun Grannis sgrannis@gmail.com wrote:
Thanks Derek,
In order for the clinical data contained in these care encounter summaries to be stored in the OpenHIE, we’d need to have an identity, so this would be a necessary process.
If the question is, “is it possible?” then the answer is yes.
If the question is, “is it feasible?” then the answer is “it depends.”
I depends on how accurately, completely, and reliably the demographics are present in the care summary document. To the extent the data are accurately and reliably present, then it’s a function of how the demographics are extracted and fed to the CR.
Hi all.
I’m posting this comment to the IL group even tho the discussion today was on an SHR community call. (My sense is that this is an IL orchestration issue).
On today’s call we discussed the idea that we might be able to harvest demographic content from an inbound care encounter document and automate the creation of an EMPI record based on this content. There are pros and cons to this idea.
One of the biggest PROS of doing this is that it is opportune. If we have all the content we need to create an EMPI record and the content has been sent to us from a trusted source, this could be considered a more pragmatic option than returning an exception message to the POS indicating the the client was “not found” in the EMPI.
One of the biggest CONS is that automatically creating an EMPI record potentially does an “end run” around whatever are the governance processes associated with setting up a person in the EMPI. If there are any financial implications (e.g. health insurance) to the existence of the EMPI record, we would need to ensure that whatever governance applied to the manual (people-executed) process also applied to the automated (system-executed) process. (e.g. in Ontario, Canada, where I live – the EMPI is the Ontario Health Insurance Plan enrollee database).
It was clear that enriching the “save encounter” workflow to automatically insert EMPI records would squarely put us into the territory of the CR community. For that reason, I’m cross-posting this to the archtitecture community with the hopes that folks from that group, and others, can wade in with their comments. Quite generically – if we find we have an inbound document, of any kind, that fails its ID resolution processes (client, health worker, facility, terminology); should we try to “fix” it or should we return an exception to the POS?
Warmest regards,
Derek.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.