Can we get a little bit more coordination please?

There is both too much and too little going with the SI Framework Query Health that I'm tempted to submit an IHE Profile proposal that overlaps with the use case and an HL7 Project Scope Statement on the same topic just to ensure that some coordination happens. It would be so simple for ONC to use these mechanisms to encourage engagement, but I don't think that would ever occur to them.
I will probably bring the topic up for the HL7 Coordination with Other SDO's panel session in September to see if there is something that could be done to improve the situation.

Several people this week were frustrated over ONC's scheduling of the Summer Concert Series, especially as it overlaps with the Public Health Informatics Conference in Atlanta, where most of the people that Query Health is supposed to serve are. There are no sessions here on what Query Health is. And the Finale of the Query Health summer concert series is being held when an important member of the desired audience is out of town for most of the week.

---

OK, now that I have that off my chest, I did have an interesting discussion about Query Health over a fantastic Omikase style dinner at MF Sushibar.

There are a couple of challenges with "sending the query to the data" which Query Health will need to address. The first challenge is scalability. The second is coordination. The third is overlap with reporting.

With regard to scalability, I can imagine the number of queries getting quite large. I don't think that it will be feasible to process a large number of queries if they aren't designed to be very efficient. There are some techniques that can be used to enable the system to operate linearly in the size of the records being queried, rather than on the number of queries being performed. But that means that the queries need to be aggregable, so that multiple queries can be run at the same time, sort of the way that the Unix egrep tool can very efficiently search for a number of strings. But that does mean that the queries need to be pretty simple to support the aggregation of them.

The second piece that needs to be addressed is coordinating results in a timely way. I don't see query health being used effectively for a national outbreak of H1N1. But I do see it being used in other ways. Even so, unless the query is truly computed the same way, there could be some challenges in interpreting the results. I'll give an example. In one case, HEDIS measures for one region in a state were way off. It appeared that Women weren't getting routine laboratory tests done that should have been. The problem was traced back to the fact that when test A was ordered, test B and C were done reflexively (automatically). But the measures were computed based on what was ordered, not on what was reported on. That variance in interpretation caused the results for one region to be so badly off that it was readily identified. But I suspect more subtle implementation decisions could wind up introducing other variances that are not so easily detectable. It needs to be looked out for. The key here is to ensure that the queries are simple enough that there can be no real differences in the results introduced by differences in implementation. Aggregation is one of those spaces where it could be challenging to produce results that don't exhibit that problem.

Finally, there is the overlap with Public Health Reporting. Ideally, I'd like to the same specification used to describe computable representation of the data needed for a report as for a query. In the first case, that representation describes the data outputs of a system. In the second case, it describes the inputs to a computation. I can use the gozouta of one as the gozinta to the other. That will be extremely powerful for not just "public health query", but as a way to define interfaces in general.

That would enable interfaces for all kinds of <a href='http://wiki.siframework.org/Public+Health+Reporting+Initiative'>public health reports</a> to be generated automatically in software. That might put a lot of interface engineers out of a job, but I'm certain that in the current environment, there will still be plenty of call on their skills for other projects.  Because as soon as you turn around, there'll be another initiative.  I'm having trouble keeping up, and unlike many other standards geeks, that IS my day job.

IHE Profile Proposal for expanding upon the Retrieval of Clinical Knowledge

HITSP started it with T81 Retrieval of Medical Knowledge. IHE continued it in QRPH TF-2 (see page 99) with QRPH-29 Retrieval of Medical Knowledge. I'm demonstrating its use for Public Health Alerting this week, but there is so much more that could be done.

The specification is very simple. You request a resource using a URL. The query parameters to use are specified in the HL7 Infobutton specification.

But the specifications as they stand in either IHE or HITSP are incomplete.

• How do you retrieve medical knowledge on a specific disease? A medication? What are the query parameters to set? What if you want a response suitable for a healthcare provider? A patient?
• What happens when there is nothing to show?
• How do you authenticate the provider using the request?
• What are the error cases?
• What is the format of the response?
• What additional metadata should be returned in the response?
• How can we make responses cachable? Should they be?
• How do we retrieve multiple results?
• Should the request be made using GET or POST?

These are all questions I had to address in the implementation I'm demonstrating at the Public Health Informatics conference this week in Atlanta. Some of the answers can be generalized to any use of InfoButton. Others are more specific to the kind of request being made.

There needs to be a general specification that addresses the common issues. These should be written as Change proposals to QRPH-29.

I have three or four other use cases for which I'd like to see a more detailed specification put together.

1. Accessing Patient oriented education information on a laboratory result, condition or diagnosis, or medication. This is a capability already supported in MedLine Plus as I understand it. I'll be following up with a few people from NLM for more details on that. Note: Access to Patient-specific education information is one of the menu-set objectives in Meaningful Use.
   
2. Accessing information about clinical trials relevant to a particular disease. Many patients with serious life-threatening or chronic illness would love to find out about clinical trials they might fit into. A suitable InfoButton query could be crafted to support access to an Atom or RSS Feed of clinical trials. That could go a long way towards encouraging enrollment in clinical trials.
3. Taking the next step in creating actionable public health alerts. In my current implementation we are getting a HTML page back. But, the content would be easier to handle if it were actually an Atom or RSS Feed in response to the query. This addresses multiple issues:
   
   1. It supports multiple responses to the query.
   2. It allows just the key metadata to be returned as a response, with subsequent retrieval of the detailed data when needed.
   3. It allows each alert seen to be given a unique resource ID that DOESN'T change even when the alert changes. This is critical, as it allows providers to keep track of what they saw, when they saw it, without having to keep a separate copy. When the alert changes, the link in the feed changes, rather than the content of the page. This is an important issue for medical records professionals.
   4. When a feed is used, the URL found is to the appropriate alert. That makes the detailed alert result cache-able. This is another important issue that can help address network latency issues. A simpler response can be returned that points to the potentially cached resource.
      

The Problem

Providers and patients need a simple way to search for web resources that can answer specific questions. The HL7 InfoButton standard provides one such mechanism by which this can be done. However, there are a number of different ways that InfoButton can be used, and there are a number of options in how a system can respond. We need a consistent set of rules for using InfoButton to query for information that is either patient or provider-oriented. We need a consistent way to address and report on errors in the responses. We need a consistent way to return results so that EHRs and PHRs can make these queries, process the results, and display them in a normalized form.

Key Use Cases

A provider using an EHR wants to locate patient oriented education materials on a given condition. How should the query be structured to obtain a selection of available materials? A patient wants to keep track of clinical trials for a specific condition. How should the query be structured to obtain a selection of appropriate clinical trials?

Standards and Systems

