Recently a prospect presented the following scenario:
High number of facilities
Fax is the current communication method between facilities and the lab
Faxes are handled by humans at both the facilities and at the lab
How can we improve our process?
The techniques described below can be put into practice in low volume situations as well.
While the ideal would be to eliminate faxes entirely with, for example, a web site or an email-technique, or, ideally, direct application integration, these techniques all require a change on the part of the faciltiy; something that is often too hard to accomplish.
So, what can you do with faxes to improve the process through reducing labor effort and reducing errors?
Phase 1 (Fax Server)
Implement a fax server at the lab. A fax server can send and receive faxes without a human handling the paper.
At the lab, the fax server can be configured to receive fax as electronic files based upon the number that originated the fax. As an example, Facility A faxes from fax number A. When the fax is received at the lab by the fax server, the fax server detects that the fax originated at fax number A and therefor places the fax file into a directory accessed by the clerk that works on faxes from facility A. alternatively, the fax server can be configured to email the fax file to the clerk. Variations on this theme include uploading the fax file into a workflow system that automates the routing of the fax.
At the lab, the fax server can be configured to send faxes to facilities, such as Facility A. An easy way to do this is through a "fax printer" accessible from the Windows Print environment at each desktop. This makes it trivial to "print" the lab results directly from the lab application and have the results, with a header page, fax out to Facility A.
Phase 2 (Workflow)
Implement case processing at the lab. Case Processing quickly automates manual steps in a process. As an example, the inbound fax might contain an order for a single patient to perform multiple tests or it might contain multiple patients for the same test or a combination. Case Processing automates presenting to a human the fax and enabling that person to quickly key the correct test orders. It then can queue up the individual test into multiple testers queues in an appropriate priority order. When the tests are completed, the results can be matched to each of the orders, the orders assembled into a single fax, and the fax sent out to the correct facility.
Phase 3 (OCR)
Implement Optical Character Recognition at the lab to reduce the manual data entry from Phase 1 above. In particular, OCR can detect a facility identifier, the individual patient medical record numbers (MRN), and, if the fax form has been configured effectively, it could detect which tests to perform. In this way, the bulk of the work performed by a human in Phase 1 can be reduced. It can't be eliminated, because OCR always has errors that need to validated, but it can significantly reduce the human effort required.
Additional techniques to improve the above include:
1. use "comb" style hand-print constraints:
Open comb fields (i.e. no line on top)
o Cells must have a U shape (otherwise they might be recognized as an "L"
o Tick marks in between characters must be of the same height but use a high mark to separate words or sections (SSN or date are good examples)
2. provide "turn-around" documents whenever possible
Turn-around documents are those that originate at the lab, sent to the facility, are adjusted by the facility, and returned. Examples might include a "orders approval" form that lists every lab to be performed for every patient. The key benefit of turn-around documents is that the lab has complete control of the placement of content on the form, as well as the ability to uniquely identify each page - this enables the OCR product to know what the form is exactly and then do the recognition of the text based on known locations for the content. Besides, the facility people will have to do less work.
Tuesday, July 20, 2010
Friday, July 2, 2010
ONC's Temporary Certification Program (provider-focus)
Today ONC conducted another teleconference to inform providers that have built their own solutions how they will be affected by the Certification Program.
Carol Bean, Director of Certification
Steve Pozniak, Director of Federal Policy
http://healthit.hhs.gov/portal/server.pt has a listserv to inform us.
Both Carol and Steve said basically the same as yesterday. See my previous post.
Each ATCB must provide testing for onsite (at the ATCB's facility) and remote for both development and deployment sites. The deployment site is typically the Providers facility.
Carol Bean, Director of Certification
Steve Pozniak, Director of Federal Policy
http://healthit.hhs.gov/portal/server.pt has a listserv to inform us.
Both Carol and Steve said basically the same as yesterday. See my previous post.
Each ATCB must provide testing for onsite (at the ATCB's facility) and remote for both development and deployment sites. The deployment site is typically the Providers facility.
Adding functionality to your existing solution that has been certified does not require that you re-certify.
Questions & Answers
- What is an EHR Module?
- It's anything that meets at least 1 certification requirement. For example, a Problem List could be an EHR Module (thought it's unlikely). another example might be a List module (Problem, Medication, Treatment, etc) that too could be an EHR Module.
- We use both a complete EHR and self-developed software. Will we need to certify the self-developed software too?
- If you have a hybrid then you'll have to test and certify the self-developed software.
- Does previous CCHIT certification flow-on? Grandfather clause....
- No.
- What is the process for getting certified?
- That depends upon the ATCB.
- what if you've got 3 certified complete EHRs and you're using parts of each at different facilities. Is it sufficient that the 3 EHRs have been certified?
- A clear answer wasn't provided, in my view.
- Would self-attestation suffice?
- You'll have to check with CMS - incentive payment question.
- What testing methods are required?
- Testing methods approved by ONC.
- What if you're running previous version of certified EHRs or highly customized solutions, what certifications are required?
- Get your system certified.
- What kind of cost are we looking at?
- 14 applications were sent out - it would be great if all of them achieved accreditation.
- Assuming the legacy environment and I get it certified, how long does the certification last?
- Let's say you get tested at Stage 1 (10 measures) and then we set Stage 2 (13 measures), you'll then need to re-certify.
Thursday, July 1, 2010
ONC's Temporary Certification Program
Today, ONC hosted a telephone conference to update Health IT Developers and Vendors of EHR technology on the Temporary Certification Program.
The temporary rule has been published as updates to 45 CFR Part 170 (HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY) Robin Raiford bookmarked the Federal Register version.
The speakers were:
Carol Beam, Director of Certification and Testing, ONC
Steve Posnack, Director of Policy, ONC
The rules serve two purposes:
This rule paves the way for vendors to get their products tested and certified.
Some of the parameters around testing include:
Section 170.420 - the Principals of Proper Conduct
ATCBs must support testing of both developed and deployed solutions
170.445 & 450
ATCBs must also support testing of both complete EHRs and EHR modules.
The following were questions posed by the audience.
The temporary rule has been published as updates to 45 CFR Part 170 (HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY) Robin Raiford bookmarked the Federal Register version.
The speakers were:
Carol Beam, Director of Certification and Testing, ONC
Steve Posnack, Director of Policy, ONC
The rules serve two purposes:
- Established the process for the National Coordinator to select ONC's Authorized Testing and Certification Body (ATCB)
- Set some of the parameters around the testing itself.
This rule paves the way for vendors to get their products tested and certified.
Some of the parameters around testing include:
Section 170.420 - the Principals of Proper Conduct
ATCBs must support testing of both developed and deployed solutions
170.445 & 450
ATCBs must also support testing of both complete EHRs and EHR modules.
The following were questions posed by the audience.
- What is a new version? (ie does a bug release constitute a new version)
- If an EHR developers defines it as a new release, then they will require a new certificate.
- How does a customer claim certification? (ie do they have to provide some sort of proof of sale / license)
- The Certified Health IT Product list will be managed by ONC and that website will be the source of truth. For Meaningful Use reporting, a unique identifier will be assigned to each bundle of products that in combination achieve Meaningful Use requirements.
- What if a solution is offered both bundled and un-bundled?
- There will be unique identifiers for each (bundled and un-bundled). ONC will not be testing whether they are actually being used - that's a function of the audit (CMS).
- What bodies will provide oversight of both the ATCB and the developers?
- in the temporary program, ONC will provide oversight of ATCB (adhere to the Principals of Proper Conduct)
- in the permanent program, vendors will be subject to a post-market surveillance program
- What will the certification cost?
- CCHIT had presented potential pricing ranges - we generally used those as our estimates. We're hoping that the competitive environment that we hope we've created will reduce those costs.
- Will there be a "seal" of certification?
- We require that the ATCBs tell the developers to convey to prospective purchasers and customers: product name, date of certification, certification number, etc. We don't specify a particular image.
- What about Clinical Quality Measures?
- When a product is ready to be certified, the measures will have to have been published.... Stay tuned.
- What about additional software that may be required?
- The additional software will have to be identified and listed.
Tuesday, June 29, 2010
Linking your ECM solution with your EMR
Recently I worked with Steve Sawyer from the Mayo Health System to produce a webinar in which Steve discusses why Mayo decided to acquire an ECM system and then to link it to their enterprise EMR. Steve's done some remarkable work and Mayo, though only about a quarter of the way through their enterprise deployment, has begun to achieve good returns. Most importantly, the docs like the solution!
Register to watch the webinar.
Register to watch the webinar.
Monday, June 28, 2010
Leadership is hard work
General McChrystal has been fired. I have to admit that I was stunned to read his remarks in Rolling Stone - they reflect very poorly on his leadership; which is a shame, given his remarkable performance in the past.
As a staff officer, I often commiserated with my peers and with my subordinates about our higher-ups - we often used the phrase Echelons Above Reality to refer to our higher-ups, which was a play on the phrase EAC (Echelons above Corps) . And we often had much harsher phrases for individuals that were in staff and sometimes command positions above us. I've seen that kind of behavior in commerce, government and the military so I think it's fairly common.
As a commander, however, the situation was much different . Everything you do, everything you say, everything you write, and all the body language you send out is scrutinized, evaluated, assessed, and probed. It's the nature of the job. As a consequence, I was extremely careful about what I said, when I said it, how I said it, to whom I said it, and the body language I presented. And I'm not a 4-star general.
So, was General McChrystal being immature? Was he somehow caught off-guard?
Or, did he do as I did: prepare ahead of time for every encounter and go into every encounter with a plan to achieve a specific outcome?
My thinking is the later - he knew what he was doing and very specifically chose to do what he did.
What I can't figure out is why? What was he planning on achieving?
As a staff officer, I often commiserated with my peers and with my subordinates about our higher-ups - we often used the phrase Echelons Above Reality to refer to our higher-ups, which was a play on the phrase EAC (Echelons above Corps) . And we often had much harsher phrases for individuals that were in staff and sometimes command positions above us. I've seen that kind of behavior in commerce, government and the military so I think it's fairly common.
As a commander, however, the situation was much different . Everything you do, everything you say, everything you write, and all the body language you send out is scrutinized, evaluated, assessed, and probed. It's the nature of the job. As a consequence, I was extremely careful about what I said, when I said it, how I said it, to whom I said it, and the body language I presented. And I'm not a 4-star general.
So, was General McChrystal being immature? Was he somehow caught off-guard?
Or, did he do as I did: prepare ahead of time for every encounter and go into every encounter with a plan to achieve a specific outcome?
My thinking is the later - he knew what he was doing and very specifically chose to do what he did.
What I can't figure out is why? What was he planning on achieving?
Friday, June 18, 2010
How to use eSignature with your EMR and your DM system
eSignature is a term that refers to applying some sort of signature to an electronic document.
One illustration of eSignature is when a physcian reviews and approves an electronic document - perhaps a progress note that has been scanned and linked to a patient encounter.
There are several common requirements:
1. an audit trail must be retained that provides access details regarding changes to the document, including the signature. Usually this audit trail will provide user and date / time stamps for each action taken with the document. For example, when a physician affixes his / her signature to the document, the physician's details and date / time are recorded.
2. the original document needs to be altered in both a visual and a physical manner. Often the signature is a text string, "Approved and digitally signed by John Smith, MD on June 18, 2010 at 1:07 PM ET." and the text is over-layed at a selected location on the document image; thus, visually the document has been altered. Next, a new document is created that "burns' the signature into the image, permanently changing the image with the signature.
3. the workflow associated with applying the signature varies but in general follows: HIM analyst identifies who needs to approve / sign the document and where on the document the signature needs to be placed. Next, the document is routed to those that need to review & sign. The people that need to do the reviewing / signing are presented with options (approve / sign, reject) and make their selection. Those that have been approved for signature are then signed and a new document created with the signature. Finally, references to the unsigned-document are translated so that only the new, signed document is returned to users.
In terms of integrating the eSignature capability among multiple systems, usually an EMR for the user interface and a DM system for managing the documents, I recommend that you rely on the EMR's workflow to manage user interaction. The key reason for this approach is that the EMR provides a consistent UI for the most critical user - the doctor. There are other reasons too (such as the EMR typically implements a role-based security model and it usually has a chart deficiency module to control the workflow), but not having to train the doctors is essential.
One illustration of eSignature is when a physcian reviews and approves an electronic document - perhaps a progress note that has been scanned and linked to a patient encounter.
There are several common requirements:
1. an audit trail must be retained that provides access details regarding changes to the document, including the signature. Usually this audit trail will provide user and date / time stamps for each action taken with the document. For example, when a physician affixes his / her signature to the document, the physician's details and date / time are recorded.
2. the original document needs to be altered in both a visual and a physical manner. Often the signature is a text string, "Approved and digitally signed by John Smith, MD on June 18, 2010 at 1:07 PM ET." and the text is over-layed at a selected location on the document image; thus, visually the document has been altered. Next, a new document is created that "burns' the signature into the image, permanently changing the image with the signature.
3. the workflow associated with applying the signature varies but in general follows: HIM analyst identifies who needs to approve / sign the document and where on the document the signature needs to be placed. Next, the document is routed to those that need to review & sign. The people that need to do the reviewing / signing are presented with options (approve / sign, reject) and make their selection. Those that have been approved for signature are then signed and a new document created with the signature. Finally, references to the unsigned-document are translated so that only the new, signed document is returned to users.
In terms of integrating the eSignature capability among multiple systems, usually an EMR for the user interface and a DM system for managing the documents, I recommend that you rely on the EMR's workflow to manage user interaction. The key reason for this approach is that the EMR provides a consistent UI for the most critical user - the doctor. There are other reasons too (such as the EMR typically implements a role-based security model and it usually has a chart deficiency module to control the workflow), but not having to train the doctors is essential.
Friday, May 14, 2010
Document Management in Healthcare
What is Document Management?
For a variety of definitions from the Web, click here.
I like examples to illustrate definitions so here's mine from heatlhcare.
Most doctor's offices have a room in which they store patient folders, often referred to as charts. In these folders are stored the paper that describes the care provided to the patient and typically includes
Usually these folders have tabs that segregate the documents and nearly always the documents are organized so that the most recent document is at the top - this is an illustration of the Last In / First Out principle.
From a volume perspective, in the US, there are approximately 400 patients / doctor overall. But for primary care physicans, the patients / doctor ratio is in the thousands and likely close to 4,000 patients per doctor. So, a brand new, single-physican practice after a year will likely have 4,000 charts. Established single-physican practices have ~10,000 charts and established multi-physican practices can reach 100,000 charts fairly quickly.
Put another way, doctor's offices have thousands of paper folders stuffed with paper.
If your labor costs are low, then relying on people to manage folders is a good use of money. On the other hand, as your labor costs rise, the value of automation increases.
One simple automation is to convert the paper stored in the folders to images and make those images availble to physicians. We do this by using a piece of hardware known as a scanner - a scanner takes paper and creates electronic pictures of the pages. Staff then identifies each picture (this is known as indexing) and the picture is added to a software application known as a Document Management system. In turn, the physician can type the patient's name and all of the scanned documents are listed for the physician to view. The physician selects a document to view, and it is displayed.
Abstracting this illustration leads one to other paper-intensive markets such as insurance, financial services, government, engineering, and so on. Abstracting this illustration also leads one to other content-intestive applications, such as law firms, web sites, marketing , and so on
While each of the above have unique requirements for which vendors have created specialist applications, they all fall into the broad category of Document Management applications.
For a variety of definitions from the Web, click here.
I like examples to illustrate definitions so here's mine from heatlhcare.
Most doctor's offices have a room in which they store patient folders, often referred to as charts. In these folders are stored the paper that describes the care provided to the patient and typically includes
- physician notes that detail how the patient presented, what was discussed, symptoms that the physician assessed, the diagnosis the physician arrived at, and the treatment / prescriptions ordered to address the symptoms
- medical laboratory results from tests perfomed due to physician orders
- prescriptions ordered
- medical histories, often completed jointly by the patient and a nurse or the physician
- and similar content.
Usually these folders have tabs that segregate the documents and nearly always the documents are organized so that the most recent document is at the top - this is an illustration of the Last In / First Out principle.
From a volume perspective, in the US, there are approximately 400 patients / doctor overall. But for primary care physicans, the patients / doctor ratio is in the thousands and likely close to 4,000 patients per doctor. So, a brand new, single-physican practice after a year will likely have 4,000 charts. Established single-physican practices have ~10,000 charts and established multi-physican practices can reach 100,000 charts fairly quickly.
Put another way, doctor's offices have thousands of paper folders stuffed with paper.
If your labor costs are low, then relying on people to manage folders is a good use of money. On the other hand, as your labor costs rise, the value of automation increases.
One simple automation is to convert the paper stored in the folders to images and make those images availble to physicians. We do this by using a piece of hardware known as a scanner - a scanner takes paper and creates electronic pictures of the pages. Staff then identifies each picture (this is known as indexing) and the picture is added to a software application known as a Document Management system. In turn, the physician can type the patient's name and all of the scanned documents are listed for the physician to view. The physician selects a document to view, and it is displayed.
Abstracting this illustration leads one to other paper-intensive markets such as insurance, financial services, government, engineering, and so on. Abstracting this illustration also leads one to other content-intestive applications, such as law firms, web sites, marketing , and so on
While each of the above have unique requirements for which vendors have created specialist applications, they all fall into the broad category of Document Management applications.
Subscribe to:
Posts (Atom)
