Please refer : http://www.open-emr.org/wiki/index.php/Transitions_of_care_%E2%80%93_receive,_display,_and_incorporate_transition_of_care/referral_summaries_(MU2);
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
Here's the correct web link to the wiki page for this MU2 item:
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:
(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.
Here's a nice article defining CCA/CCR/CCD/CCDA for dummies (people like myself):
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.
www.mi-squared.com / @tonymi2
oemr.org / @OEMR_org
Added a wire frame document, Please review.
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.
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).
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.
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.
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.
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.
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.
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
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?
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
city => Test City
state => Test State
zip => 00000
phone => 000-000-0000
which is the details of a lab service specified in the system.
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)?
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.
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.
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 :) )
On another topic, EMR Direct is working on the mechanism to import CCR/CCD/CCDA docs via Direct:
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:
(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)
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,
Here is a more detailed example showing one address book entry and one lab result entry.
After parsing a CCR XML exported from openEMR, the following are the values that are available from it.
If we import them back to OpenEMR then we can map it as follows.
But in the case of lab result this information is not enough to create a lab order and result.
The first group shows an entry referring to the lab which is specified in the CCR XML and we need to import it (either into OpenERM address book or some other table) so that we can refer to the lab which performed a specific test for the imported patient.
The format used is : tablename => fieldname => value
users => lname => Test
users => fname => Lab
users => street =>
users => city => Test City
users => state => Test State
users => zip => 00000
users => phone => 000-000-0000
The second group shows a single lab result specified in the CCR XML.
procedure_type => name => Fasting Blood Glucose
procedure_result => abnormal => high
procedure_result => result => 178 MG/DL
procedure_result => date => 2013-01-22T19:40:40Z
In the case of lab if there are 10 lab results for a patient which were performed in a single lab, only a single entry will be there.
But this CCR XML will also contain the facility address as a separate entry, another entry for the EMR which is used to generate this information. So from a single CCR XML we'll have about three address book entries.
Please let us know if anybody have any doubts.
Thanks and regards
Is the script for exporting CCR available in the community version of OpenEMR or limited to your version only? I am aware that Tony of mi-square has provided a script for importing it (contrib/util/import_mi2xml.php).
Hi ZH Healthcare,
Do you have a general scheme (or plan) for the uploading/tracking of the CCR/CCD/CCDA documents? We need to know this for EMR Direct to integrate in their Direct import feature discussed above?
(since this upload piece is becoming a bottleneck, I think it makes sense to prioritize this over the labs/addresses for now)
For your import document implementation (essentially setting the patient id to 0), I just had two quick question since can't readily test it:
1. What directory are the documents ending up in (I am assuming sites/default/documents/0/ )?
2. Is there a screen where these documents (set to patient 0) can already be seen in OpenEMR (to allow manual use of the move to #)?
For those interested, here is the commit with above discussed implementation:
The documents are going into sites/default/documents/direct/. We are using the Documents upload function which I assume would use the correct sites subdirectory if necessary.
We accessed patient "Zero" with /controller.php?document&list&patient_id=0, but I added a menu item in miscellaneous in my last update to open this link directly from the left_nav menu.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.