InfoButton, HTTP, XHTML, HTML, HTML 5, Atom, RSS EHR, PHR, HIE

Discussion

This should be a joint work item between Patient Care Coordination, and Quality Research and Public Health. IHE would be a good venue to solve this problem because it involves developing a profile across several existing standards. It has the necessary expertise in PCC and QRPH to address content issues, and in IT Infrastrucure to address common infrastructure questions. There may also be cases where a query could actually return a URL to a form that could be used with the IHE Request Form for Data Capture profile. We should examine what the glide path is from QRPH-29 to ITI-34.

Open for Public Comments: Proposal to ONC on S&I PH Reporting Initiative

PARTICIPATE IN THE PUBLIC REVIEW

Proposal for the

ONC S&I Framework

Public Health Reporting Initiative

        Comment Period: August 19, 2011 - September 6, 2011

Dear Members of Public Health, Clinical and Health IT Vendor Communities!

We are requesting your participation in the Public Review of the Proposal to the Office of National Coordinator for Health IT (ONC) to establish the Public Health Reporting Initiative under the ONC Standards & Interoperability (S&I) Framework.

The goal of the proposed S&I Public Health Reporting Initiative is to harmonize the use of HIT standards and create reference implementation guides to support interoperable bi-directional communication between clinical care and public health agencies for selected information exchanges (use cases).  

The proposed timeline for this Initiative is October 2011 through December 2013, and will strive to produce deliverables for timely consideration of the HIT standards Committee during FY 2013.

The S&I Public Health Reporting Initiative will:

v  focus on individual-patient reporting from EHR systems and patients/consumers to public health agencies (local, state and federal)

v  examine several reporting use cases that share similar business processes, data and information exchange requirements.  The Initiative will then select candidate use cases that can benefit from the harmonization of HIT standards and implementation guide(s).  The harmonized use cases will be forwarded as reference implementations (testing methods, tools, certification criteria and processes) for consideration for Stage 3 of Meaningful Use adoption

v  identify demonstration pilot partners to help test artifacts from this Initiative, including the deployment of certified HIT products to enable information exchange and interoperability between EHRs and public health information systems

v  develop a Roadmap for Public Health Reporting HIT Standardization  that  extends and supports the long term harmonization and alignment of public health information exchanges and systems  with the recommendations and deliverables produced under this Initiative

We are also soliciting your feedback and suggestions for possible USE CASES that can be harmonized and delivered as candidate reference implementations under this Initiative.

Please provide your comments on the Initiativs Charter (attached),

and USE CASES by September 6, 2011 at: http://wiki.siframework.org/Comment+on+the+Proposal+for+the+ONC+SI+Framework++Public+Health+Reporting+Initiative

Please also join the Initiatis Sprint Team to finalize the Proposal in September 2011 by attending conference calls on September 7 and 14 from 4-5pm ET.

Please contact Wendy Scharber at wendy@phdsc.org to join the Initiatives Sprint Team.

Participate in Building HIT Interoperability for Public Health!

PublicHealth Informatics Conference

This weekend, I'll be headed off to the Public Health Informatics Conference, affectionately known in some circles as the Conference formally known as PHIN.

It will be the first Healthcare Conference that I wear my jacket too. It's been to other events, but this will be its first conference.

If you are looking for me, you can find me in my usual place: The Interoperability Showcase where I and many other IHE supporters will be demonstrating use of Healthcare standards for interoperability.

I'll be participating in the Public Health Alerting demonstration, just like I have in prior years. To learn more about what is happening there, you can also check out this session and this one.

I'm looking forward to it.

What we will be demonstrating is actually a very powerful mechanism to deliver public health clinical decision support as a service that can be used by any electronic health record system, health information exchange, or even a personal health record. The work is based on the HITSP T81 specification.

If this seems like old news, it's probably because you've read some of the press I talked about here. We are taking it to the next step. It may have taken time, but I'm hoping it will have been worth the wait.

There will be plenty of other things going on, including use of HL7 CDA to support disease monitoring and surveillance, electronic laboratory reporting, and implementation of several IHE profiles developed by the Quality, Research and Public Health domains. If you are going to the conference, stop by the showcase and say hi. I'll be pretty easy to spot.

PublicHealth should be Patient Centered Too

Some recent discussions got me to thinking about Public Health again, possibly because I've been spending a significant amount time with the IHE Quality, Research and Public Health technical committee and individual members this week.  Some time ago I wrote about "Taking Cost out of the System".  Let's list some of the activities that individual providers and organizations need to engage in with public health:

• Reporting Immunizations
• Getting Immunization Data (if you are lucky)
• Reporting information to disease specific registries (e.g., Cancer)
• Reporting Syndromic Surveillance Data
• Reporting Notifiable and Reportable Laboratory Reports (and Orders)
• Pediatric Lead Testing 
• Early Hearing Screening
• Reporting Birth information

Three of these are already part of Meaningful Use Stage 1 here in the US, and others are expected to become part of Stage 2.   With few exceptions, all of these different reports go to different silos, using different messages.

When we look at Federal law covering exchanges with public health, it is noted as an exception to the usual rule of "No PHI", although many public health agencies choose to limit the amount of PHI they receive to make their systems less costly and easier to work with.

I'd like us to think about a different model for dealing with public health.  It's not the "Send the question to the data" that Wes Rishel or I talked about in recent postings, either.  Who bears the burden of performing the query?  It's not public health, its the individual providers and organizations who would have to receive and process it.  That really doesn't make public health's life any easier.  There are just as many systems to send the queries to, the data is not "normalized" as it is when public health silos up, and the queries aren't quickly done for ad hoc purposes.

When a doctor treats a patient, the ideal today, is that he treats the whole patient.  The system may fall short of that, but it has certainly been expressed in the "patient-centric" focus.  Why should public health be any different. After all, public health is really dealing with an aggregate of patients (in the usual sense of the phrase, I realize public health also provides individual patient care, but that is a different sense of the commonly understood meaning).

What would happen if instead of every single provider having to figure out how to extract data from patient records they have on the patient, they were instead required to provide public health with a copy of this information (with a few notable exceptions).  It could be through an HIE, through Direct, or through some other transport mechanism.  Public health could then take those records, abstract from them what is needed to deal with:

• Immunizations
• Syndromic Surveillance
• Disease Registries
• Birth Records
• Pediatric Lead Testing
• Early Hearing Screening
• Reportable and Notifiable Conditions

What happens to the way that public health is organized?  Well, for one, they'd have to pool their IT resources and eliminate redundancies.  Two, they'd be responsible for analyzing and routing the data that they need for public health functions to their internal functions, rather than making providers do that for each separate function.  Third, they'd have to get a lot better about security of the data that they centrally manage.

