zhhealthcare wrote on Friday, February 01, 2013:
We have begun working on this project and the documents can be seen in the link above.
One clarification from the experts here.
Our understanding is that CCR and CCD is different representation of the same XML file.
We are not aware of separate XML files for CCR and CCDs.
Therefore we are working on parsing the XML file that is going to be brought in.
Thanks and regards
bradymiller wrote on Friday, February 01, 2013:
Hi,
Here’s the correct web link to the wiki page for this MU2 item:
http://open-emr.org/wiki/index.php/Transitions_of_care_%E2%80%93_receive,_display,_and_incorporate_transition_of_care/referral_summaries_(MU2)
-brady
bradymiller wrote on Friday, February 01, 2013:
Hi,
Just to point out, note there are current Document categories CCD/CCR that can bring in the xml portions. So, there is a place to at least hold these things and display them in their “nice” format (of course, still need to do a bunch of work as you’ve nicely laid out in your documentation on the wiki page)
Two things to bring up here:
1. It looks like we will soon have a mechanism for electronically retrieving (and sending) ccd via a Direct service:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/6706156
(That service, EMR Direct, has a sandbox that you can work in, if interested, when get to the point of incorporating this)
2. OpenEMR’s CCR/CCD forms are rather shabby (to say the least). Another ongoing project should be to optimize these things (and convert them to CCDA), which could even be done independently by another group (maybe MI2, whom was planning to do some CCDA work) if not enough resources.
-brady
OpenEMR
bradymiller wrote on Friday, February 01, 2013:
Hi,
Here’s a nice article defining CCA/CCR/CCD/CCDA for dummies (people like myself):
http://www.integrationrequired.com/?p=310
-brady
OpenEMR
tmccormi wrote on Saturday, February 02, 2013:
The point of this project should be; to be able to import standard CCR and CCD files and CCDA file formats into OpenEMR native data table locations from external sources (other EMRs). CCR and CCD are definitely NOT the same at all except they are both XML based, C-CDA is a “new” format derived from CCR and CCD.
Tony
www.mi-squared.com / @tonymi2
oemr.org / @OEMR_org
zhhealthcare wrote on Monday, February 04, 2013:
Hi Guys
Added a wire frame document, Please review.
Thanks
bradymiller wrote on Tuesday, February 05, 2013:
Hi Shameem,
Note there is a mechanism to import/store/view the xml components of ccr/ccd documents in the Patient Summary/Documents section. As long as it builds on the current mechanism, having your own import/reconcile gui screen makes complete sense (since this feature is not patient centric) along with having another place to store these documents until the patient is known (ie. if some user intervention is needed to confirm patient identity or allow a new patient etc.). Also, don’t hard-code it to just CCR since this mechanism will also be used for CCD and CCDA in future. Not sure where best place for the menu items will be, but this can be easily changed/revised/improved once the functionality is there.
-brady
OpenEMR
zhhealthcare wrote on Tuesday, February 12, 2013:
Hi,
The parsing of the CCR XML and insertion of the parsed result into audit tables for approval is almost complete.
Please suggest a solution for the below mentioned concerns( which was also mentioned earlier in the requirement analysis document).
Concerns:
Basically the problem is that the values we import from the CCR will be shown in the drop-down lists in the OpenEMR, so we have to identify and exclude them from the list of options shown in the current OpenEMR.
- The address book entries will be populated with the records imported from each CCR document, we have to identify the information imported from CCR in some way and exclude it from listings in OpenEMR.
- The lab results in the current openEMR is shown as orders and its result. However from the CCR we won’t get enough information for creating the order. Further if we insert such an order as a new one we have to exclude it from the list of tests available in the EMR.
Working of the XML parser is as follows, please let us know if any change is required.
The parsing of the CCR XML is performed using DOM XML parser. The function to parse the XML has two arguments, first one is the path to the XML file and the second one is the mapping for the XML file. The mapping is an array in which level 1 key is the main tag in the XML, level 2 key is ‘table name:field name’ and level 2 value is the sub tag under the main tag given in level 1 key.
Thanks and regards
yehster wrote on Tuesday, February 12, 2013:
Something to consider would be to import these record into different tables than the existing address book etc…
Then they are already “filtered out.” and you don’t have to worry about the impact to existing listings.
bradymiller wrote on Wednesday, February 13, 2013:
Hi (specific question for Rod below),
Another alternative would be to add a flag sql-column in the address book table (ie. users table) that identifies it was imported in(what are these entries exactly?). Considering the addition of address book entries in the users table didn’t cause much upheaval, I am guessing it would be straightforward to mask these entries (possibly no effort needed) from other user drop-downs in OpenEMR.
For the lab issue, Rod, do you have any thoughts on a good direction to point us towards in order to deal with the issue of importing labs, whereas the labs don’t fit into the ordering hierarchy that a clinic has set up in the procedure tables? I’d hate to place a bunch of miscellanous mapping entries for importing into the procedure_type and procedure order_code tables. Any advice would be useful.
thanks,
-brady
OpenEMR
sunsetsystems wrote on Wednesday, February 13, 2013:
Hi Brady,
I suggest keeping things out of the address book that the clinic does not have a direct interest in. If that table gets too big it will become clumsy to maintain. So perhaps a new table is in order. Note that for labs specifically, there is a new table procedure_providers for their information - I removed them from the address book already.
There will be a general need to store lab results that don’t have a corresponding order in OpenEMR, this is something that I may have to deal with soon (depending on whether a particular clients wants that). I think the general approach will be to create a skeleton order but to not associate it with a visit, so that’s what I suggest in this case. The existing code will need to adapt to the possible absence of an encounter. I recommend ZH keep in contact with me about the details to make sure we stay on the same page.
sunsetsystems wrote on Wednesday, February 13, 2013:
By the way you can now store lab results without matching entries in the procedure_type table - that’s something that I also took care of with the last set of updates.
deschel wrote on Wednesday, February 13, 2013:
What information are you importing into address book? Names & address information of specialists, other doctors in the medical records being imported? If not, pleaaaase don’t touch it.
Address book tables are being overhauled by me and cipher-naught. They are sooo poorly designed.
What is currently in address book will be broken out into multiple tables. There is no reason for user access info to be stored in the same table that names and addresses of specialists, etc are stored in.
We are unbloating these tables and replacing them with something much more powerful.
When we are finished EVERY ADDRESS & PHONE NUMBER will be stored in address book - patients, insurance companies, secondary contacts, employers, users (without login data), other providers, etc. It will be a universal centralized address book that will be extremely well designed and well thought out table normalization.
We keep having delays. I’m hoping to have something to upload to github in the next few weeks. The database access and translation code is finished. We are just working on the user interface design now.
David Eschelbacher MD
bradymiller wrote on Wednesday, February 13, 2013:
Hi,
Agree that what to do with the address book entries is dependent on what is being imported. Can we get some example of what will be getting imported into them?
thanks,
-brady
OpenEMR
zhhealthcare wrote on Wednesday, February 13, 2013:
Hi,
Thank you for your suggestions.
An example for an address book entry we got as a result of openEMR CCR XML parsing is,
lname => Test
fname => Lab
street =>
city => Test City
state => Test State
zip => 00000
phone => 000-000-0000
which is the details of a lab service specified in the system.
Thanks and regards
bradymiller wrote on Thursday, February 14, 2013:
Hi,
Since it appears will be getting a large variety of entries, sounds like another table would be ideal for this (misc_address_book or something like that). Not sure what fields would be needed; should make it as minimal as possible. Any input here(especially David since it appears he’s put a lot of work into this already)?
-brady
OpenEMR
deschel wrote on Thursday, February 14, 2013:
It is unclear to me what data you are trying to store.
lname = TEST - Is this the name of the test?
Is there going to be a record for each test?
So if there are 10 tests at the same lab, does this mean that you will have ten records all with the same values for fname (lab name), City, State, and Phone no. Then this is not an addressbook. Am I misunderstanding your illustration?
If I am understanding it correctly, then you need two tables. One to store the lab names and addresses and a different related table (1:many relationship) that stores the tests provided by that lab.
Example:
Table: diagnostic_test
Columns:
diagnostic_test_id
diagnostic_test_name
addressbook_id
Then use addressbook to store the name and address of the lab. The diagnostic_test table can point to the lab that the test was done at by storing the addressbook_id of the lab that it was done at.
One table should store just one type of info, ie addressbook should only store address info.
Now, when importing the data, you will need to create an algorithm for matching the lab_name to an existing record if that lab is in the database, and to add a record if it is not.
David Eschelbacher MD
bradymiller wrote on Thursday, February 14, 2013:
Hi,
It’s for importing CCR/CCD/CCDA documents, so I think there will be a large variety of entity types/addresses.
ZH, To help us further clarify, can we get multiple examples? (to avoid merging ZH’s two issues above, which is where we seem headed 
)
thanks,
-brady
OpenEMR
bradymiller wrote on Thursday, February 14, 2013:
Hi zhhealthcare,
On another topic, EMR Direct is working on the mechanism to import CCR/CCD/CCDA docs via Direct:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/6706156
After they get imported via direct, figured it would make sense to just piggyback onto whatever solution you have for importing unknown patient CCD/CCDA/CCR docs(ie. before you parse them and assign patient id etc.). Here’s the doc you have on this:
http://open-emr.org/wiki/images/7/7e/CCR_XML_Import.pdf
(seems like pertinent is page 1)
If your at the point where this is code for importing, then just let us know, so EMR Direct can then figure out how to incorporate the EMR Direct import into it. (Don’t use the mechanism that is in EMR Direct’s code posted on the above forum thread since this is too invasive; ie. do what your were planning)
thanks,
-brady
OpenEMR
lcmaas3 wrote on Thursday, February 14, 2013:
Hi.
Here are some details on the working model for receiving and storing CCDA/CCD/CCR documents received in Direct Messages. We hope we can tweak this into something that works together with your import features. As you know, the MU2 criteria has the three parts “Receive”, “Display” and “Incorporate”. Based on our work in several industry-wide Direct workgroups, there seems to be consensus developing around a “one message, one patient” model for transmission of summary or transition of care docs, so we have written our “Receive” code so that each Direct message (which should contain a CCDA, CCD, or CCR document, but could also contain additional documents such as images, referral requests, etc) can be associated to a single patient.
In Post #7 above, Brady suggested using the mechanism to import/store/view the xml components of ccr/ccd documents in the Patient Summary/Documents section. We agree with idea, because the MU2 “Display” requirement to show the received documents in human readable form is largely covered here (note this is separate from the incorporation of the data elements). Reasonable “human-readable” viewing of a valid MU2-compliant CCDA would have to be confirmed, of course, since this is technically different from a CCD or CCR.
One issue is that on receive since the patient_id is not known to us, and, at least for now, we are setting the patient ID to “zero” as a searchable placeholder in the patient_id field in the documents table, until it is changed by an adminstrator using the “move to patient #” feature already in the Documents section or, more optimally, identified by the ZH import functionality. If you or someone else builds a function such as XML_patient_match($doc_id) for a CCD,CCR,or CCDA document that scans the XML referenced by the doc_id in the documents table and returns either a valid patient_id or “zero” if equivocal or unknown, we could take advantage of that when adding the documents. You could also use this function to create a queue of documents that require user intervention for the “Incorporate” (aka import) step. (Since the messages are received asynchronously, the “Incorporate” process would have to be run manually by someone by processing this queue). Any remaining unknown/uncertain patient_id’s could be resolved in this step as well.
Let me know how this sounds to you all,
Luis
EMR Direct