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.
Thursday, December 23, 2010
HL7/IHE Health Story Implementation Guide Consolidation Project
This crossed my emailbox yesterday. I will be participating in my role as Publishing Facilitator for the HL7 Structured Documents Work Group.
-----
On behalf of the Health Story Project and HL7 Structured Documents Work Group I am pleased to announce and invite your participation in the launch of the HL7/IHE Health Story Implementation Guide Consolidation Project.
The Project will take place under the auspices of the Office of the National Coordinator (ONC) Standards & Interoperability Framework and is a collaborative effort among the Health Story Project, Health Level Seven (HL7), Integrating the Healthcare Enterprise (IHE) and interested Healthcare industry stakeholders - collectively, the Consolidation Project Community.
ONC has launched a wiki page to support the project community which you can access here:
http://jira.niemhealth.org/wiki/display/SIF/CDA+Template+Consolidation+Project
NOTE: When you first click the link, you will need to Register for a JIRA wiki account and request a login before you can access the page.
FIRST MEETING: January 4, 2011
# Recurring meeting: Tuesday @ 11:00 AM EST - 12:30 PM EST
# Conference line: 1-770-657-9270, Participant Passcode: 310940
# Webmeeting: tbs
In short, the Project will:
1. Republish all eight HL7/Health Story Implementation Guides plus the related/referenced templates from CCD in a single source.
2. Update the templates to meet the requirements of Meaningful Use, in other words, augment the base CCD requirements to meet the requirements of HITSP C32/C83.
3. Reconcile discrepancies between overlapping templates published by HL7, IHE and HITSP.
The Project will not develop new content. (There is a parallel project starting up under ONC to address new content requirements – this is not that project.)
The Project wiki includes links to source material including the HL7 Project Scope Statement.
Please let me know if you have any questions. I look forward to a successful collaboration.
-----
On behalf of the Health Story Project and HL7 Structured Documents Work Group I am pleased to announce and invite your participation in the launch of the HL7/IHE Health Story Implementation Guide Consolidation Project.
The Project will take place under the auspices of the Office of the National Coordinator (ONC) Standards & Interoperability Framework and is a collaborative effort among the Health Story Project, Health Level Seven (HL7), Integrating the Healthcare Enterprise (IHE) and interested Healthcare industry stakeholders - collectively, the Consolidation Project Community.
ONC has launched a wiki page to support the project community which you can access here:
http://jira.niemhealth.org/wiki/display/SIF/CDA+Template+Consolidation+Project
NOTE: When you first click the link, you will need to Register for a JIRA wiki account and request a login before you can access the page.
FIRST MEETING: January 4, 2011
# Recurring meeting: Tuesday @ 11:00 AM EST - 12:30 PM EST
# Conference line: 1-770-657-9270, Participant Passcode: 310940
# Webmeeting: tbs
In short, the Project will:
1. Republish all eight HL7/Health Story Implementation Guides plus the related/referenced templates from CCD in a single source.
2. Update the templates to meet the requirements of Meaningful Use, in other words, augment the base CCD requirements to meet the requirements of HITSP C32/C83.
3. Reconcile discrepancies between overlapping templates published by HL7, IHE and HITSP.
The Project will not develop new content. (There is a parallel project starting up under ONC to address new content requirements – this is not that project.)
The Project wiki includes links to source material including the HL7 Project Scope Statement.
Please let me know if you have any questions. I look forward to a successful collaboration.
Friday, December 17, 2010
Radiology Orders and Results Interface
Here is another interesting interface project.
We want to send Radiology Orders from our EHR system to our trading partner and want the Radiology Results document to be returned electronically and placed into the patient's chart in the EHR.
Simple. Right.
Except, the scheduling system at our trading partner will not receive the order. I suggested that we send them an order message (ORM), a scheduled appointment (SIU), and a registration message for a future encounter (ADT). They told us that they could not process any of those HL7 messages into their scheduling system. So, we settled on this kluge. I will convert the order message into an email that I will send securely to the scheduling department. They will then manually key the appointment into their system. Hopefully, they will remember to key our Order Number so that I can match the result to a patient. Securely? Well, yes. The appointment will contain PHI, so I will utilize the secure email function of our email system. They wanted some data that the EHR could not place into the order, so I had to look that data up from the database and place it into the email.
So much for the outbound "order." Now, for the returned results.
A Radiology Result is just a special type of Clinical Document.
We have an existing document interface which we use to receive clinical documents from this trading partner as ORU^R01 messages. They will place these radiology documents into that stream and I will have to select those messages, process them a little bit differently and send them to the EHR. I will need to look up our patient identifier and put it into the message in place of their patient identifier. I will also look up the NPI for each of the incoming providers and place that into the message. The sending system gives us their internal identifier for each provider, and the EHR would like to see the NPI instead.
We are still developing this interface. The outbound orders seem to be working fine. I have built the results processing route and am waiting to get a test result to see if I have built that correctly.
We want to send Radiology Orders from our EHR system to our trading partner and want the Radiology Results document to be returned electronically and placed into the patient's chart in the EHR.
Simple. Right.
Except, the scheduling system at our trading partner will not receive the order. I suggested that we send them an order message (ORM), a scheduled appointment (SIU), and a registration message for a future encounter (ADT). They told us that they could not process any of those HL7 messages into their scheduling system. So, we settled on this kluge. I will convert the order message into an email that I will send securely to the scheduling department. They will then manually key the appointment into their system. Hopefully, they will remember to key our Order Number so that I can match the result to a patient. Securely? Well, yes. The appointment will contain PHI, so I will utilize the secure email function of our email system. They wanted some data that the EHR could not place into the order, so I had to look that data up from the database and place it into the email.
So much for the outbound "order." Now, for the returned results.
A Radiology Result is just a special type of Clinical Document.
We have an existing document interface which we use to receive clinical documents from this trading partner as ORU^R01 messages. They will place these radiology documents into that stream and I will have to select those messages, process them a little bit differently and send them to the EHR. I will need to look up our patient identifier and put it into the message in place of their patient identifier. I will also look up the NPI for each of the incoming providers and place that into the message. The sending system gives us their internal identifier for each provider, and the EHR would like to see the NPI instead.
We are still developing this interface. The outbound orders seem to be working fine. I have built the results processing route and am waiting to get a test result to see if I have built that correctly.
Saturday, November 20, 2010
Filtered ADT Feed to an Ultrasound System
Here is some more fun that an integration analyst can have.
I was asked to put together an interface to an ultrasound system that is used in two of our OBGYN clinics. They wanted patient demographics for the patients that would be arriving for an ultrasound at these clinics.
So far, so good. Typically, one would send a filtered version of the ADT stream to this system. Except that the ADT feed that comes out of our practice management system does not contain enough information for me to do so. However, the scheduling messages that come out of the PM system do. Kind of.
They send an SIU^S12 message with a patient status of "ARRIVED" when the patient arrives for their scheduled appointment. The first thing is to find the correct clinic code in the message. The message codes the location as "OBG^Oxxx" indicating that the patient belongs to the OBGYN department and is to be seen in location Oxxx. That's non-standard usage, but I was able to figure it out.
OK. So, I can pick that message out and translate it into an ADT^A04 (Register Patient) message and send that to the ancillary.
The other trick is to build a filter that will only allow the ultrasound patients to pass. Usually, there is information in the AIG segment (General Resource) that will tell you that the ultrasound machine needs to be part of the appointment. However, this PM system doesn't schedule that way. They send a bogus provider code for the ultrasound machine (actually, two of them, one for each clinic) in the SCH-12 (Placer Contact Person) field in the scheduling message. I would not have expected to find this data in this field.
Of course, none of this was documented. I needed to look at the live message stream and the values in the messages and deduce the values to filter on. I think that I got it right, but I won't know for certain until we test.
This message won't have all of the demographic information that the ancillary wants, but it will be better than nothing.
This illustrates part of the fun that interfacing can be. The business owners know what they want to do (usually), but they don't know how to do it. My job is to understand what they want to accomplish and then figure out how to construct an interface that will accomplish those objectives.
I was asked to put together an interface to an ultrasound system that is used in two of our OBGYN clinics. They wanted patient demographics for the patients that would be arriving for an ultrasound at these clinics.
So far, so good. Typically, one would send a filtered version of the ADT stream to this system. Except that the ADT feed that comes out of our practice management system does not contain enough information for me to do so. However, the scheduling messages that come out of the PM system do. Kind of.
They send an SIU^S12 message with a patient status of "ARRIVED" when the patient arrives for their scheduled appointment. The first thing is to find the correct clinic code in the message. The message codes the location as "OBG^Oxxx" indicating that the patient belongs to the OBGYN department and is to be seen in location Oxxx. That's non-standard usage, but I was able to figure it out.
OK. So, I can pick that message out and translate it into an ADT^A04 (Register Patient) message and send that to the ancillary.
The other trick is to build a filter that will only allow the ultrasound patients to pass. Usually, there is information in the AIG segment (General Resource) that will tell you that the ultrasound machine needs to be part of the appointment. However, this PM system doesn't schedule that way. They send a bogus provider code for the ultrasound machine (actually, two of them, one for each clinic) in the SCH-12 (Placer Contact Person) field in the scheduling message. I would not have expected to find this data in this field.
Of course, none of this was documented. I needed to look at the live message stream and the values in the messages and deduce the values to filter on. I think that I got it right, but I won't know for certain until we test.
This message won't have all of the demographic information that the ancillary wants, but it will be better than nothing.
This illustrates part of the fun that interfacing can be. The business owners know what they want to do (usually), but they don't know how to do it. My job is to understand what they want to accomplish and then figure out how to construct an interface that will accomplish those objectives.
Subscribe to:
Posts (Atom)