What would happen at the provider end?  Instead of having one or two interfaces that need to be managed for each public health function that would need to be supported by each provider organization, there would be only two (the outbound push to public health, and a way to query public health where necessary).  You could use the same standards being selected for clinical documentation being exchanged between healthcare providers, so that would eliminate another source of variation in the data.  Public health can then take the clinical data they need and distribute them where they need to go, with appropriate pseudonomization, abstraction, extraction and roll-up, et cetera.  If this were done at the state level, with local access, this could have an even greater impact.  Many organizations have to deal with multiple municipalities when communicating to public health.  Imagine the cost savings to providers that could occur by ripping out and throwing away dozens of unnecessary interfaces.  I've seen estimates of anywhere from $5K to $20K per interface (depending upon who makes the estimates and the complexity of the interfaces being discussed).  Even using a lowball figure, that savings could be significant to many provider organizations.

This is a pipe dream.  I don't see it happening, but not because it's technically unfeasible.  Politically and organizationally it isn't feasible.  You'd have to get multiple agencies to agree to share resources, and give something up (control and resources) in the process.  I heard someone report at an eHealth Connecticut conference five years ago that they figured the State could spend $5-10 million to set up a State HIE and still have twice as much savings left over if they were able to eliminate public health silos.  But could you imaging getting all of those state agencies to buy in?  What about the policy ramifications?  Actually, because public health has the HIPAA exemption that's not pre-empted by state law, they might also get around some of those. What about public response?  What, you are going to send all my medical records to the state?  The privacy barons would have a field day over that one, and certainly there are some technical barriers around what would be needed to be put into place to make them happy.  Oh, and then there's all the fine wording of all that public funding running around in public health.  That's why we had excellent surveillance mechanisms for H5N1 that completely failed us when we were hit with an H1N1 epidemic in the making.  That's not disease-centric thinking, that's even worse:  Serotypical thinking, and unfortunately, all to typical.

So of course, it's easier to create a new standard to work around all those other really complex issues.  I vacillate around the simplicity of the query model and the cost distribution that puts most of the work back on the provider.  Do I want to tackle an easy challenge and avoid the hard stuff that would provide even more savings?  I dunno.  It's 2:00 am.  Do I really need more work?

But, I cannot help thinking that one standard already supported by several hundred EHRs could replace three, four or even more standards used in public health exchanges.  All we need do is to stop public health from organizing themselves into disease-centric silos.

-- Keith

P.S.  Maybe what I should have said is that public health should be population centered.

IHE Quality, Research and Public Health supplements published for Public Comment

IHE Community,

Quality, Research and Public Health supplements published for Public Comment

The IHE Quality, Research and Public Health Technical Committee has published the following supplements to the forthcoming IHE Quality, Research and Public Health Technical Framework for public comment in the period from June 17, 2011 to July 17, 2011:

·       Early Hearing Care Plan (EHCP) 

·       Mother and Child Health (MCH) 

·       Physician Reporting to a Public Health Repository-Cancer Registry (PRPH-Ca) 

·       Public Health Reporting (PH-rpt) 

·       Quality Measure Definition - Early Hearing (QMD-EH) 

·       Quality Measure Execution - Early Hearing (QME-EH) 

·       Retrieve Process for Execution (RPE)

The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 17, 2011, will be considered by the Quality, Research and Public Health Technical Committee in developing the trial implementation version of the supplements.  Comments should be submitted at http://www.ihe.net/qrph/qrphcomments.cfm.

PublicHealth Syndromic Surveillance Guide Published for Public Comment

I've spent a good bit of time talking about Syndromic Surveillance for Meaningful Use on this blog, especially given the various mistakes made in the original selection of standards and the subsequent approaches used to correct those mistakes. Now we have another minor whoops to contend with.

PHIN recently published a new implementation guide for implementing syndromic surveillance.  But this was not developed through a  consensus-based standards development process as suggested by OMB Directive A-119.  Instead it was yet another Federally sponsored project developed outside of an SDO.  I should acknowledge that they did have SDO input or I wouldn't have even known where to find this.  There is an opportunity to comment, it's just not one which people who follow and develop healthcare standards would normally be tracking.

I did a quick skim through the guide.  Once again, the work isn't bad, but I am still concerned about the lack of input from the side of producers of the messages in the guide.  There are a couple of places in the guide where the value set is marked TBD.  The most annoying one is the lack of specificity on laboratory results.  Haven't we been down this path before.  At least they could specify LOINC as the vocabulary and build from other work on reportable and notifiable conditions.

I'll do a more detailed analysis as time permits. The deadline for comments in June 20th, so there is still time.

CDC informational webinar on syndromic surveillance guidance Tues 12/14

The International Society for Disease Surveillance (ISDS), with the support of the CDC BioSense Program, is developing guidance for the Meaningful Use objective that relates to syndromic surveillance. In close collaboration with the CDC, ISDS is using a consensus-driven process and engaging key stakeholders to develop the recommendations that will serve as a resource for electronic health record technology vendors, healthcare professionals and hospitals, and public health stakeholders supporting public health syndromic surveillance practice.  The final guidelines will be provided to the Office of the National Coordinator of Health Information Technology (ONC) in January 2011. ONC has indicated that this information will be used in the rulemaking process for Meaningful Use Stages 2 and 3.

Now through 12/17/2010, the ISDS is making the interim guidance available for review and readers are welcome to comment at the following link:www.syndromic.org/projects/meaningful-use

An informational webinar will take place on 12/14/2010 from 1:30-3 PM(EST). The purpose and content of the recommendation will be discussed in detail with participants. This opportunity is intended to assist you in providing constructive comments to ISDS before the 12/17 deadline.

Please SAVE THE DATE and join the webinar here:

https://cdc-informatics.dimdim.com/communications/

Public Health Surveillance Program Office POC

Sam Groseclose 404-498-0127                      

Taha Kass-Hout  404-498-2014

Webinar POC:  Rick Jones 770-841-2890

Rick Jones
Associate Director for Communications
Centers for Disease Control and Prevention
Office of Surveillance, Epidemiology & Laboratory Services
Public Health Informatics & Technology Program Office

PublicHealth Surveilance Recommendations for MeaningfulUse Published for Comment

At the beginning of December ISDS published its recommendations for Disease Surveillance for Meaningful Use.  I've commented on this work in this blog before.  It's now out for a second round of public comment. 

ISDS, while reporting that they have convened a workgroup of Meaningful Use stakeholders, definately did not include the stakeholders who have to implement the requirements described in their deliberations on the creation of this specification. This is pretty important in standards development.  You need to have the producers as well as the consumers present in the discussion, or you wind up with an unbalanced approach.

