Notifications
Clear all
Topic starter
I am not sure if this is the correct place to post but I have a question about a strange configuration situation we have which results in numerous inbound HL7 messages to be manually resolved.
Problem:
Numerous HL7 messages come in and are not automatically resolved due to a "multiple matches were found" condition (Link Logic error attached)
Reason:
Back in 2005 we opened an Ambulatory Surgery Center (ASC) where we do procedures on patients who have been referred from our parent company of Tallahassee Neurological Clinic. We spoke with GE and decided (with their blessing) that we could put the patients in the system a second time with a different Location of Care so we could use the EMR portion of CPS for both businesses since the patients and doctors are the same.
Thoughts and details:
This problem is growing as we add more electronic interfaces (Electronic Prescriptions and labs for now). TNC has three "Locations of care" called TN, NS, and PMC. Attached is a HL7 message which shows that "PMC" appears in the message but that information is not utilized to defeat the "multiple matches" condition. We do not currently utilize the "ASC" location of care for any HL7 messaging but that should also be a possibility as it is set up in the system as such.
A while back I did speak with GE Support about this but was told that we would always have to manually resolve these things. It is very easy to manually resolve these, but it is time consuming and I can't help but think how stupid this is to have to do this manually since this HL7 stuff is defined rigidly and consistently. There should be no issue of liability but I feel like that answer from support was influenced by a lawyer.
Possible Solution:
Tell the Link Logic system to ignore the ASC Location of care when attempting to resolve patients. We do not have interfaces set up for the ASC location of care anyway.
Better Solution:
Utilize the Location of Care field so that the "multiple match" condition would be mitigated with the "location of care" making them unique.
-----------------------------------------------------------------------------------------
Sample Link Logic error showing "PMC" notation in the LOC field
In this example, the patient "Simpson, Homer" would exist in the CPS database twice. His information is the same in both databases; once in the location of care called "PMC", and also in the Location of Care, "ASC"
----------------------------------------------------------------------------------------
MSH|^~\&|eScriptMessenger||||20170316082312||ORU|1|P|2.3
/-/ Error: No existing data could be found to match incoming data, Multiple matches were found. lastName: Simpson, firstName: Homer, SocSecNo: 568470008 , dateOfBirth: 05/12/1955, Sex: M, Account: 123456789, SubAccount: , LOC: PMC, middleName: , Suffix: , Prefix: , Title: , CareProvider: NRiviera, AttendingDoctor: Riviera MD Nick E, (Patient) [PID|1|123456789|123456789||Simpson^Homer^||19550512|F|||742 Evergreen Terrace^^Portland^OR^970356995^||||||||], Start at: 58, End At: 165, Line in file: 1 \-\
PID|1|123456789|123456789||Simpson^Homer^||19550512|F|||742 Evergreen Terrace^^Portland^OR^970356995^||||||||
PV1|1|R|PMC||||JRiviera^Riviera MD^Nick^E
OBR|1|||^eRx Request for PROTONIX 40MG TABLETS||20170316072254|20170316072254|||||||||PMNURSE||RX||||20170316072254|||F
OBX|1|ST|ESM_RR^ESM_RR||WL3374115835520170316062254`PROTONIX 40MG TABLETS`40``30 Tablet`30`TAKE 1 TABLET BY MOUTH EVERY DAY``1`1`03/16/2017`01/04/2017` Kwik-E-Mart 03374*`5412240331`00008084181``PROTONIX 40MG TABLETS [BMN] Quantity: 30 Tablet Instructions: TAKE 1 TABLET BY MOUTH EVERY DAY||||||F|||20170316082312.297
NTE|1|NTE-2|Provider Name: Riviera MD, Nick E~ Provider Phone: 555-NICK~ Provider Address: 44 Bow Street ~ Provider City: Portland~ Provider State: OR~ Provider Zip: 970354675~~ Patient Name: Simpson, Homer ~ Patient DOB: 05/12/1955~ Patient Sex: F~~ Medication: PROTONIX 40MG TABLETS [BMN]~ NDCNUM: 00008084181~ Instructions: TAKE 1 TABLET BY MOUTH EVERY DAY~ Quantity: 30 Tablet~ Refills: 1~ Written Date: 03/16/2017~ Transaction ID: WL3374115835520170316062254~ Date of Request: 20170316072254~~ Pharmacy: Kwik-E-Mart 03374*~ Last Fill Date: 01/04/2017~ Pharmacy Phone: 5415550331~ Pharmacy Notes: ~~ Drug Dispensed: PROTONIX 40MG TABLETS [BMN]~ Quantity: 30 Tablet~ Instructions: TAKE 1 TABLET BY MOUTH EVERY DAY~ Refill(s): 1~ Notes: ~ Written Date: 03/16/2017~~ Pharmacy Address: 100 E MAGNOLIA ~ Pharmacy City: Portland~ Pharmacy State: OR~ Pharmacy Zip: 97055|
Any thoughts would be appreciated
Mike Zavolas
Tallahassee Neurological Clinic
Posted : March 16, 2017 3:12 am
This would be fairly easy to fix by routing the messages to an interface engine (ex: Qvera or Mirth) and having the interface engine lookup the patient via an SQL query and populate the patient ID field in the HL7 message. With the proper patient id in the message, you could have it ignore name/dob/sex etc.
If you would like someone to build one for you let me know.
Posted : March 16, 2017 3:20 am
There is a checkbox in Patient Matching -> Criteria that says "Use location of care in matching algorithm"
Posted : March 16, 2017 3:26 am
Topic starter
I am going to try this. I also noticed some definitions on the "Locations of care" button where I would be able to exclude the "ASC" location.
Thanks for that tip
Mike Zavolas
Tallahassee Neurological Clinic
Posted : March 16, 2017 3:40 am
Also remember, if someone has multiple interface with the same names, it could have created multiple ExternalIDs which may also cause this issue. I had this issue in the past and cleared all the ExternalIDs fromt he External ID table, and let it rebuild itself, I haven't received an error again.
Posted : March 16, 2017 3:50 am
Check out chapter 19 of the managing interfaces 12.2 document. It explains in if-then format how matching decisions are made.
My IT mind asks why not merge the patients. However I understand from a practical standpoint that may not be possible.
Posted : March 16, 2017 3:56 am
Mirth could be used to query the database and add the appropriate PID to the HL7 message.
Posted : March 16, 2017 3:57 am
We are a Neurosurgical practice and also have several locations which include our Neurosurgeons, PT, Pain Management, MRI, X-ray etc.
We only create the patient once in our system. I would merge all the duplicate accounts and only deal with one account per patient. There is a report you can run on duplicate patients.
Have a great day!
Posted : March 16, 2017 4:30 am
I just re-read your question and there is one part I do not understand, are the values in PID-2 and PID-3 the correct patient IDs in CPS? If so are they PatientID, or ExternalID? If they are not the correct PID, I think your best option is to have an interface perform an SQL query and replace the ID and then setup linklogic to only use the Patient ID and ignore the rest of the demographics.
If they are the Correct PatID already, just turn off patient demographic matching and have it rely on the PatID.
As someone else mentioned, there is an option in LL to match on location as well. In CEMR, the option is in the LL "Task options" then select the inbound interface and select Patient matching and then criteria. It might be slightly different in CPS.
EDIT: Also, there is a location of care setting under Task options. You could try to uncheck the other locations of care and see if that fixed your issue.
Posted : March 16, 2017 5:52 am
Topic starter
The Location of Care of ASC is a separate business entity. For IRS purposes we would not be allowed to merge the patients (co-mingling) but there are other reasons as well. There is another system at the ASC business called Vision which is used for scheduling, insurance, and state reporting
Posted : March 16, 2017 6:33 am
Topic starter
I unchecked the ASC LOC for one interface and haven't seen any errors since I did that so I think that is a good fix. However I can't seem to identify which interface is for e-Prescribe. I know for sure that it is a Kryptiq product but I have 9 different "import tasks" with the word Kryptiq as part of the name. I am going through and changing each one while monitoring the LL messages to make sure I don't accidentally cause hundreds of errors to fix.
The names are Kryptiq, Kryptiq-ADM, Kryptiq-ETOH, Kryptiq-HIV, Kryptiq-MH, Kryptiq-STD, Kryptiq-AIDS, Kryptiq-MHLTH,Kryptiq-SUBAB. I recognize the initials and would understand the need for confidentiality possibly but I don't know why there are import tasks for these things. We don't test for these types of things. I was hoping changing the LOC setting in the one called KRYPTIQ would do the trick but it did not.
I like some of these other ideas here so if this doesn't work it is good that I have other options, thanks for the discussion today. Good stuff
Mike Zavolas
Tallahassee neurological Clinic
Posted : March 16, 2017 6:54 am
Topic starter
If the LOC thing doesn't do the trick I may go this route. I never heard of Mirth but did google it. It is open source, correct? This may do the trick. I could replace 123456789 with the actual PID after a SQL query and change the message. Seems very doable
Mike Zavolas
Tallahassee Neurological Clinic
Posted : March 16, 2017 6:56 am
Take a look under import lab results. We have an interface called eScriptMessenger.
Posted : March 16, 2017 7:12 am
Topic starter
Found it. Thanks for that tip.
BTW, I did not answer the PID-2 and PID-3 question. 123456789 is what I think you are referring to. That is what is in that field when the message arrives. It makes sense because the sender would not have this information but I think that is where I would be able to replace 123456789 with the real PID or ExternalID with Mirth
Posted : March 16, 2017 7:26 am
If disabling the locations works for you, that is definitely the easiest route to use. Since the PID-2 and PID-3 are outside medical record numbers, you could fix the issue with an interface as stated before. If you would like to look into a Qvera/Mirth solution to the problem let me know and I would be glad to assist.
Posted : March 16, 2017 7:45 am
Page 1 / 2
Next
