Difference between revisions of "MU-CPOE"
Anthracite (talk | contribs) |
(Added a glossary link to record~) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
*# Provider referrals | *# Provider referrals | ||
| − | 1. Medication ordering requires interaction checking, formulary checking, insurance checking, allergy etc. ePrescibing will endeavor to handle this and Oroville hospital is in the process of setting this up and will release the code into open source when it is done. For local printing of prescriptions for hand carrying to the pharmacy, the autofinish can be used. This is all a difficult problem because ePrescribing is not standardized and there are multiple ePrescribing databases that need to be mapped to RxNorm for meaningful use and that mapping is not available freely available. Local drug ordering databases need to be mapped as well. In addition, the problem of quality recording raises its head because that requires that NDC codes, not RxNorm be used in reporting the appropriate performance measures. And medication allergies need to be coded in a way that the allergy cross checking or ingredients can be done recognizing the drugs that contain that ingredient, probably by mapping them to RxNorm. | + | 1. Medication ordering requires interaction checking, formulary checking, insurance checking, [[allergy~|Allergy]] etc. ePrescibing will endeavor to handle this and Oroville hospital is in the process of setting this up and will release the code into open source when it is done. For local printing of prescriptions for hand carrying to the pharmacy, the autofinish can be used. This is all a difficult problem because ePrescribing is not standardized and there are multiple ePrescribing databases that need to be mapped to RxNorm for meaningful use and that mapping is not available freely available. Local drug ordering databases need to be mapped as well. In addition, the problem of quality recording raises its head because that requires that NDC codes, not RxNorm be used in reporting the appropriate performance measures. And medication allergies need to be coded in a way that the [[allergy~|Allergy]] cross checking or ingredients can be done recognizing the drugs that contain that ingredient, probably by mapping them to RxNorm. |
2. Laboratory orders for laboratories that are not in-house need to be transmitted to the laboratory that is appropriate for the patient's insurance and the proper ICD9 codes and tests ordered depending on the lab being used. If the orders are not sent (usually HL7) that an alternative incoming processing system will need to be set up to handle these transmitted results which will require some coding. The VistA Lab Project which generally meets on Monday nights will be tackling this problem but it is on hiatus right now. Interfaces with labs are difficult and are probably best processed sending HL7 messages to Mirth and the Mirth used to help facilitate matching up the data transmitted from VistA to the HL7 messages that the lab wishes to receive. The HL7 setup process itself needs documentation for those of us who are not very sophisticated at it and I understand that there is such an effort going on on the Medsphere web site. | 2. Laboratory orders for laboratories that are not in-house need to be transmitted to the laboratory that is appropriate for the patient's insurance and the proper ICD9 codes and tests ordered depending on the lab being used. If the orders are not sent (usually HL7) that an alternative incoming processing system will need to be set up to handle these transmitted results which will require some coding. The VistA Lab Project which generally meets on Monday nights will be tackling this problem but it is on hiatus right now. Interfaces with labs are difficult and are probably best processed sending HL7 messages to Mirth and the Mirth used to help facilitate matching up the data transmitted from VistA to the HL7 messages that the lab wishes to receive. The HL7 setup process itself needs documentation for those of us who are not very sophisticated at it and I understand that there is such an effort going on on the Medsphere web site. | ||
| − | 3. Radiology referrals need to be made out using the proper templates to provide the necessary information and instructions for the patient for various procedures as well as providing the necessary clinical information for the radiologist depending on the procedure. In the setting with no radiology department, this will need to be sent to someone to process or print out to hand to the patient and some sort of status | + | 3. Radiology referrals need to be made out using the proper templates to provide the necessary information and instructions for the patient for various procedures as well as providing the necessary clinical information for the radiologist depending on the procedure. In the setting with no radiology department, this will need to be sent to someone to process or print out to hand to the patient and some sort of status [[record~|Record]]ed. The existing processes in VistA can be adapted to do this, but it requires some setup, documentation of that set u and analysis of the process for various settings. This requires a considerable amount of work to be entered here. |
4. Provider referrals needs to be configured to work well in the clinical setting for most out patient facilities. It is designed to handle referrals to other physicians within the same facility, but can be configured to significantly improve work flow and tracking of referrals using VistA. Matt King is one who has had a lot of experience with this at Clinica Adelante and can probably advise us on how to do this very effectively. Others who have done it should also be approached for their suggestions. | 4. Provider referrals needs to be configured to work well in the clinical setting for most out patient facilities. It is designed to handle referrals to other physicians within the same facility, but can be configured to significantly improve work flow and tracking of referrals using VistA. Matt King is one who has had a lot of experience with this at Clinica Adelante and can probably advise us on how to do this very effectively. Others who have done it should also be approached for their suggestions. | ||
Latest revision as of 12:48, 1 April 2012
Enable a user to electronically record, store, retrieve and manage, at a minimum, the following order types:
- Medications
- Laboratory
- Radiology/Imaging
- Provider referrals
1. Medication ordering requires interaction checking, formulary checking, insurance checking, Allergy etc. ePrescibing will endeavor to handle this and Oroville hospital is in the process of setting this up and will release the code into open source when it is done. For local printing of prescriptions for hand carrying to the pharmacy, the autofinish can be used. This is all a difficult problem because ePrescribing is not standardized and there are multiple ePrescribing databases that need to be mapped to RxNorm for meaningful use and that mapping is not available freely available. Local drug ordering databases need to be mapped as well. In addition, the problem of quality recording raises its head because that requires that NDC codes, not RxNorm be used in reporting the appropriate performance measures. And medication allergies need to be coded in a way that the Allergy cross checking or ingredients can be done recognizing the drugs that contain that ingredient, probably by mapping them to RxNorm.
2. Laboratory orders for laboratories that are not in-house need to be transmitted to the laboratory that is appropriate for the patient's insurance and the proper ICD9 codes and tests ordered depending on the lab being used. If the orders are not sent (usually HL7) that an alternative incoming processing system will need to be set up to handle these transmitted results which will require some coding. The VistA Lab Project which generally meets on Monday nights will be tackling this problem but it is on hiatus right now. Interfaces with labs are difficult and are probably best processed sending HL7 messages to Mirth and the Mirth used to help facilitate matching up the data transmitted from VistA to the HL7 messages that the lab wishes to receive. The HL7 setup process itself needs documentation for those of us who are not very sophisticated at it and I understand that there is such an effort going on on the Medsphere web site.
3. Radiology referrals need to be made out using the proper templates to provide the necessary information and instructions for the patient for various procedures as well as providing the necessary clinical information for the radiologist depending on the procedure. In the setting with no radiology department, this will need to be sent to someone to process or print out to hand to the patient and some sort of status Recorded. The existing processes in VistA can be adapted to do this, but it requires some setup, documentation of that set u and analysis of the process for various settings. This requires a considerable amount of work to be entered here.
4. Provider referrals needs to be configured to work well in the clinical setting for most out patient facilities. It is designed to handle referrals to other physicians within the same facility, but can be configured to significantly improve work flow and tracking of referrals using VistA. Matt King is one who has had a lot of experience with this at Clinica Adelante and can probably advise us on how to do this very effectively. Others who have done it should also be approached for their suggestions.
I believe Matt handled this by sending the consult to someone assigned the job of sending the referral to the consultant selected. This might be by fax, etc. I believe consult services are set up and referral documents set up using a template that has some prepopulated objects in it - demographics, etc., and the person responsible for seeing that they get sent out is sent an alert. The the "consult service" is actually a group/person set up to process the consult. Various requirements can be set up for each sort of "consult service," like certain lab results of pulmonary funcion test results, EKGs, etc. Much of this can be set up under the Consult Management CMRC MGR option using Setup a consult service (SS).
Consult responses are set up as special TIU notes for scanned responses and the provider receiving the consult has a special note title to process it and is responsible for setting the consult status to completed.
Detailed documentation for how this is done with other variations needs to be entered here.