What has changed for the better though is that they report that the implementation guide work will be done in HL7, and they've simply reported the required data elements, rather than how they are to be built into an HL7 messaqge. I'm very happy to see this change.  It means that the standards development work will be done in an experiencd SDO which has balanced participation in the the development process.


I have a couple of comments on the document that they published:

1.  On reporting, they recommend reporting from Hospitals and Urgent Care centers every 24 hours, and indicate that there is a belief that ambulatory reporting would be beneficial, but there is a lack of experience in this space.  I would have to agree on the experience space.  I have a hypothesis that ambulatory reporting would not only be beneficial, but also, significantly better than hospital and urgent care reporting based one what I've learned from others.  I suspect that disease activitity in ambulatory care settings spikes ahead of urgent care centers and hospitals, because that is where patients with health coverage will go when they first start having symptoms of disease, whereas patients without will seek urgent or emergency care only after symptoms become severe.  This could amount to a several day lead on existing surveillance efforts.
So, it might be cheap and easy to get large volumes of data from hospitals, but the signal will be smaller and more delayed.  It might be more difficult or expensive to get data from ambulatory providers, but the signal will likely be stronger and sooner (but also different due to change in symptom severity).

From a policy perspective:  I would recommend research and funding into studies on the effectiveness of disease surveillance from the ambulatory perspective.  I would NOT postpone deployment of basic surveillance into urgent and hospital care settings, but would postpone advanced deployment into those settings until it has been determined whether that setting or the ambulatory setting would be the better place to spend money.

2.  On data elements:
Facility name and address data is noted as being RE, required to be sent when known.  I cannot imagine a hospital or urgent care center that does not have that data available.  It should be required.

Unique Patient Identifier and Medical Record Number are two different kinds of patient identifier.  No need to separate these.

Age is required but Gender is RE.  I don't get it.  If you can always figure out the age, then gender should be as easy.  Many of the reasons why you wouldn't be able to ascertain age would also impact gender (patient not concious).  I would assume that these two data elements would have the same level of requirement, and that it should likely be RE (because you may not be able to determine age).

For age, units should also be allowed to be decades, because after a certain age, that's all that HIPAA allows you to indicate.

For patient class, I would limit the value set to Emergency, Outpatient or Inpatient.  Other distinctions, such as obstetric, recurring, or pre-admit are variations on Outpatient as far as I can tell, and not of great utility in surveillance.  While these are values used in the HL7 standard, they don't seem as applicable to the surveillance task.

On Chief Complaint/Reason for Visit, I understand the desire for free text content, but would separate the requirements for free text and coded data and make both RE (send if you have it).  Having both fields for surveillance may be valuable, as you can make associatations between coded values and free text content based on entered data that could be useful later.

I'm curious while tempurature and pulse oximetry are RE, but other vital signs are not included.  I'm not a public health specialist, I can imagine that blood pressure might not correspond to a public health problem, but I could imagine that pulse and respiration might.  What's the significance of the signal conveyed by these data elements, and what is the significance criteria by which a data elements are chosen to be included in this data set.  Hmm, there's some interesting math to do on this set... it strikes me that there's at least a good research paper in evaluating the predictive value of various data elements in the recommended set to public health surveillance.

PHIN VADS Webinar Series - Supporting Meaningful Use

Crossed my desk today...

---

 

 

Greetings,

 

CDC Vocabulary and Messaging team announces an upcoming, free web seminar series about CDC Vocabulary Server (PHIN VADS) that supports the distribution and implementation of vocabularies associated with public health Meaningful Use (MU) measures and the HL7 messaging implementation guides.

PHIN VADS application can be accessed at http://phinvads.cdc.gov

 

Mark the Dates:

1. November 30th, 2010 1 p.m. to 2:30 p.m. EasternVADS Content and Application Overview.Teleconference and LiveMeeting link: http://www.phconnect.org/events/phin-vads-content-application
2. December 2nd, 2010, 1 p.m. to 2:30 p.m. EasternVADS Application Integration and Web Services Overview for DevelopersTeleconference and LiveMeeting link: http://www.phconnect.org/events/phin-vads-application
3. Dec 3^rd, 2010, 1 p.m.to 2:30 p.m. EasternVADS value set authoring tool for value set creators and quality measure developers.Teleconference and LiveMeeting link: http://www.phconnect.org/events/phin-vads-value-set-authoring

To keep the seminars at a manageable size, though, we maintain a maximum number of 99 simultaneous participants logging-on during any seminar.

 

PHIN VADS collaborative workspace
CDC Vocabulary and Messaging team has launched a new collaborative workspace for PHIN VADS in Public Health Connect (phConnect).  This online forum will facilitate the adoption of vocabulary and messaging standards as well as collaboration between value set developers, quality measure developers, implementers, messaging analysts, public health departments, vendors, SDOs and CDC Vocabulary and Messaging team. PHIN VADS workgroup is one of the workgroups of public health Vocabulary and Messaging Community of Practice (VMCoP).
Please visit the PHIN VADS forum online at http://www.phconnect.org/group/phinvads to discuss any PHIN VADS value set development and implementation issues. This forum also includes all the resources related to VADS application and content.

 

ONC Federal HIT Vocabulary Task Force testimony about PHIN VADS
CDC Vocabulary and Messaging team has recently provided testimony to Office of National Coordinator (ONC) Federal Health IT standards committee vocabulary task force regarding the vocabulary development and PHIN VADS value set distribution.
CDC PHIN VADS Testimony hyperlinks to Federal Health IT website:

• One Stop Shop for Meaningful Use Vocabulary -Sept 1^st, 2010 (Written Transcript, Audio)
• Best Practices and Lessons Learned: Vocabulary Infrastructure - March 23^rd, 2010 (Written Transcript, Audio)

Point of Contact:
Please contact the CDC Vocabulary and Messaging team at PHINVS@CDC.GOV if you have any questions about PHIN VADS or the webinar series.

 

Thanks
CDC Vocabulary and Messaging Team

A schedule for Stage 2 and more on Public Health Surveillance

Rita Altamore dropped these tidbits in my inbox.  I thought I'd share them.

First, the draft timeline for MU Stage 2 is below.
MU Work Plan Timeline

• Oct 20, 2010: directional guidance from HITPC
• Dec 13, 2010: present draft MU stages 2/3 criteria
• Jan, 2011: release draft MU criteria RFC
• Feb, 2011: analyze RFC submissions and revise MU draft criteria
• Mar, 2011: present revised draft MU criteria to HITPC
• 2Q11: CMS report on initial MU submissions
• 3Q11: Final HITPC recommendations on stage 2 MU
• ~4Q11: CMS MU NPRM

