I blogged about this project earlier.
http://jira.siframework.org/wiki/display/SIF/CDA+Consolidation+Project
Basically, this is a project that is sponsored by the Office of National Coordinator for Health Care IT (ONC) to consolidate and harmonize eight of the CDA IGs that are required for Meaningful Use. I am participatign in my role as the Publishing Facilitator for the HL7 Structured Documents Work Group, which owns the IGs and will be the sponsoring committee when the documents are ballotted in HL7.
Some very smart people have developed tools that will enable us to create a single library of CDA Templates and constraints and publish the IGs
The Model Driven Health Tools (MDHT) from the Open Health Tools (OHT) project will be used to generate the IGS. MDHT is based on the Eclipse workbench. The actual prose for the IGs will be created using the Darwin Information Typing Architecture (DITA). The tools will transform the models and DITA into a variety of output formats.
https://www.projects.openhealthtools.org/sf/projects/mdht/
http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html#ditaspec
I've seen Eclipse before, but this is my first exposure to MDHT and DITA. I think that I understand how the tool integrates the modelling and vocabulary information with the publishing aspect, but I am still learning.
The main group has been meeting since the first week of January. The publishing sub-group will begin meeting next week.
The intent is to ballot these IGs in the May HL7 ballot cycle, so we have a lot to accomplish in a very short period of time. We will also explore how we can better integrate the IG generation and publication process into the HL7 Publishing process. It would be good if all of the CDA IGs can be generated using these tools. This would enable consistent formatting.
There are two other S&I Framework projects that will kickoff next week. These are the Transition of Care (TOC) Initiative and and the Laboratory Interface Initiative. I do not have time to participate in either of those. I'll be busy enough with my day job and the CDA IG Consolidation project.
Saturday, January 29, 2011
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.
Sunday, January 9, 2011
Lab Results and Abnormal Flags
We're in the final testing of a lab results interface with a local hospital. They will send us results messages and we will place those results into the Patient's chart so that our Doctors can view the results in our EHR. Their lab system will not accept order messages from us, so we are faxing the orders to them and they are manually entering the orders. The results come back to us as an ORU^R01 message.
Late in the testing, we discovered that some results were not displaying correctly. The values were correct. The NextGen EHR will display results that are Low, High or Abnormal in a different color to make it easier for the provider to recognize. This is meta-data in that it describes the results. This information is carried in the message in the OBX-8 Abnormal Flags field.
The sending lab system is using non-standard codes in this field. Technically, the values for OBX-8 are in the User Defined Table 0078, which means that they can use whatever they want in there. Many years ago, they defined their own abnormal flags.
The values in HL7 Table 0078 are below.
Value -- Description Comment
L -- Below low normal
H -- Above high normal
LL -- Below lower panic limits
HH -- Above upper panic limits
< -- Below absolute low-off instrument scale
> -- Above absolute high-off instrument scale
N -- Normal (applies to non-numeric results)
A -- Abnormal (applies to non-numeric results)
AA -- Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units)
null -- No range defined, or normal ranges don't apply
U -- Significant change up
D -- Significant change down
B -- Better--use when direction not relevant
W -- Worse--use when direction not relevant
S -- Susceptible. Indicates for microbiology susceptibilities only.
R -- Resistant. Indicates for microbiology susceptibilities only.
I -- Intermediate. Indicates for microbiology susceptibilities only.
MS -- Moderately susceptible. Indicates for microbiology susceptibilities only.
VS -- Very susceptible. Indicates for microbiology susceptibilities only.
The sending system told us that they would not change the codes that they use.
I was already using a Rhapsody Mapper to make changes to the incoming result message before I sent it to NextGen. So, I needed to translate their Abnormal Results codes into the ones that NextGen uses. There are a limited number of codes to translate, and the code sets are fairly static. I have done this sort of code translation using interface engines before. It is very common. The technique varies. Cloverleaf has a separate component that is used to translate codes.
I have use database tables to translate codes in Rhapsody before. We recently upgraded to Rhapsody version 4.0, and it supports Translate Tables in a way that does not require using a database. I had not used this technique before, so I got to learn something new. You create the translate table using the IDE and can maintain it using either the IDE or from the web based Management Console. Once I had the table created, I needed to add a single line of code to the Mapper to translate the code.
I made the change to the test route and replayed several results messages to verify that Low, High and Abnormal results are displayed in the correct color in the EHR.
Because I had not used this technique before, the change took about half a day to develop, code and test.
The Management Console will allow us to view the codes that failed to translate. That is, when we get a message that contains a code that is not in the translate table, we will be able to see that and possibly add the new code to the translation table. I don't expect this to happen, because it sounds like they have been using their non-standard codes for many years.
The sending lab system will have to adopt the Abnormal Flags values from Table 0078 to achieve Meaningful Use, as both of the Implementation Guides (Lab to EHR and Public Health) have specified the use of the values that are in the standard.
Late in the testing, we discovered that some results were not displaying correctly. The values were correct. The NextGen EHR will display results that are Low, High or Abnormal in a different color to make it easier for the provider to recognize. This is meta-data in that it describes the results. This information is carried in the message in the OBX-8 Abnormal Flags field.
The sending lab system is using non-standard codes in this field. Technically, the values for OBX-8 are in the User Defined Table 0078, which means that they can use whatever they want in there. Many years ago, they defined their own abnormal flags.
The values in HL7 Table 0078 are below.
Value -- Description Comment
L -- Below low normal
H -- Above high normal
LL -- Below lower panic limits
HH -- Above upper panic limits
< -- Below absolute low-off instrument scale
> -- Above absolute high-off instrument scale
N -- Normal (applies to non-numeric results)
A -- Abnormal (applies to non-numeric results)
AA -- Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units)
null -- No range defined, or normal ranges don't apply
U -- Significant change up
D -- Significant change down
B -- Better--use when direction not relevant
W -- Worse--use when direction not relevant
S -- Susceptible. Indicates for microbiology susceptibilities only.
R -- Resistant. Indicates for microbiology susceptibilities only.
I -- Intermediate. Indicates for microbiology susceptibilities only.
MS -- Moderately susceptible. Indicates for microbiology susceptibilities only.
VS -- Very susceptible. Indicates for microbiology susceptibilities only.
The sending system told us that they would not change the codes that they use.
I was already using a Rhapsody Mapper to make changes to the incoming result message before I sent it to NextGen. So, I needed to translate their Abnormal Results codes into the ones that NextGen uses. There are a limited number of codes to translate, and the code sets are fairly static. I have done this sort of code translation using interface engines before. It is very common. The technique varies. Cloverleaf has a separate component that is used to translate codes.
I have use database tables to translate codes in Rhapsody before. We recently upgraded to Rhapsody version 4.0, and it supports Translate Tables in a way that does not require using a database. I had not used this technique before, so I got to learn something new. You create the translate table using the IDE and can maintain it using either the IDE or from the web based Management Console. Once I had the table created, I needed to add a single line of code to the Mapper to translate the code.
I made the change to the test route and replayed several results messages to verify that Low, High and Abnormal results are displayed in the correct color in the EHR.
Because I had not used this technique before, the change took about half a day to develop, code and test.
The Management Console will allow us to view the codes that failed to translate. That is, when we get a message that contains a code that is not in the translate table, we will be able to see that and possibly add the new code to the translation table. I don't expect this to happen, because it sounds like they have been using their non-standard codes for many years.
The sending lab system will have to adopt the Abnormal Flags values from Table 0078 to achieve Meaningful Use, as both of the Implementation Guides (Lab to EHR and Public Health) have specified the use of the values that are in the standard.
Saturday, January 1, 2011
2010 in Review
It was an interesting year.
I started a new job in January. I'm building interfaces for the Wayne State University Physician Group in Detroit, MI. They have existing interfaces that were built by a person that is no longer there, so my first task was to redirect those interfaces to "pass through" the Rhapsody interface engine so that I could actually see the messages. I started planning for redirecting those interfaces when we replace our practice management system. The PM migration has taken longer than any of us expected.
I finished my Masters Degree in Medical Informatics in June. I went to Evanston for the graduation ceremony with my parents. I had family and friends over to my house to celebrate!
I spent another week camping "up north" with my dog, Sonny, in August. That helped me to recharge my batteries.
The lease on my Volvo S60 ended in December. I picked up a new Lincoln MKZ. I had three S60s and an S40, but, as Ford no longer owns Volvo, I decided to change. I also considered changing to a color other than black, but ended up with another black car.
I continue to play hockey. This time of year, I am playing three and sometimes four nights a week.
I was too busy to play much music while I was working on the Masters degree. Now that that is complete, I have been able to play my Chapman Stick more.
The holidays were nice. I had family over for both Thanksgiving and Christmas this year.
It was a pretty good year.
I started a new job in January. I'm building interfaces for the Wayne State University Physician Group in Detroit, MI. They have existing interfaces that were built by a person that is no longer there, so my first task was to redirect those interfaces to "pass through" the Rhapsody interface engine so that I could actually see the messages. I started planning for redirecting those interfaces when we replace our practice management system. The PM migration has taken longer than any of us expected.
I finished my Masters Degree in Medical Informatics in June. I went to Evanston for the graduation ceremony with my parents. I had family and friends over to my house to celebrate!
I spent another week camping "up north" with my dog, Sonny, in August. That helped me to recharge my batteries.
The lease on my Volvo S60 ended in December. I picked up a new Lincoln MKZ. I had three S60s and an S40, but, as Ford no longer owns Volvo, I decided to change. I also considered changing to a color other than black, but ended up with another black car.
I continue to play hockey. This time of year, I am playing three and sometimes four nights a week.
I was too busy to play much music while I was working on the Masters degree. Now that that is complete, I have been able to play my Chapman Stick more.
The holidays were nice. I had family over for both Thanksgiving and Christmas this year.
It was a pretty good year.
Subscribe to:
Posts (Atom)