The ballot for the ONC S&I Framework Consolidated CDA IGs closed earlier this month. The response was overwhelming.
There were a total of 554 comments submitted. Of these, 277 were negative.
The HL7 ballot process requires that all negative comments be addressed, resolved and withdrawn by the submitters. So, there is a lot of work to be done before the consolidated guides are approved. This is important, because the ONC would like the consolidated guides to be used for Meaningful Use Stage 2.
The HL7 Structured Documents Working Group (SDWG) resolved 56 negatives during the Orlando Working Group meeting.
A number of the negative votes are publishing related, and we will begin looking at these during today's CDA Documentation call.
Reconciliation will continue to take place on the two ONC calls on Tuesday and Wednesday and during the regular HL7 SDWG call on Thursdays.
I hope to map out a strategy for getting the final Consolidated Guides published using MDHT. We will start that work and not wait for reconciliation to be completed.
It should be a busy summer.
The ONC S&I Framework teams will meet next month in Washington, DC for two days and we hope to get more work done then.
Showing posts with label informatics. Show all posts
Showing posts with label informatics. Show all posts
Wednesday, May 25, 2011
Tuesday, April 5, 2011
The relationship between Documents, Sections and Clinical Statements
The content for a clinical document is specified using Sections and Clinical Statements as building blocks.
Each Clinical Document contains exactly one header. The content of the Header is defined by the US Realm Header Template.
Each Clinical Document contains one or more sections. The content of a section is defined by its Section Template.
Each Section contains zero or more Clinical Statements. Some Sections are “narrative only” and do not contain any Clinical Statements. The content of a Clinical Statement is defined by its Clinical Statement Template.
This approach allows each document that contains an Allergy Section to use the same rules for constructing that section.
This approach allows each section that contains a Procedure Activity to use the same rules for constructing that Clinical Statement.
Sunday, January 23, 2011
Scheduling Interface and the Big Picture
I've been working on a project to replace existing interfaces to our old practice management system and redirect them to the replacement PM system. We're also adding new functionality and interfaces, too. Sometimes, it's important to think about what the business use of the messages is. Many times, the old system did things the way that it does because it made sense to do it that way ten or fifteen years ago. Simply replicating that process with the new system may not be the best way to go.
Here is an example.
Our doctors practice in several local hospitals. Our agreement with the hospitals is that we will bill for the procedures that our doctors perform there. We will bill for the professional charges, and the hospital will bill for the administrative charges. The trick is to figure out what we should bill for.
Our doctors use the hospital's computer systems when they deliver care there.
This hopital sends us a stream of scheduling messages. We do not get a stream of ADT messages from this hospital. That would be too easy.
The current system looks through the scheduling messages to see if there were appointments today that we do not have encounters in the practice management system. If not, it creates one. This will create an empty encounter that someone in the billing office will notice. They will follow up with the doctor to see what procedures were performed so that we can figure out what to bill.
Now, the scheduling stream is every appointment at the hospital clinics. Some patients will schedule a procedure up to a year in the future. This could be an annual mammogram, for example. Now, that appointment can, and probably will, change many times before the patient actually has that encounter. Keeping track of this in an interface engine will be very difficult.
I decided that I would save all of the messages and would have another process that would look at messages for encounters that are scheduled for today and check those against existing encounters in the practice management system. This would involve a database lookup. If there was no encounter, I would translate the scheduling message into a registration message and send that to the practice management system to create the encounter.
As I was trying to decide how I would replicate the existing logic, I realized that it would be very error prone. I could have the original appointment message for an encounter today, but if there is a later message that rescheduled or cancelled that appointment, this logic would create an encounter that never happened.
So, as I thought about how I would implement a system that would manage the appointments, I wondered if there might be a better way. Why should I have to create a logic in the interface engine to manage appointments and schedules? Could I find a system that would do that for me?
Then, it hit me. What if I simply sent the scheduling messages to the Practice Management system and let it manage the appointments? After all, that is one of the functions of a PM system.
Hmmmm.... I thought about it for a few moments.
Then, I asked Pam, our PM expert, how the PM system would handle an appointment without an encounter. She said that it would show up as a "no show" in an audit report. So, the business owners could use this "no show" report to follow up with the doctors to determine the billable procedures that occurred in this encounter.
This has the advantage of also having the schedule for these locations in our PM system.
We still need to follow up with the business owners to see if getting the information in this way would meet their needs.
We are building a mock-up of the new system to see what it might look in a test environment. I will create this schedling interface and we can see if this will work.
The moral to this story is that implementing a new system is an opportunity to do things better. If you keep your head down and simply replicate existing functions, you lose an opportunity to improve things. Of course, this requires that you actually understand what the old system does at an operational level, and not simply at a tactical level.
Here is an example.
Our doctors practice in several local hospitals. Our agreement with the hospitals is that we will bill for the procedures that our doctors perform there. We will bill for the professional charges, and the hospital will bill for the administrative charges. The trick is to figure out what we should bill for.
Our doctors use the hospital's computer systems when they deliver care there.
This hopital sends us a stream of scheduling messages. We do not get a stream of ADT messages from this hospital. That would be too easy.
The current system looks through the scheduling messages to see if there were appointments today that we do not have encounters in the practice management system. If not, it creates one. This will create an empty encounter that someone in the billing office will notice. They will follow up with the doctor to see what procedures were performed so that we can figure out what to bill.
Now, the scheduling stream is every appointment at the hospital clinics. Some patients will schedule a procedure up to a year in the future. This could be an annual mammogram, for example. Now, that appointment can, and probably will, change many times before the patient actually has that encounter. Keeping track of this in an interface engine will be very difficult.
I decided that I would save all of the messages and would have another process that would look at messages for encounters that are scheduled for today and check those against existing encounters in the practice management system. This would involve a database lookup. If there was no encounter, I would translate the scheduling message into a registration message and send that to the practice management system to create the encounter.
As I was trying to decide how I would replicate the existing logic, I realized that it would be very error prone. I could have the original appointment message for an encounter today, but if there is a later message that rescheduled or cancelled that appointment, this logic would create an encounter that never happened.
So, as I thought about how I would implement a system that would manage the appointments, I wondered if there might be a better way. Why should I have to create a logic in the interface engine to manage appointments and schedules? Could I find a system that would do that for me?
Then, it hit me. What if I simply sent the scheduling messages to the Practice Management system and let it manage the appointments? After all, that is one of the functions of a PM system.
Hmmmm.... I thought about it for a few moments.
Then, I asked Pam, our PM expert, how the PM system would handle an appointment without an encounter. She said that it would show up as a "no show" in an audit report. So, the business owners could use this "no show" report to follow up with the doctors to determine the billable procedures that occurred in this encounter.
This has the advantage of also having the schedule for these locations in our PM system.
We still need to follow up with the business owners to see if getting the information in this way would meet their needs.
We are building a mock-up of the new system to see what it might look in a test environment. I will create this schedling interface and we can see if this will work.
The moral to this story is that implementing a new system is an opportunity to do things better. If you keep your head down and simply replicate existing functions, you lose an opportunity to improve things. Of course, this requires that you actually understand what the old system does at an operational level, and not simply at a tactical level.
Monday, May 25, 2009
More on Meaningful Use
I wrote earlier about what Meaningful Use is and why it is important. Recall that providers will be reimbursed for purchases of certified HIT products and that they will then recieve financial incentive for the "meaningful use" of that technololgy, but all that the legislation says is that meaningful use is:
1. ePrescribing
2. participation in an HIE
3. submission of quality measures
The importance of the definition is that it is the first step in a process that involves many others.
1. The HIT Standards committee will need to select the standards and implementation guides that support meaningful use
2. The certification body (which may be CCHIT, but HHS has not confirmed this) will need to align its certification criteria with these
3. Vendors may need to adjust their EHR Systems to ensure that it meets the criteria. This may require recertification.
4. HealthCare Organizations (HCOs) that already have technology in place may need to upgrade or adjust their systems so that they can meet the meaningful use criteria. Those organizations that do not have EHRs in place will likely wait until the vendors have caught up with the certification criteria before they begin implementing.
Until the definition is published, we can guess at what they mean, and try to be ready for it.
Money becomes available for the purchase of "certified" EHR systems in October, 2010. So, the timing is extremely tight.
These dates are from the recovery.gov website:
http://www.recovery.gov/?q=content/program-plan&program_id=5299
Standards Rulemaking: Recovery Act §3004 (B) (1) - No later than December 31, 2009, HHS shall adopt and publish an initial set of standards, implementation specifications, and certification criteria. The rulemaking for this initial set of standards, implementation specifications, and certification criteria may be issued on an interim, final basis. Fully competitive contract awards will be utilized to support the impact analysis.
Milestones:
Complete Draft Rule/ Regulatory Impact Analysis. Start: 05/01/2009 End: 08/26/2009
Submit for HHS Clearance. Start: 08/26/2009 end: 09/25/2009
Clear OMB (up to 90 day process) Start: 09/25/2009 End: 12/24/2009
Publish in Federal Register. Start: 12/24/2009 End: 12/31/2009
So, if the HIT Standards Committee is to meet the deadline of submitting the list of standards that are required to support “meaningful use” (August 26), the definition has to be published very, very soon.
1. ePrescribing
2. participation in an HIE
3. submission of quality measures
The importance of the definition is that it is the first step in a process that involves many others.
1. The HIT Standards committee will need to select the standards and implementation guides that support meaningful use
2. The certification body (which may be CCHIT, but HHS has not confirmed this) will need to align its certification criteria with these
3. Vendors may need to adjust their EHR Systems to ensure that it meets the criteria. This may require recertification.
4. HealthCare Organizations (HCOs) that already have technology in place may need to upgrade or adjust their systems so that they can meet the meaningful use criteria. Those organizations that do not have EHRs in place will likely wait until the vendors have caught up with the certification criteria before they begin implementing.
Until the definition is published, we can guess at what they mean, and try to be ready for it.
Money becomes available for the purchase of "certified" EHR systems in October, 2010. So, the timing is extremely tight.
These dates are from the recovery.gov website:
http://www.recovery.gov/?q=content/program-plan&program_id=5299
Standards Rulemaking: Recovery Act §3004 (B) (1) - No later than December 31, 2009, HHS shall adopt and publish an initial set of standards, implementation specifications, and certification criteria. The rulemaking for this initial set of standards, implementation specifications, and certification criteria may be issued on an interim, final basis. Fully competitive contract awards will be utilized to support the impact analysis.
Milestones:
Complete Draft Rule/ Regulatory Impact Analysis. Start: 05/01/2009 End: 08/26/2009
Submit for HHS Clearance. Start: 08/26/2009 end: 09/25/2009
Clear OMB (up to 90 day process) Start: 09/25/2009 End: 12/24/2009
Publish in Federal Register. Start: 12/24/2009 End: 12/31/2009
So, if the HIT Standards Committee is to meet the deadline of submitting the list of standards that are required to support “meaningful use” (August 26), the definition has to be published very, very soon.
Subscribe to:
Posts (Atom)