Opportunity to comment on New Disease Surveillance Standard

Next, and of a bit more immediate importance.  The ISDS Recommendation has been posted on their web site.  You can see the current draft below.  If you'd like to comment on it, they have started a survey for feedback here:

http://www.surveymonkey.com/s/F9FR2CY

I appreciate that they've provided an opportunity for the public to comment, but the process is still lacking balance as I've mentioned previously.  Balance is the principal the consumers, users and producers of stuff that must meet a standard are represented in a standards making process.  At the moment, public health has undue influence in this process.  But hey, at least we get to provide comments.  Can you guess what my first one will be.
 
Here is the text to comment on.

My feedback will also include some information based on what I found out in this comparison between what they did and what HITSP did.  Analysis of Proposed ISDS Standards for Disease Surveillance

   Keith



 

Analysis of Proposed ISDS Standards for Disease Surveillance

The executive summary:  For Meaningful Use Biosurveillance requirements, you should use HITSP C39 for now, and when this work is complete, and if adopted, you will be pretty darn close.  Why we couldn't have adopted the HITSP C39 for now is quite beyond me.

Here is what I found comparing the two:

What's added to the ISDS specification:
Facility Identifier and Address -- Not specified HITSP specification, and there is a clear need for it.
Visit Identifier -- Not specified in the HITSP Specification
Patient Country -- Not specified in the HITSP Specification

Patient Class -- The ISDS specification does not constrain the vocabulary to Emergency, Inpatient and Outpatient like HITSP did.  Instead they recommend that constraint.  It's not clear why this is done, but I can imagine that it might contain useful information for public health if a larger value set was used.

Date/Time of Message -- ISDS puts this in the EVN segment (in EVN-2), but the specification also says this is the time of the message transmission which HL7 Version 2 clearly states goes into MSH-7 message creation time.  I think the concern here is that an intermediary will report a different time when it forwards a message than what the facility provides.  So, put your date time in EVN-2 and MSH-7.

What was in HITSP that isn't in the ISDS specification any more:
Date of Birth -- Explicitely excluded, most likely due to privacy issues.
Diagnosis Date / Time -- The ISDS specifiction doesn't include this data element.  It seems as if it would be useful, so I'm not sure why they didn't include it.
Discharge Disposition -- Now uses UB04 instead of UB92 codes, but otherwise the same.  This would have been fixed in HITSP had we ever gotten the change to update the V2 specifications to the new data architecture.
Heart Rate -- Not included in the ISDS specification, not sure why.
Blood Pressure -- Not included in the ISDS specification, not sure why.
Nurse / Triage Notes -- Not included in the ISDS specification.

Altogether, I'm pretty happy with how well the work matches what was already done in HITSP.  I'm extremely dismayed that the developers didn't report these deltas in their own efforts, because it is pretty clear that they could have rather easily.  I did it in about 4 hours of effort, mostly because I had to copy/paste tables from the Adobe PDF into a spreadsheet in order to complete the analysis.  That was a total waste of time.  Once that was done the analysis took about 15 minutes.  At least with the HITSP work I had the original source for the tables.

When this work is done, I want it to be available as an HL7 Version 2 Profile -- Enough of these PDF tables.  Also, I want to be able to post comments on this work.  It's fine to get comments from the Joint Public Health Information Task Force, but you also need feedback from implementors of these specifications, or as I said previously, the process is broken.

The specification needs to be a heck of a lot easier to read.  Those tables were a nightmare.
1.  Put the information in the tables in the order it appears in the message.
2.  Show the message segment layout first
3.  Put table stuff in tables and notes below in text for each field, just like HL7 does for the standard.  It's a lot easier to get through that way.
4.  Separate fields and segments and defines lengths for each.

ONC Relaxes 2011 requirements on Guides for Public Health Reporting

It took them about 7 weeks to write and publish the 18 or so pages needed to fix the problem, but fix it they did, and in the right way given deadlines under Meaningful Use.  ONC has removed the use of the HL7 2.5.1 implementation guide specified for public health reporting in a recent interim final rule.  The rule is now "on display" and is expecte to be published in the Federal Register on or soon after Wednesday of this week.

You can view the rule (now published in the Federal Register) below:


I still owe you a review of the work being done by ISDS. That is, in my opinion, presently being implemented through an unbalanced process that is dominated by one side of the transaction (the one not having  "receiving" requirements under the Incentives rule).

Having said that, at least the current rule allows implementations to proceed using the 2011 criteria, and we can all breathe a bit easier right now. You will soon be able to just simply use the HITSP C39 Specification for public health reporting without hacking it to support 2.3.1 as I had previously suggested.

I'm not sure how much of that seven weeks delay could have been saved without eradicating the root cause of the mistake in the first place.  While we presently have Government 2.0 initiatives, I'm not sure that we are quite ready for "Agile Government" or the potential backlash it could cause.  But, maybe something could be done about more nimble communcations...

Good and Fast work, but BUSTED Process

This is the Preliminary EHR Data Requirements for Syndromic Surveillance from ISDS.

Page 6 section 1.2 Meaningful Use Working Group Charter and 1.2.2 Membership is the most interesting to me, quoted below, emphasis mine:

1.2 Meaningful Use Workgroup Charter

By January 2011, the Workgroup will recommend a contemporary business model of syndromic surveillance and its core data requirements, using a community consensus-driven process.
...
1.2.2 Membership

The eight-member group consists of syndromic surveillance experts from state and local health departments from across the U.S. Workgroup members are actively engaged in day-to-day system operations and are developing or implementing health information exchange technologies.

In HITSP days, this definition of a consensus group that omits consumers of a specification, users of products that need to implement it, and vendors required to implement it would get the second worst marks possible during "Tier 2" review, only worse being a proprietary specification.

The prinipal of balance is completely lost here.  It may be good, and fast work, and in the 30 second skim, it even looks pretty much like what HITSP came up with after months of deliberation. 

BUT! The process is BROKEN, and the deadlines here will NOT WORK for Meaningful Users.

MeaningfulUse IG for Public Health Surveillance WILL Change

About a month ago I posted on the topic that the implementation guide chosen to be used with the HL7 2.5.1 standard for public health surveillance was likely to change.  Confirmation came shortly after via the HIT Standards Committee, and has since been acknowledged in an ONC FAQ.

Details on what the plans are to replace this guidance have been relatively limited, and so most implementations are either struggling with the wrong guide still, are hopefully using the advice I gave on how to use the HL7 Version 2.3.1 standard with the HITSP C39 specification.

Here's what's been going on since then.

