In the US, healthcare and public health are both in the jurisdiction of the individual states, or so I'm told. When I think about this a little more, it is very interesting to observe that the central government is NOT a committee or conglomerate of state governments. So, technically, the center is supposed to create rules in the appropriate jurisdiction. Wait, it becomes a little more complicated - the center controls a lot of money that is for healthcare purposes (think Medicare), and... money is power.
What does this lead to?
Rules being created by the central government that individual states will extend and change as per their likes, leading to possibly 50 different ways to do the same thing. While I believe in allowing the states to do what it best for them, I think that it would make a lot of sense for the center to invite state representatives to get input as well as buy-in.
A leading example of this is the group of public health menu options for meaningful use. It seems like immunization experts and owners from different states have already solved this in some way by getting together. I welcome comment from all on how we can take the immunization folks' success model and apply it to electronic lab reporting and syndromic surveillance.
Thursday, May 19, 2011
Tuesday, May 17, 2011
Electronic Lab Reporting "Task Force" workgroup
The CDC and CSTE (Council of State and Territorial Epidemiologists) has come together to create a "task force" that will work on kicking off the first necessary step to start defining a standardized set of reportable lab results. The official name is the CDC CSTE ELR Task Force Standards workgroup.
As the first step, the plan is to create a mapping between reportable conditions and its associated LOINC lab tests and SNOMED lab results. This product is to be called the RCMT (Reportable Condition Mapping Table). Several conditions are on the list to be discussed and mapped.
I'm really glad that CDC and CSTE has taken this first bold move in the right direction. I was reminded by someone today that Epidemiologists aren't all necessarily LOINC experts, and therefore, LIS vendors, EHR vendors, Hospital representatives (clinicians and infection control experts) and public health departments are encouraged to participate in this endeavor.
Now, if we could take this to the next level by using a standards process for this, and involving the right people as well as then formalizing how this information would be represented, I would be very happy.
Please note that from the RCMT website, anyone is able to join into these calls and participate. Please do so, especially if you fall in one of the categories mentioned above.
As the first step, the plan is to create a mapping between reportable conditions and its associated LOINC lab tests and SNOMED lab results. This product is to be called the RCMT (Reportable Condition Mapping Table). Several conditions are on the list to be discussed and mapped.
I'm really glad that CDC and CSTE has taken this first bold move in the right direction. I was reminded by someone today that Epidemiologists aren't all necessarily LOINC experts, and therefore, LIS vendors, EHR vendors, Hospital representatives (clinicians and infection control experts) and public health departments are encouraged to participate in this endeavor.
Now, if we could take this to the next level by using a standards process for this, and involving the right people as well as then formalizing how this information would be represented, I would be very happy.
Please note that from the RCMT website, anyone is able to join into these calls and participate. Please do so, especially if you fall in one of the categories mentioned above.
The ONC asks Canada for advice
I'm at HL7 this week, and it has been a great day already. In Q3 today, I was privy to a wonderful conversation about a set of questions that the ONC has actually sent to the Canadian Health Infoway about registries, an in particular provider registries.
This is really good news - the US government is actually looking at successful models for guidance. What I hope is that we learn from not just Canada, but take into account other countries like New Zealand and the Netherlands and pick what would be the best model for the US.
Along with the registry model, in my opinion, the powerful thing is that we understand the business drivers to sustain the model.
More to come from HL7 and the days progress.
This is really good news - the US government is actually looking at successful models for guidance. What I hope is that we learn from not just Canada, but take into account other countries like New Zealand and the Netherlands and pick what would be the best model for the US.
Along with the registry model, in my opinion, the powerful thing is that we understand the business drivers to sustain the model.
More to come from HL7 and the days progress.
Tuesday, May 10, 2011
Immunization Information Systems (IIS) and data tracking during Pandemics
A small group of people are currently working in HL7 (particularly in Public Health and Emergency Response - PHER) to try to create a standardized way to track certain characteristics of patients that may be in a higher risk and may be a priority for certain types of immunizations. Once example of this would be during the last Pandemic response for H1N1.
The problem is actually quite a bit more challenging because in order for the IIS to track this information, it needs to receive it from the EHR system (EHRS), and more importantly, the EHRS should capture this information. However, it is difficult to collect and transmit all data that might ever be important for classifying patients into these priority categories, mainly because it is impossible to predict all the data we will need for emergencies scenarios we've yet to uncover.
The approach that HL7 and PHER are taking seems like a good balance - collect the information that has been useful in the past, and then allow for addition of more information later. The proposal is to use OBX segments (OBX-3 and OBX-5) where OBX-3 would always be the LOINC code 59785-6 - Immunization Indication and the OBX-5 value would be the appropriate Snomed code for clinical data elements such as pregnancy, immune compromised, abnormal liver function, abnormal renal function, etc. This seems like an approach that would work with the caveat that the EHRS would have to map the particular Snomed codes that the CDC categorizes with what the providers enter into the system.
The approach for this problem seems to be the most elegant I've seen so far. The challenge is that of activating this during a pandemic response, and making sure that the providers are entering the appropriate information all through, so that during the response, we have the correctly identifiable data to put patients into the correct priority lists for particular immunizations.
One could also argue that a mapping or crosswalk of the Snomed codes might be a possibility, and it is - as long as we are willing to do one of two things:
1. Place the burden on the EHRS to execute this mapping
2. Send large amounts of data from the EHRS to the IIS and have the IIS execute the mapping
Food for thought...
The problem is actually quite a bit more challenging because in order for the IIS to track this information, it needs to receive it from the EHR system (EHRS), and more importantly, the EHRS should capture this information. However, it is difficult to collect and transmit all data that might ever be important for classifying patients into these priority categories, mainly because it is impossible to predict all the data we will need for emergencies scenarios we've yet to uncover.
The approach that HL7 and PHER are taking seems like a good balance - collect the information that has been useful in the past, and then allow for addition of more information later. The proposal is to use OBX segments (OBX-3 and OBX-5) where OBX-3 would always be the LOINC code 59785-6 - Immunization Indication and the OBX-5 value would be the appropriate Snomed code for clinical data elements such as pregnancy, immune compromised, abnormal liver function, abnormal renal function, etc. This seems like an approach that would work with the caveat that the EHRS would have to map the particular Snomed codes that the CDC categorizes with what the providers enter into the system.
The approach for this problem seems to be the most elegant I've seen so far. The challenge is that of activating this during a pandemic response, and making sure that the providers are entering the appropriate information all through, so that during the response, we have the correctly identifiable data to put patients into the correct priority lists for particular immunizations.
One could also argue that a mapping or crosswalk of the Snomed codes might be a possibility, and it is - as long as we are willing to do one of two things:
1. Place the burden on the EHRS to execute this mapping
2. Send large amounts of data from the EHRS to the IIS and have the IIS execute the mapping
Food for thought...
Friday, May 6, 2011
New type of profile at IHE - "Workflow Profile" and the QRPH TF
Over the past few months, the QRPH domain in IHE has been toying with the idea that we need a profile that represents more of a workflow for a particular real life use case. This has been a topic of energetic discussion for multiple face-to-face meetings.
There are possible options or profiles out there that may come to mind to help solve this idea.
Cross Enterprise Document Workflow - The description of XDW is from Keith's blog.
{The purpose of XDW is not to "automate" workflows within or even across enterprises. Instead, it's about tracking what happens, or should happen in the next few well-defined steps, and being able to look inside any "sub-workflows" initiated.}
I don't think that this is really our end goal. XDW will be great for tracking workflow, and I may actually ask ITI to rename XDW to XDWT or XDT (to have the word tracking in there) in order to avoid confusion.
Retrieve Process for Execution - RPE is a profile that uses a process definition written in BPMN and orchestrates machine execution of the process across different actors with BPEL being the underlying mechanism.
While RPE could be used to help achieve the goal of this new type of profile, it definitely feels like using a bazooka to kill a rat.
So, with some rethinking, QRPH is getting more comfortable with the idea that this new type of profile is going to be similar to the existing profile or technical framework (note that as of this blog writing, QRPH doesn't have a final text technical framework). The key here would be that the workflow profile would not create any new transactions or define any new content and instead be a Volume I definition for the workflow with potentially new actors that are grouped with existing actors in QRPH or another domain.
It is exciting to see the ideas for the QRPH technical framework coming together, and the domain starting to show signs of sprouting.
There are possible options or profiles out there that may come to mind to help solve this idea.
Cross Enterprise Document Workflow - The description of XDW is from Keith's blog.
{The purpose of XDW is not to "automate" workflows within or even across enterprises. Instead, it's about tracking what happens, or should happen in the next few well-defined steps, and being able to look inside any "sub-workflows" initiated.}
I don't think that this is really our end goal. XDW will be great for tracking workflow, and I may actually ask ITI to rename XDW to XDWT or XDT (to have the word tracking in there) in order to avoid confusion.
Retrieve Process for Execution - RPE is a profile that uses a process definition written in BPMN and orchestrates machine execution of the process across different actors with BPEL being the underlying mechanism.
While RPE could be used to help achieve the goal of this new type of profile, it definitely feels like using a bazooka to kill a rat.
So, with some rethinking, QRPH is getting more comfortable with the idea that this new type of profile is going to be similar to the existing profile or technical framework (note that as of this blog writing, QRPH doesn't have a final text technical framework). The key here would be that the workflow profile would not create any new transactions or define any new content and instead be a Volume I definition for the workflow with potentially new actors that are grouped with existing actors in QRPH or another domain.
It is exciting to see the ideas for the QRPH technical framework coming together, and the domain starting to show signs of sprouting.
Thursday, May 5, 2011
Using RFD for Public Health Reporting
Today, at the IHE face-to-face meeting, QRPH worked on putting together a concrete model of how public health workflows could use the QRPH public health content profiles with RFD. This was a great discussion that clarified this workflow for a lot of people. For this reason, I thought it would be great to share this with everyone. Let's get the goal defined first - public health organizations would like to receive a standard document with the right and complete data as per the profile specification.
The basic point is that the public health workflow could do this is one of two ways when using RFD:
1. Define the pre-pop data in the RFD Retrieve Form transaction, and require that the Form Filler be able to conform to the pre-pop requirements laid out by the specific public health profile. There are obvious disadvantages to this, and doesn't necessarily even accomplish the public health goal of receiving a standard document that they profiled.
2. Group the Form Receiver with the content creator for the particular public health content profile, and the public health system be the content consumer. This will allow the goal to actually be met. Note that in order to stick with the RFD rules, the actual rules to create the document as per the profile would have to be written into the actual form's "submit" function by the Form Manager OR the Form Manager and Form Receiver would have to be able to collaborate such that the Form Receiver can actually understand the submitted form and create the document as per the profile specification.
The basic point is that the public health workflow could do this is one of two ways when using RFD:
1. Define the pre-pop data in the RFD Retrieve Form transaction, and require that the Form Filler be able to conform to the pre-pop requirements laid out by the specific public health profile. There are obvious disadvantages to this, and doesn't necessarily even accomplish the public health goal of receiving a standard document that they profiled.
2. Group the Form Receiver with the content creator for the particular public health content profile, and the public health system be the content consumer. This will allow the goal to actually be met. Note that in order to stick with the RFD rules, the actual rules to create the document as per the profile would have to be written into the actual form's "submit" function by the Form Manager OR the Form Manager and Form Receiver would have to be able to collaborate such that the Form Receiver can actually understand the submitted form and create the document as per the profile specification.
Tuesday, May 3, 2011
Mandatory and Required and R2 and Optional and what?
Both Standards (in HL7) or Profiles (in IHE) refer to the optionality of different items (documents, sections, message elements etc.). However, there is a subtle difference in the way the two organizations refer to the list of options. At the IHE face-to-face meeting today, the PCC and QRPH committees came together and set forth a plan to try to possibly get IHE more lined up with HL7, especially when it comes to Profiles using CDA. This is today's update from the sidecarguy.
Why Sidecarguy?
Most of you are already aware of Keith Boone's blog on Healthcare - motorcycleguy.blogspot.com. While discussing this with a colleague of mine, Tim P., I commented that I should start a blog that was a commentary too, and comment on Keith's blog as well. It was actually Tim's idea to say that I should call it the sidecarguy. So, due props to Tim.
Subscribe to:
Posts (Atom)