Opinions on Public Health

Keith discusses his views on Public Health in his (somewhat long) blog post. First things first - what is the role of public health (also referred to as population health)?

My thoughts - to analyze, record and improve the health of the population as a whole by collecting data about individuals, researching trends across populations and appropriating and distributing best practices and care for individuals.

A few observations:
I didn't use the word patient, but instead "individuals". This is because the population consists of both patients as well as non-patients.
Data is collected per individual but the analysis and research should be across a defined population.
Finally, to complete the circle to improve the health of the population, feeding best practices back into individual cases (patients and non-patients). Care can be delivered and best practices adopted only if this happens at the level of the individual.

So, in some sense, I see public health starting off by dealing with the patient level, moving to the population level and then coming back down to the patient level. Here is a little illustration to help:

 

 

I've already discussed some of the challenges of the political and jurisdictional nature here.

There are some technical challenges that we need to overcome in order to architect a sensible solution for automating data collection in public health. Some of these have to do with standards that are currently being worked on in HL7 as well as profiles being written in IHE. Are we there yet from a technical perspective? Absolutely not. However, we are a LOT further along compared to the challenges faced operationally and politically. Power and Money drive too much in this country. Right now, nobody wants to cooperate unless there is some form of profit associated - or at the minimum, no loss of one's powers and jurisdiction.

I was fortunate to have an interesting discussion with a couple of other people at IHE - MW, LF and NK at lunch today about the challenges in applying automating solutions to the public health areas.

This, like a lot of things, is a situation of "Catch 22" or a cycle where it is difficult to get the first step going. Since the states own public health data, and the center needs to purchase it from them, the states want incentives to conform to any standards developed by the center. Vendors obviously want one set of standards across the country while the different states have no incentives to agree upon one standard set of data or workflows. In fact, I will go on to say that I don't think that in public health, there is even an agreed upon workflow to collect the necessary individual data and what to do with it.

So, there are several challenges, and how do we move forward? First, we need to establish common workflows and data requirements. Next, we need to create standards while engaging both vendors and experts from areas of patient care, non-patient information collection as well as public health. Then, maybe create a new standard? Okay, let's rephrase that to agree upon a single standard for each of the different domains withing public health. It is important to try to standardize the workflow too. Finally, getting the buy-in from the states to require the use of these standards.

At the lunch table, we discussed how it would help to have a pilot first. The pilot should be one or two states with a handful of hospitals / provider organizations. It is important to restrict the participation to a handful of hospitals and provider organizations to allow for standards and profiles to mature before expanding the pilot for general consumption. This would also give the opportunity to demonstrate the possible savings from the pilot sites.

RPE and XDW

IHE's ITI and QRPH committees today met again to discuss the similarities and differences between RPE and XDW. I'll start first by giving a quick overview of what each profile is and then discuss my viewpoints on the comparison.

RPE - Retrieve Process for Execution
RPE was a profile that was written a few years ago and at the time was called Retrieve Protocol for Execution where protocol referred to research protocols. The purpose originally was for a protocol executor to retrieve a protocol from the protocol definition manager and execute it while providing updates to a state manager. RPE has evolved since then. Now, The process executor and the process state manager both retrieve the process from the process definition manager and the executor then retrieves executable steps from the process state manager and executes them, finally providing updates to the state manager.

XDW - Cross-enterprise Document Workflow
XDW is a profile where the the XDW content updater consumes a workflow document, performs some workflow steps and replaces the document with an updated workflow document.

When comparing these two profiles, it is very easy to make arguments for both the similarities as well as the differences between them. Some are highlighted below:
Similarities:
Both profiles deal with some type of process or workflow.
Both profiles allow for shared execution of a process or workflow.
Differences:
RPE has more of a central execution architecture while XDW has more of a distributed execution architecture.
RPE attempts to automate the execution steps with executable tasks while XDW does not.
XDW documents the workflow steps that were completed in a document architecture while RPE does not.

Once again, I will argue that several other similarities and differences can easily be documented. So, what is the purpose of having these two separate profiles.

When posed with a problem that could be potentially solved by either of these profiles (or a combination of both), how does one figure out what the best solution is. This is somewhat of an architectural question and some level or art comes into play. However, both ITI and QRPH have agreed to create a decision tree that will help answer this question based on collecting more information about the problem. I will refrain from posting further thoughts till we have some semblance of a finished product from the two committees.

Proliferation of Standards

For those who have worked with standards enough, this one might hit home a little bit. It is from xkcd.com

Nails it...

CDC PHIN Syndromic Surveillance Message Guide

Most of you have probably read the notice on the Messaging Guide for Syndromic Surveillance published by PHIN (CDC). The CDC is requesting feedback on this implementation guide by June 20, 2011. If you missed the notice, here is the summary:

The Centers for Disease
Control and Prevention (CDC), located
within the Department of Health and
Human Services (HHS) is requesting
public comment on the draft PHIN
Messaging Guide for Syndromic
Surveillance. The document translates
the business requirement
recommendations from the International
Society for Disease Surveillance to
technical specifications to support
meaningful use of electronic health
records for syndromic surveillance.
Comments will be used to inform and
finalize the Messaging Guide.

You can find all the relevant information at Regulations.gov. Several people and organizations will probably provide feedback. I know that HL7 will be doing so through the PHER working group. Below are some of my thoughts.

Jurisdictional Challenges in Healthcare Standards

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.

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.

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.

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...

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.

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.