CDC has been enaged with the International Society of Disease Surveillance (ISDS) on Disease Surveillance topics.  They asked ISDS to engage on this topic.  There was apparently a meeting of ISDS members earlier this month in New York City to discuss the issue, but I don't have many details beyond that.

Sundak Ganasen (Lead CDC Vocabulary Specialist) recently shared some of the outcomes of earlier discussions with ISDS to the HL7 Public Health and Emergency response workgroup through their public mailing list.  You can find that document below:



ISDS subsequently engaged with HLN Consulting to help them develop a consensus-based guide.  I've had some discussion with HLN regarding this work. 

Some of the challenges are that the existing work is in the "Biosurveillance" space which is not necessarily the same space as Syndromic Surveillance, although there are certainly overlaps.  I would argue that the C39 specification is simple enough to get us started while we wait for a larger body of work to be completed. 

The other challenge is having a public health system that is prepared to accept the data, and that is probably a strong argument from the public health perspective.  From the meaningful use perspective, though, trying to ensure that public health gets something they are prepared to use in the timeframes mentioned in the document above will fail for phase 1.  I say that because January 2011 is too late to have a specification that can start being developed upon in time for it to be implemented for phase 1.  That will mean that we wind up with a rather large variation in HL Version 2.3.1 implementations which public health will be equally unready to accept.

This is a difficult challenge.  I almost think that we must step back, and look at surveillance as a phase 2 requirement at this stage, given the time frames.  It is a shame, because it really should fit into phase 1.  The only realistic way to succeed for phase 1 is to get a final specification into the development pipeline by the end of October, and even that will be unlikely to see wide adoption.

HL7 to Offer Program on Standards for MeaningfulUse of EHR Technology at Annual Meeting

This crossed my desk this morning, which was right on time since I submitted the draft yesterday ;-)

This will be a great program for those of you in the Boston/Cambridge area on October 4th.  HL7 experts will be describing the 5 HL7 Standards selected for meaningful use.  I'll be speaking on CCD and CDA as you see below, and we've lined up experts and excellent speakers on the other HL7 standards.

     Keith

---

Health Level Seven® International

For Immediate Release

HL7 to Offer Program on Standards for Meaningful Use of EHR Technology at Annual Plenary and Working Group Meeting

          Ann Arbor, Michigan, USA – August 26, 2010 – Health Level Seven® International (HL7®), the global authority for interoperability and standards in healthcare information technology, today announced the speakers for their Ambassador program on Standards for Meaningful Use being held Monday, October 4, 2010 in Cambridge, MA.  This program qualifies for three Continuing Medical Education credits (CME) approved through the American College of Physicians and provides an overview of the HL7 standards used to achieve meaningful use under the new federal regulations.

          “As the healthcare industry is pushed forward to meet the meaningful use requirements under the ARRA-HITECH act, healthcare IT professionals and healthcare providers will have to work together to integrate computer systems and share patient data,” said Grant M. Wood, Senior IT Strategist at Intermountain Healthcare’s Clinical Genetics Institute in Salt Lake City, and host of the program.  “HL7 has solutions – from sharing lab data, to sharing summary data about a patient as they move from doctor to doctor, to even those who provide public health services like disease surveillance and immunization registries. This multi-topic session will help budding experts achieve this goal.”  

The program includes:

• HL7 and Meaningful Use by Gora Datta, Chairman and CEO, CAL2CAL Corporation.  Mr. Datta will provide an overview of what meaningful use requires, and how HL7 has been involved in the development of standards for meaningful use.
• HL7 Version 2 and Immunization by Alean Kirnak, President, Software Partners LLC; American Immunization Registry Association; Co-Chair, HL7 Public Health and Emergency Response Work Group.  Ms. Kirnak will describe the approaches to meeting Meaningful Use immunization registry reporting criteria using HL7 Version 2.  She will discuss the place of immunization registry reporting within the overall context of the meaningful use rule, as well as the potential future benefits to providers.
• HL7 Version 2 and Surveillance by Lori Reed-Fourquet, Consultant, eHealthSign, LLC and Anna Orlova, PhD, Executive Director, Public Health Data Standards Consortium Ms. Reed-Fourquet and Dr. Orlova will describe standards and approaches for meeting meaningful use requirements involving public health surveillance. They will discuss both provider and public health perspectives for bi-directional interoperable communications using multiple HL7-based messages, documents, and services.
• HL7 Version 2 and Electronic Lab Reporting by Austin Kreisler, Technical Fellow, SAIC; Co-Chair, HL7 Orders & Observations Work Group; Co-Chair, HL7 Domain Experts Steering Division; Member, HL7 Technical Steering Committee.  Mr. Kreisler will describe the relationship between meaningful use and the reporting of laboratory result data to public health agencies. This presentation will describe the various ways laboratory result data are utilized by public health agencies and show how HL7 standards are used to facilitate use of that laboratory data.
• HL7’s CDA and CCD Standards by Keith W. Boone, Standards Architect, GE Healthcare; Co-Chair, HL7 Clinical Document Architecture Work Group; Co-Chair, IHE Patient Care Coordination; past Co-Chair, ANSI/HITSP Care Management and Health Records.  Mr. Boone will describe the use of the HL7 CDA standard and CCD implementation guide to create clinical summaries and exchange health information between eligible providers and hospitals.  This session will also address the use of the HITSP C32 specification to the HL7 standards and guides.

The Ambassador Program event on HL7 and the final rule on standards for meaningful use will be held Monday afternoon immediately following the plenary meeting. For more information about this session, please visit http://www.hl7.org/events/boston102010/ambassador.asp. Additional tutorials providing more detail on HL7 standards for meaningful use, including HL7 Version 2, CDA Release 2 and CCD, are offered throughout the week.  For more information about HL7 tutorials, please visit http://www.hl7.org/events/boston102010/tutorials.asp.

          Online registration is now open. Early bird registration offers a discounted rate through September 10, 2010.  To register online, visit http://www.hl7.org/events/boston102010/.  Advance registrations will be accepted until September 24, 2010.  After September 24, 2010, registrations must be made on-site in Cambridge, MA. 

          HL7 Working Group meetings are held three times a year to provide its more than 40 work groups a chance to meet together to work on the standards and provide educational sessions for the healthcare IT community.

About Health Level Seven International (HL7)

Founded in 1987, Health Level Seven International is the global authority for healthcare Information interoperability and standards with affiliates established in more than 30 countries. HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving healthcare. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.

HL7’s endeavors are sponsored, in part, by the support of its benefactors: Abbott; Accenture; Booz Allen Hamilton; Centers for Disease Control and Prevention; Duke Translational Medicine Institute (DTMI); Eclipsys Corporation; Epic Systems Corporation; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Intel Corporation; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NHS Connecting for Health; NICTIZ National Healthcare; Novartis Pharmaceuticals Corporation; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; Quest Diagnostics Inc.; Siemens Healthcare; St. Jude Medical; Thomson Reuters; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs.

Numerous HL7 Affiliates have been established around the globe including Argentina, Australia, Austria, Brazil, Canada, Chile, Colombia, Croatia, Czech Republic, Finland, Germany, Greece, Hong Kong, India, Italy, Japan, Korea, The Netherlands, New Zealand, Norway, Romania, Russia, Singapore, Spain, Sweden, Switzerland, Taiwan, Turkey, United Kingdom, and Uruguay.

For more information, please visit: http://www.hl7.org/

# # #

MeaningfulUse IG for Public Health Surveillance likely to Change

Meaningful Use selects a number of different standards and implmentation guides.  Here's what it has to say about Public Health Surveillance:

§170.205 Content exchange standards and implementation specifications for exchanging electronic health information. The Secretary adopts the following content exchange standards and associated implementation specifications:
   ...
(d) Electronic submission to public health agencies for surveillance or reporting.
(1) Standard. HL7 2.3.1(incorporated by reference in §170.299).
(2) Standard. HL7 2.5.1(incorporated by reference in §170.299).
Implementation specifications. Public Health Information Network HL7 Version 2.5 Message Structure Specification for National Condition Reporting Final Version 1.0 and Errata and Clarifications National Notification Message Structural Specification (incorporated by reference in §170.299).

§170.302 General certification criteria for Complete EHRs or EHR Modules. The Secretary adopts the following general certification criteria for Complete EHRs or EHR Modules. Complete EHRs or EHR Modules must include the capability to perform the following functions electronically, unless designated as optional, and in accordance with all applicable standards and implementation specifications adopted in this part:

...

(l) Public health surveillance. Electronically record, modify, retrieve, and submit syndrome-based public health surveillance information in accordance with the standard (and applicable implementation specifications) specified in §170.205(d)(1) or §170.205(d)(2).

One of the teams that was looking to implement this internally discovered a number of issues with this selection.  In reviewing the PHIN specification, we found this [emphasis mine]:

1.1 SCOPE

This document specifies the structure and methodology for the use of the Health Level 7 (HL7) Version 2.5 Unsolicited Result Message (ORU^R01) to support electronic interchange of any de-identified Nationally Notifiable Condition message from public health entities to the CDC. The message structure is the same for the individual Case Notification, the Summary Notification, the Environmental Investigation Notification, and the notification of Laboratory report results to meet national reporting requirements to CDC.

On followup with experts from a state public health agency, we heard that this was wrong on several counts: 

1. This specification describes a framework for public health reporting from states to the CDC, not for reporting to state public health.
2. It's an old version (Version 2.0 is out).
3. It describes a framework for communication but doesn't describe what goes into the message.  One observer reported: "It specifies what the picture frame should look like, but not what the picture should be that goes in it."

I did some more digging, and was able to confirm that apparently there was some sort of bollux.  It isn't clear how CDC sent over the wrong guide to ONC, but apparently they did, and they don't seem to have anything current to replace it in their own set of guides.  I hear that the Council on State and Territorial Epidemiologists (CSTE) and the CDC are trying to figure out how to fix this.  In the meantime, every Healthcare IT Vendor is busy trying to impleent these requirements.

So what is an implementor to do while we wait for CDC and the rest to find the right solution, and for ONC to announce that there really is a problem and that it will be fixed?

Well, here's my advice:

1.  Use HL7 Version 2.3.1, because there is no implementation guide specified, and you can do something reasonable with it.
2.  Use the message formats defined in HITSP C39 Encounter Message Component, which is designed (in 2006 I might add) for the purpose of "sending patient encounter data (excluding laboratory, radiology) from a Biosurveillance Message Sender to a Biosurveillance Message Receiver.", but change the version from 2.5 to 2.3.1

This should be compliant with §170.205 (d)(2) (it will be an HL7 Version 2.3.1 message) and §170.302 (l) (by compliance with §170.205 (d)(2)).

Now, what should CDC and ONC do? 

1. Fess up.  Everyone makes mistakes.  Please correct this one swiftly, and with as much transparency as you possibly can.  We don't need heads to roll.  Meaningful Use has amazingly crazy schedules that we are all trying to meet.  Make it possible for us to meet them by giving us the information we need, when you know it, not after you've had a change to make it all better.  Cause by then, it will already be too late.
2. Give us a schedule for when you think the correction will be made.
3. Consider seriously using the HITPS C39 specification which was purpose designed for this specifc use case for the replacement.  I'll point out that the HITSP C39 guide had the input of experts from the CDC and Federal Advisory Committees conveigned on this topic, and State Public Health agencies.

I'm done kicking over bee hives for today.

Observations on Public Health

During a dinner conversation at an IHE Meeting, we were discussing some of the problems that public health faces in this decade. To put this into context, I need to set the clock back three years.  At that time,  three different constituencies (Clinical Research, Public Health, and Quality) worked within the IHE Patient Care Coordination domain for an entire year to develop a white paper describing their differences. What they came out with instead was a white paper expressing their similarities.  Public health extended the original paper several steps further, analyzing two different domains within public health to identify their similarities.

They came up with several important functional requirements needed by all stakeholders:

1. Expressing Criteria
2. Managing Patient Identity
3. Gathering Data
4. Retrieving Additional Data
5. Filtering and Data Review
6. Analysis and Evaluation
7. Mapping
8. Aggregation and  Reporting
9. Communication

The next year (after several important discussions about the pronunciation of acronyms), the Quality, Research and Public Health domain of IHE was formed (QRPH -- pronounced Quirf).

Now fast forward three years. Earlier this year we met with several members of the public health community at the PHIN Conference in Atlanta to discuss The Making of an IHE Profile.  During the discussion, we brainstormed several different ideas.  Many of the needs were already addressed in existing IHE profiles (the number of times that I said "IHE has a profile for that" was probably too many, but the point was made).  What came out of that were three ideas reported here which are being discussed in Oak Brook this week.  I'll let you know what happened to these ideas later this week.

Over dinner, we talked about how siloed funding has resulted in a siloed infrastructure (this isn't a new concept, it was identified in the early 1990's by a researcher at John's Hopkins University).  The solution is not to create more silos, but instead to figure out how to rationalize public health.  One concerned, and very much in the know person said "But that will never happen", and she's both wrong and right.  It certainly won't happen tommorrow, nor the next year, or even two.  However, it can be changed over time.  We just need to have the persistence to make it change, and show by example how to do it.  We also need to get people thinking about the future, instead of the last battle we lost.  We are still learning the wrong things in some places.

Take for example, the current H1N1 pandemic.  If you had asked people three years ago what pandemic we would be facing in 2009, I and likely many people working in public health would NOT have said H1N1 Swine Flu, but rather H5N1 Bird Flu. Where did all the money spent to deal with H5N1 Bird flu go, and why isn't that infrastructure effective for Swine Flu?  For that matter, what about all the money that was spent to deal with SARS in the previous decade?  Examine how funding for H1N1 surveillance, education, pandemic planning, et cetera is being awarded.  Huge grants and contracts are being issued, but as public health official told me last month, "That money runs out in June (2010) and we don't know what will happen afterwards...".  It's hard to build and maintain an infrastructure when the funding runs out because the emergency has past us.  We need to think about a sustained funding model for important public health issues. 

All is not lost, because others are learning the right things. One state near me looked at their public health infrastructure a few years ago and realized that if they were able to eliminate the inefficiencies in that state due to the information silos, thereby reducing duplicated infrastructure they could save about of $10 million dollars a year.  Upon learning this, their choice was to spend $5 million a year of that savings to build the right infrastructure that would help solve the problem and save them $5 million a year.  They are now looking at adopting an IHE infrastructure statewide in the service of their population, and won't be the first state to do so (I believe Vermont has that honor).

As I've become engaged in the healthcare space I've learned about two things:  patients and patience.  I no longer look for changes to occur in Internet time.  It takes about five to seven years to go from the initial stages of development for a NEW standard (as opposed to a revision of an existing one), into having several products available on the market using it.  It's going to take that long or longer to make some of the changes we need in public health (they need more than just one new standard).

Please Lord, give me patience  ... NOW!

The Making of an IHE Profile Part 2

Yesterday, several members of IHE, HITSP and HL7 spent several hours describing the IHE process to people at the PHIN Conference. Then we developed several IHE Profile proposals and selected one that will be passed on to the appropriate IHE Committee for review for the 2010-2011 development cycle (see IHE Patient Care Coordination Accepting Profile Proposals last month).

The first step of our process was to brainstorm ideas. Here are just some of the ideas that we came up with (there were a few more, but I failed to copy all of them down in my exhaustion after 10 days of travel, so I'm working from memory) :

• Case Reporting Workflow
  Reporting Public Health Cases from an EMR or possibly a PHR using existing clinical data, gathering additional case reporting data. This could also be expanded to further support case investigation.
• Cancer Treatment Data Gathering and Summarization
  Gathering cancer treatment data in a Cancer Registry from numerous data sources, and providing (possibly on demand) a summary of cancer treatment.
• Clinical Terminology Services/Vocabulary Exchange
  Supporting the exchange of terminology information for use within clinical decision support, Electronic Medical Record Systems and quality reporting systems.
• Alerting Dissemination
  Disseminating alerts and providing them at the point of care.
• Elligibility Workflow
  Obtaining information about a patient's elligibility to participate in a particular program, making a determination about their elligibility, obtaining consent to participate in a program, and to share information with the program, and enrolling the patient in the program.
• Emergency Department Surveillance
  Gathering data from emergency department visits.
• Forms Exchange
  Exchanging and deploying data collection forms from State public health to local public health.
• Electronic Laboratory Reporting
  Gathering laboratory data for surveillance.
• Electronic Master Patient Indexing for Public Health
  Supporting the use of a single EMPI for public health programs.
• Exchanging Disease Treatment Data with Surveillance Programs (e.g., Immunization and Influenza)
  Connecting different information systems used for public health with each other to see how treatment impacts the spread of disease. This could include passing a summarized data set between registries containing treatment data (e.g., Immunizations) with systems that monitor the spread of disease (e.g., Surveillance).
• Message Validation Services
  Supporting the validation of messages at runtime based on specifications.
• Gathering and Reporting Vital Statistics
  Reporting the details of birth or death to a vital statistics registry.
• Exchange of information about Healthcare Associated Infections
  Reporting Healthcare Associated Infections to public health officials.

Then we reviewed the different ideas and talked about what IHE has to offer already in these areas. In many cases IHE had a profile to meet the needs, possibly more than one. Many of these ideas involved:

1. Managing patient identity, for which the IHE Patient Identity Cross Referencing (PIX) and Patient Demographics Query (PDQ)profiles apply (also available for HL7 Version 3).
2. Gathering information from providers treating a given patient, for which the IHE Cross Enterprise Document Sharing (XDS.b) profile, and the Document Metadata Subscription (DSUB) profiles apply, as do the various content profiles from the IHE Technical Frameworks (e.g., the PCC domain's Emergency Department Encounter Summary (EDES), the Lab domain's Sharing Laboratory Reports (XD-LAB) and Laboratory Testing Workflow (LTW).
3. Exchanging dynamic requests for additional information, for which the IHE Retrieve Form for Data Capture profile applies.

There were several places where there are still gaps in the standards. On the alerting side and in a few other places, the ability to exchange rules that could be used for clinical decision support, or specific guidelines for treatment, or alerts, is still missing some critical standards. Another place where standards are missing or incomplete are document templates or messaging guides for reporting vital statistics information. In all of these cases, IHE members are involved in other standards organizations and are engaged in moving these activities forward.

Next we divided up into three groups, and each group selected one or two of the ideas that appeal to them to develop a brief profile proposal. The proposal needed to include:

1. Statement of the Problem
2. A Key Use case describing the problem
3. Identification of the Systems involved
4. Identification of Standards Available
5. Further Discussion

After developing the proposals, each team was given time to present them and answer questions. I asked the same question of each team, which was for them to somehow quantify the value or impact of that proposal on the existing situation in terms of patients served, workload reduced, et cetera. This is such a useful question that I've proposed adding it to the brief proposal template, and will be quizzing profile proposers for these details.

As a result of this tutorial at PHIN, we produced three different proposals, which are in bold above. The top vote getter is at the top of the list, and we will be moving that forward to the Quality, Research Public Health domain. However, there were no losers here, because the other two are also being persued by the groups who were involved. The Clinical Terminologies proposal will be passed along to IT Infrastructure, and the Cancer treatment data gathering and summarization will be passed along to either PCC or QRPH.

We were thrilled with the results of this effort, and I will be following these proposals as they move forward in the process. In addition, IHE PCC will be reviewing a second round of proposals earlier in 2010. This is in expectation that there will be additional demands for new work in early 2010 coming from various international groups, and to better balance our workload for the coming year.

I hope that we will be able to provide a similar tutorial session at HIMSS in February of this year, and I will also update you on the progress there.