Time Relationships and HQMF

Anyone who has developed a project schedule using one of the common project management tools has run across the number of different ways you can describe the relationship of  two activities with each other.  For example:

• Activity X starts after the start of Activity Y
• Activity X and Y start at the same time.
• Activity X starts after the end of Activity Y
• Activity X ends after the start of Activity Y

Et cetera (and note that the above is not a complete list).

One of the challenges in Query Health is being able to describe the relationship of two events with respect to each other:  For example, in the case where you want to find all cases where the patient was diagnosed with some particular disease within the measurement period.

There are a number of different ways to look at this.  The simplest is to understand that you have two events, X and Y, with a start and end time.  Thus, you can compare X.start or X.end to Y.start or Y.end.  You also have three atomic comparative operations, less than <, greater than > and equals (which you can combine to product less than or equal to, greater than or equal to, or not equals).

You can combine these into a relationship in the form X.time operator Y.time.  You have 2 choices for time on X and Y (start or end), and three choices for the operator (<, > or =).  That gives 2 x 2 x 3 or 12 different possible comparisons.  We've already eliminated some duplication by saying that X is first, and Y is second.  That way X.start > Y.start and Y.start < X.start are eliminated as duplicates.

The table below pretty much describes all possible atomic relationships, along with a short code to describe it.

X	starts	before	start of	Y	(SBS)
X	starts	concurrent with	start of	Y	(SCS)
X	starts	after	start of	Y	(SAS)
X	starts	before	end of	Y	(SBE)
X	starts	concurrent with	end of	Y	(SCE)
X	starts	after	end of	Y	(SAE)
X	ends	before	start of	Y	(EBS)
X	ends	concurrent with	start of	Y	(ECS)
X	ends	after	start of	Y	(EAS)
X	ends	before	end of	Y	(EBE)
X	ends	concurrent with	end of	Y	(ECE)
X	ends	after	end of	Y	(EAE)

We can combine some of these to form other interesting cases.  For example, event X occurs during event Y if X starts after or concurrently with Y starting, and ends before on concurrently with Y ending.  Event X and Y are concurrent if they start and end at the same time, et cetera.

SBS and SAS, SBE and EAS, SAE and EBS, EBE and EAE, SCE and ECS are inverses.  If X SBS Y, then Y SAS X, and so on.  We could remove the inverse and still be able to express any relationship just by swapping the position of X and Y.  I've marked the ones I suggest we keep and throw away in the table above.

(Just for fun, you might note that SCS and ECS are self inverses: X SCS Y implies Y SCS X, and so on).

Here is the HL7 Vocabulary for time relationships:

Code	Display Name	Definition
CONCURRENT	concurrent with	A relationship in which the source act's effective time is the same as the target act's effective time.
DURING	occurs during	A relationship in which the source act's effective time is wholly within the target act's effective time.
EAE	ends after end of
EAS	ends after start of
EBS	ends before start of
ECW	ends concurrent with	A relationship in which the source act's effective time ends with the end of the target act's effective time.
EDU	ends during
OVERLAP	overlaps with	A relationship in which the source act's effective time overlaps the target act's effective time in any way.
SAE	starts after end of
SAS	starts after start of	The source Act starts after the start of the target Act (i.e. if we say "ActOne SAS ActTwo", it means that ActOne starts after the start of ActTwo, therefore ActOne is the source and ActTwo is the target).
SBS	starts before start of
SCW	starts concurrent with	A relationship in which the source act's effective time starts with the start of the target act's effective time.
SDU	starts during

The non-atomic codes are underlined in the above (they are combinations of two relationships)
To simplify things, I've mapped the HL7 atomic codes to my atomic codes in the table below:

X	starts	before	start of	Y	(SBS)	SBS	starts before start of
X	starts	concurrent with	start of	Y	(SCS)	SCW	starts concurrent with
X	starts	after	start of	Y	(SAS)	SAS	starts after start of
X	starts	before	end of	Y	(SBE)
X	starts	concurrent with	end of	Y	(SCE)		Missing
X	starts	after	end of	Y	(SAE)	SAE	starts after end of
X	ends	before	start of	Y	(EBS)	EBS	ends before start of
X	ends	concurrent with	start of	Y	(ECS)		Missing
X	ends	after	start of	Y	(EAS)	EAS	ends after start of
X	ends	before	end of	Y	(EBE)
X	ends	concurrent with	end of	Y	(ECE)	ECW	ends concurrent with
X	ends	after	end of	Y	(EAE)	EAE	ends after end of

Looking at the table, you can see lines where my code is in italic and HL7 has a code, and other places where my code is in bold, and HL7 doesn't have a code.  These are discrepancies in the HL7 Vocabulary for comparing the time sequence of two events.  Missing codes represent conditions that cannot be expressed simply using an atomic relationship.  Added codes indicate cases which can be represented in more than one way.

For Query Health, we probably don't need the missing codes, but HL7 might consider adding them to address other use cases where the time relationship value set is used.   With respect to the extra code (SAS), I believe that we'll advise the use of SBS with the inversion indicator rather than SAS just for consistency.  Ideally, I'd like to avoid the inversion indicator all-together, and would propose that all twelve of these conditions be allowed to express time relationships in a natural way.

As for the non-atomic relatioships that HL7 has provided, I believe that they are fine for Query Health, and don't care to get into a deep analysis.  The number of meaningful ways that you could combine two or more of these atomic comparisons is more than I want to deal with right now.  When HQMF goes forward, I suspect that several harmonization proposals will be made, and deeply argued.  Might as well get it out of the way now.

ONC releases New Guide on Health Information, Privacy and Security and MeaningfulUse

ONC's New Guide on Health Information, Privacy and Security and Meaningful Use ONC's Office of the Chief Privacy Officer (OCPO) recently released a "Guide to Privacy and Security of Health Information,"* an instructional guide designed to help healthcare practitioners, staff, and other professionals better understand the important role privacy and security play in the use of electronic health records (EHRs) and Meaningful Use. The guide is a comprehensive, and easy-to-understand tool to help providers and professionals integrate privacy and security into their clinical practice and includes sections addressing: ·       Privacy & Security and Meaningful Use ·       Security Risk Analysis and Management Tips ·       Working with EHR and Health IT Vendors ·       A Privacy & Security 10-Step Plan ·       Health IT Privacy and Security Resources Full Guide: Check out the full Guide to Privacy and Security of Health Information: http://www.healthit.gov/sites/default/files/pdf/privacy/privacy-and-security-guide.pdf. Sections of the Guide: You can also download individual sections of the guide. Please visit the privacy and security section under the Providers & Professionals tab on HealthIT.gov: http://www.healthit.gov/providers-professionals/ehr-privacy-security   Together, we can build a culture where privacy and security are respected and valued to inspire confidence and trust in health IT and electronic health information exchange by protecting the confidentiality, integrity, and availability of health information. *OCPO developed this guide with assistance from an ONC cooperative agreement partner, the American Health Information Management Association (AHIMA) Foundation.

IHE Liaison Report to HL7

I'm the HL7 Liaison to IHE, which means that every four months I get to report to the HL7 Technical Steering Committee what IHE is doing that could impact HL7 standards.  The report is due today, and I also need a blog post, so I'm killing two birds with one stone.

NOTE:  This is not a complete listing of IHE Domain activities, just those using or having an impact on HL7 Standards.  This is also not a complete history, just a list of recent activities since the last time I gave this update to HL7.

Patient Care Coordination

• PCC is using the HL7 Infobutton Standard and the URL Implementation Guide to update the HITSP T81 Retrieval of Medical Knowledge transaction to support IHE requirements.  It uses the Atom format as the standard for responses, similar to what HL7 did with Infobutton DSS Implementation Guide.   To be published for public comment in early June.
• PCC is also developing three workflow profiles based on the IHE XDW profile to support eReferral, Telehome Monitoring, and Tumor Board which are not presently using HL7 standards.

IT Infrastructure

• ITI is developing a white paper on the exchange of Critical Results, with the anticipation of future profile development.  They are looking at HL7 Version 2.5, 2.7.1 or 2.8, and adopting (or pre-adopting) the R40, R41, R42 trigger events with the ORU to communicate critical findings.
• ITI is also developing a profile to support Patient Encounter Location Query, using HL7 Version 2.  Development is principally being handled through IHE-J.
• It is also developing a profile supporting the exchange of documents for mobile health, and has been looking at hData and other standards to support communication of clinical documents (e.g., CDA) between mobile devices and application portals.   To be published for public comment in early June

Quality, Research and Public Health

• QRPH is working on several CDA templates in support of Early Hearing Screening, Birth Summaries,  and Clinical Research.

Cardiology

• IHE Cardiology has developed CDA templates for Catheterization (CATH), 
• The are presently working on a profile supporting Electrophysiology reporting using CDA.

Eyecare

• Eyecare has developed General Eye Evaluation Content Profile, using an HL7 CDA document to record a patient’s general eye examination. It consists of an evaluation of the physiological function and the anatomical status of the eye, visual system and its related structures. Planned to be released as a Draft for Trial Implementation in May.
• They are currently developing three clincial documents related to Cataract Sugeries. Cataract Pre-Operative Note, Cataract Operative Note and Cataract Post-Operative Note. Expected to be published for pubic comment late in 2012.
  

Radiology 

• Radiology is developing a white paper on the management of reporting templates.  While this does not reference HL7 standards, it does address a topic of interest to Structured Documents with respect to the "Definition" of a document.

Laboratory

• The Laboratory Analytical Workflow (LAW) profile improves interoperability between in vitro diagnostic testing systems and health informatics systems by reducing complexity and variability in the exchange of information related to patient and QC test orders and to the result thereof. LAW supports the workflow of lab test work order steps and their results between analyzers and automation managers. LAW will be tested at the 2012 EU Connectathon.  It uses HL7 2.5.1.
• The Laboratory Clinical Communications (LCC) profile is to standardize and electronically capture common laboratory – provider communications around order modifications and result verification and interpretation. LCC is in progress.   It uses HL7 2.5.1.

Patient Care Devices

• Asynchronous Data Query (ADQ) is a profiling project within the IHE Patient Care Device domain to provide messages for a system to request device data from a repository containing device data. An HL7 query is used to specify the particular data that is desired.

Clinical Quality Workgroup Update

The HIT Standards Committee Clinical Quality Workgroup met today to discuss the status of the recommendations of the Essential Components (Value Set) Tiger Team, and the Optimal Characteristics Tiger Team.

The Essential Components Tiger Team has pretty much completed our initial scope of work, resulting in four recommendations:

1. Establish NLM as a single authority for the validation of value sets used in Stage 2 quality measures.
2. ONC should expedite recommendations of the Implementation Workgroup (Jan 2012) and Vocabulary Task Force (April 2010) related to establishment of a publicly available value set repository.
3. The value set repository established by NLM should build upon the IHE Sharing Value Sets (SVS) profile for storing and serving value sets, and incorporate Common Terminology Service 2 (CTS2) methods for managing vocabularies referenced by value sets.
4. Establish a web service for human and machine consumption of Meaningful Use 2 value sets. Consider NLM, AHRQ, or CDC as the Internet host for validated value sets.

Some of the interesting points made on the call today:

1. The value set format selected describes the expanded value set, rather than the definition.  Looking forward, there should be a way to express the definition of a value set also.
2. ONC should consider making available a forum where the public can report issues and/or questions raised about value sets.  That forum should be publicly available so that the public can also see what the status of current issues are, and what if any resolutions or answers are available.

You can find the slides below.

---

Questions and Answers on HL7 MeaningfulUse Stage2 Webinar

I presented a Free HL7 webinar today on HL7 Standards for Meaningful Use Stage 2.  It was the largest webinar audience I've ever addressed (over 360 people), and also one of the largest webinars HL7 has ever done.

We had time at the end to answer a several audience questions, but given the volume of participants, there was no way we could get to every question.  However, just like the last time I did a HL7 webinar, I promised to make an attempt to answer every question submitted, and am doing so now in this blog post.

Where Can I get...

1. the slides?
   HL7 will be making the slides available to attendees in a couple of days.  You should be getting an e-mail with the information on how to retrieve the slides once they have been posted.
2. the standards?
   HL7 Consolidated CDA Draft Standard is available from HL7
   HL7 Version 2.5.1 Standard  is available from HL7
   HL7 Version 2.5.1 Implementation Guides are available from HL7
   The CDC 2.5.1 Immunization Guide is available from the CDC
   The PHIN Syndromic Surveillance guide is available from the CDC (for Hospitals and Emergency Rooms only, an ambulatory guide is in the works but is not part of Stage 2).
   The Cancer Reporting guide is available from the CDC (for Ambulatory only, as Hospitals already have a method and requirement for reporting).
   The Laboratory Reporting Guide will be available from HL7 when they have finished Reconciliation.
3. the audio.  I'm sorry for the audio problems.  If you think there is a section you missed, this presentation was also given in March a conference in Valley Forge.  The folks there streamed the video out over Internet2, and so you can see a video recording of the material here.

I'll take the letter C for $44,000... 

1. Is CCR included in Meaningful Use?
   Yes and No.  The ASTM CCR Standard is a data set.  One XML representation of this data set  is what most people call "the CCR", but that is not the only standard representation.  The other standardized representation is the CCD.  The named standards for 2014 include CCD Version 1.1, which is a standardized representation of the ASTM CCR, and the sections that appear in CCD Version 1.1 also appear in other document types in that guide.  But that's probably not the question that was being asked.  If you want to know if the ASTM XML representation is included, the answer is simply NO.
2. Are CCD and CCR competing standards?
   NO.  The CCD is an implementation of CCR, and thus CCR is a core component of CCD.  However, the ASTM XML representations of the CCR and the HL7 CDA representations do compete.
3. What is the official use case of the CCD?
   The primary use case for the CCD is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient.
4. Why is the CCD not enough?
   CCD does not include other data specific to a providers scope of practice that identify other inputs (e.g., Review of Systems, Physical Examination, history of present illness), nor does it address details about what happened during the course of treatment (e.g., operative course, hospital course).  This information a) helps the receiving provider understand more about the patient and the sending provider's decision making and b) allows the sending provider to reuse clinical documentation already being generated.
5. How do you define the scope (which ones, and how far in the past) of labs to be included when sending a Consolidated CDA Document?
   MU appears to be concerned with laboratory results that were performed during the encounter, but is not specific.  The Test Results section says: The section often includes notable results such as abnormal values or relevant trends, and could contain all results for the period of time being documented.  See this post on relevant for more details.
6. What level of CDA is used?
   The CDA Consolidation guide itself allows for documents to be at level 1, 2 or 3.  The focus of Meaningful Use is on structured data, so the answer is level 3.
7. Can you explain the incompatibilities between Consolidated CDA and HITSP C32?
   Yes I can, but I haven't yet, that post is coming.  The main issue is with the Problem Concern Act in the two documents, which bubbles up through everything.  There are other minor details.  It's not hard, just slogging that needs to be done.  
8. What do you suggest that providers and vendors do now to address these incompatibilities?
   Keep listening here, look into the issues, and share your findings with others, as I will do here when I complete my own analysis.  If we could just get CMS and ONC to stop publishing stuff that needs feedback for a month or so, I might be able to do that.  And believe me, I share your pain.  
9. How far along is HL7 in their work with NIST to update the HL7 evaluators used by vendors for Certification preparations?
   I'm told that the new test plans and specifications will be published for public comment when they are available, just as last time.  I haven't heard the schedule yet, but I'll try to find out where they are at.  
10. Specifically on offering places to upload and test against proposed Stage 2 specifications for Public Health and CCDA?
    A CCDA Schematron was built, but not included in the December Publication.  I will ask that the corrections currently being made include Schematrons in the next release.  Also, MDHT will be releasing Version 1.1 Real Soon Now, and that will include CCDA test tools.
11. With CCDA and the added Clinical Documents will there be a section for Provider electronic Signature?
    There already is a place to record the presence of an electronic signature of the document in the CDA standard, and so it is available today in any CDA implementation guide.  However, you might also be  talking about a digital signature, which is cryptographic proof that an electronic signature was obtained. The esMD S&I Framework project is talking about both electronic and digital signatures.
12. Are the Standards that “could be” within the consolidated CDA - if they are not specifically named by ONC or CMS - are they “optional” to be in the CDA - (i.e. LOINC for age and vital signs)?
    If MU says SHALL, you won't be certified if you don't. If Consolidated CDA says SHALL, then to conform, you must do it, and to be certified you must conform.  If the Consolidated CDA says SHOULD, and MU is silent then to conform, you do not need to do it, but you should probably have a good reason. 
13. Can you talk about the MDHT project and how it could help EHR vendors in implementing Patient summaries and other types of documents?
    WOW.  Awesome! Dave deserves an award for putting that stuff together (and so does John but I'll have to address that some other day).  But Doug really does a great job talking about it, so I'll let his words fill in for mine.

Education

1. Is there any certification programme where an individual Healthcare Integration consultant can get certified and can benefit Healthcare providers in “Meaningful Use”  implementation Projects?
   There are at least three ways to answer this question. 1) ONC funded several workforce development programs at the undergraduate and graduate level and freely available undergraduate curriculum development, and certification testing  2) HL7 offers education and certification opportunities and also has an online e-learning program.  I teach at HL7 Working Group Meetings especially like the CDA class they offer during their educational summits.  Other organizations also offer CDA and HL7 training.   

Import and Reconciliation

1. Your thoughts on the clinical reconciliation mention in the NPRM for problems, medications and allergies from medical summaries.  ie: it seems clear that a CCD received in as part of a CCDA into an EMR, will have to digest these 3 sections of data (if present, and hopefully requiring standard nomenclature) and discretely display them in some section of a reconcilation area within a patient chart.
   IHE has a great answer for how to do this.  See Tuesday's post.
2. Is there a requirement to “import” discrete data  like Allergies, Problems from the Summary documents and update the EMR database?
   I feel like the Magic Eight Ball ... "Answer Hazy ... ask again later".  The notion of  incorporation  in the 2014 criteria has drawn a lot of criticism, because " incorporation of labs" is not the same as "incorporation of problems, medications and allergies".  The HL7 Policy Advisory Committee's expressed view (and my own) is that incorporation of the later requires some sort of reconciliation process.

Will it Stick?

1. What about the push to incorporate CCD summary data into the EHR as structured data in the patient record. Do you think that will be required in Stage 2?
   I would personally hope so.  As I mentioned above, the "incorporation" definition has certainly drawn quite a bit of attention, and it seems likely that there will be some clarification, but I would expect that it would be clarified rather than dropped.
2. Consider ICD-10 deadlines have moved, will there be a change in ICD-10 requirement for the summary document?
   ONC has signaled in the proposed rule that they anticipate following the CMS lead on ICD-10.  If CMS delays, any requirement in MU on ICD-9 or 10 will be challenging because the regulations will change in the middle of the Certification period.  I would hope ICD-10 would be dropped altogether, and others, including members of the  HIT Standards Committee have made similar suggestions.  Note: CMS hasn't made a decision yet, but they've certainly moved in the direction of a delay, so don't count any chickens (or skis on fire) yet. 
3. When will ICD9 be replaced by ICD10 in the context of coding meaningful use problem lists?
   Never if I'm reading current leanings.  The propose rule suggests SNOMED CT, and only retains ICD for Diagnoses (which is not the same as problems).  SNOMED CT has resulted in some backlash, and it's possible we could go back to the ICD or SNOMED model we had under the 2011 criteria, but I don't see ONC leaning in that direction.

Vocabulary Questions

1. What vocabulary is used to code diagnostic imaging procedures?
   No vocabulary is specified expressly for the purpose of recording diagnostic imaging procedures explicitly in the rule. However, the rule does say that Procedures must use ICD-10-PCS or HCPCS/CPT-4. Given that ICD-10-PCS includes imaging procedures, I would assume that is what must be used.  Consolidated CDA identifies SNOMED CT, ICD-9-CM Procedures, or ICD-10-PCS, or CPT-4 or LOINC as possible options (SHOULD or MAY), but has no specific requirements.  
2. How all labs will handle LOINC...
   Labs aren't incented under meaningful use, and I don't know what would incent them to use LOINC until the payers (including CMS) step in.  Some payers already have, and I know that most labs can already map their own codes to LOINC because of that.
3. There was direct mention of SNOMED-CT as vocabulary for Problems and LOINC for laboratory result messages. Is it correct to also indicate that SNOMED-CT is required for qualitative laboratory results in concert with LOINC for the specific tests?
   It would certainly be a good idea (CHI and HITSP both had it years ago), but it's not stated that way in the rule.  However, the implementation guide specified by the rule does require SNOMED CT for qualitative results in Microbiology, and so it is required for certain kinds of tests, but possibly not all tests.
4. Are there any efforts to harmonize SNOMED and MedDRA  vocabularies? In the EU, we are using MedDRA for pharmacovgiliance reporting as part of EVMPD.
   This is not my area of expertise, but I would expect that such an activity would be easy to find out about.  But Dr. Google says no.
5. Could you speak to the difference between “problems” and “diagnoses” and why SNOMED-CT is proposed for the former and ICD-10 for the latter?
   SNOMED-CT has long been agreed as being the best way to describe problems for the purposes of clinical decision support.  When you get to the term Diagnosis you have to distinguish between clinical and administrative uses of the term.  The term Diagnosis is so often used in billing that it appears someone forgot that the use of the term encounter diagnosis was still meant (according to several members of the HIT Standards committee) to be in the clinical context.  This is another reason why ICD-10-CM could disappear from the final rule.   

Infobutton

1. Can you expand on how Infobutton is to be used for Patient Education?
   Here is one possible scenario: On completion of a patient encounter, a clinician activates the patient education Infobutton associated with patient's diagnosis (or medication, or lab result).  The EHR locates appropriate content from a web accessible resource.  The clinician displays it, discusses it with the patient, and then prints it out.
2. Can you please provide functional scenarios for the Infobutton and Provider Reference Content?
   Here is one possible scenario drawn from the standard:
   A clinician is reviewing a problem list module of an EHR and is unfamiliar with a rare disease (Camurati-Engelmann Disease) that the patient, a 15-year-old female, has. The problem list module provides an infobutton link next to the "Camurati-Engelmann Disease" problem. The user clicks on the infobutton link, initiating an infobutton event.

Laboratory Reporting

1. Does the Electronic Laboratory Reporting include Blood Bank and Pathology or just LAB and MIC?
   The HL7 ELR guide describes the transmission of laboratory-reportable findings to appropriate local, state, territorial and federal health agencies using the message.  That includes pathology.  I don't see any reference to blood banking in the guide, but the experts can be found here. 
2. For Laboratory results, is it your impression that for stage 2 MU, Pathology discrete results will be required?
   This is not clearly stated in the HL7 LRI guide, nor is it clearly stated in other reference content.  It is an excellent question to post to ONC, and I will be doing so.  I would have to assume yes until ONC says otherwise.
3. We use ORU for the lab resuts with embedded PDF document, Do it qualify meaningful use?
   Since that does not follow the required, the answer is NO.
4. Why does IHE XD_LAB CDA based spec not show up in the S&I Laboratory Result Interface Initiative?
   Because the initiative was scoped to harmonize the HITSP and eLINCs Laboratory Reporting guides for HL7 Version 2.5.1, not replace them with something even better  ;-)

Odds and Ends

1. Is the HL7 also the normal output data format for most patient-care devices?
   I would assume that HL7 Version 2 and/or IEEE are the most common, but that's not my area of expertise.  It is for these guys though.
2. Wondering why HL7 version 3 isn't in the picture
   Hmm, given that CDA was the first Version 3 standard published by HL7, I thought about putting the answer to this question in the CDA section, but I expect the person asking it wouldn't expect to find it there, and for many CDA != Version 3.  I agree and disagree alternately depending on who I'm talking to.  The NwHIN Exchange specifications do include use of Version 3 (in their use of XCPD for example).  The real answer is that MU is step-wise refinement, and you might see Version 3 cropping up in later stages (even as early as Stage 3).
3. Are there any MU standard directly related to clinical research activities?
   No.  But you could use Infobutton to locate a clinical trial (a use case of the IHE Request for Clinical Knowledge profile I just finalized for public comment).
4. QRDA updated DSTU is for Stage 2, not beyond...
   QRDA has not been proposed in the Meaningful Use certification rule, although CMS has interest in it for quality reporting, which is related to that rule.  The QRDA updated DSTU may be for that "data file defined by CMS", but that also depends on which update to the DSTU you are talking about.  The update for "Category 1" is being supported by CMS, and is targeted (as I understand it) at some pilot programs for quality reporting.  The update supporting Category 3 is needed for aggregated reporting and for Query Health, and that is almost certainly NOT going to be ready for Stage 2, but could be for stage 3.  I believe both updates are included in the same HL7 project scope statement.   

Balloting Strategies

The HL7 Ballot for May closes this coming Monday, May 7th.  There are about three dozen specifications being balloted this cycle.  It's not really practical for a single person or even in many cases for a single organization to vote on every ballot that HL7 prepares.  IHE is preparing numerous profiles for public comment this week (more than a dozen there) for a 30-day public comment period starting next month.  Again, it can be challenging to comment on everything.

Over the years I've developed a number of strategies that can help you go through the ballots.  There are three key strategies to use when voting on standards:

1. Prioritize
2. Spread out the Effort
3. Borrow from Others   

Prioritize
This should be obvious.  You (or your organization) need not vote on everything that HL7, IHE or any other standards organization produces.  Focus only on those specifications that have an impact on your organization. HL7 and IHE have regularly scheduled times for balloting, which means that numerous specifications will be voted on in the same time period.  Other SDOs vote on standards when they think they are ready, which can spread out the work, but means that you have to pay more attention to schedules for individual work items.  Step 1 of prioritizing is to pick the specifications you plan on voting on for this cycle.

In HL7, ballots are "For Comment Only", "Informative", "Draft Standard for Trial Use (DSTU)", or "Normative".  For Comment Only ballots are just to get feedback and there will always be another opportunity to vote (sometime in the next year before it goes to a publishable stage).  DSTU ballots usually stay in Draft form for 2-3 years, and there will be an opportunity to vote on those again before they go normative.  Informative and Normative documents may not get balloted again for several years (Normative standards can go at most 5 years before being re-affirmed under ANSI rules).

When I prepare my ballot comments, I pay attention to the publications in this order: Normative, DSTU, Informative, For Comment Only.  That way, if I don't get through everything, I've covered the most important pieces first.

Spread out the Effort
Spread out the work.  If you have a team of experts (like I work with), assign one person to shepherd each document through its commenting process.  If you have a team working on one document, you can spread out the effort on a single specification by assigning different sections to different team members based on area of expertise.

We often have several members voting on one document, but assign one person to submit the comments.  All other voters simply vote as the assigned member tells them, and refers to their comments in their vote.  When you have several voting members in an SDO, this ensures that you take the maximum advantage of your voting rights.

There are several ways to review a document, each taking different amounts of time:

1. Skim and Scan.  Read through the document quickly (this works well for documents that have been through several cycles, or for "Comment Only" ballots where you want to provide high level feedback.  Skim the document first to identify potential problem areas (and focus your attention on the technical content that impacts implementation -- the normative content).  Then scan those sections deeply when you make comments.  
2. Read through and highlight.  A single person reads through the document, highlighting and commenting on issues as they are found.  Ballots in which content is available in Word or PDF format allow you to use commenting tools in those products.  I even wrote a Word Macro last year to help with this (many HL7 and IHE documents start in word, and even though that may not be what is published for the ballot, you might still be able to get access to the Word version).
3. When reviewing with a team, provide the team with an overview
   Reviewing with a team can provide greater coverage.  In order to save time, make sure you know how you are going to consolidate comments from the team.  HL7 has a ballot macro to merge several  comment spreadsheets into a single one.  This can be very useful in combining feedback.  Agree first on how to order comments (e.g., by line number or page number), so that you can sort comments by position in the document (allowing you to find duplicates or conflicting comments).
1. then Split up: This is useful when you have a team that is familiar with the topic, but which may not be familiar with the specification.  Usually this involves holding a meeting to provide an overview of the specification being reviewed, explaining what the material is, and explaining each person's responsibility to them. 
2. then read through separately.  This produces better coverage than overview and split up, but takes more effort.  
3. and Read Through together.  This is perhaps the most expensive method.  Usually these are run like a specification inspection or review.  It takes the most time, but gives people the opportunity to come to consensus on comments.  This is very effective when working together with several organizations.  

Borrow from Others
Borrowing from others not just an accepted way to address limited resources (it works for regulatory comments also), but is also encouraged by the process.  Ballots are always public, so you can readily locate what others have already said about the standard.  I usually (especially on ballots on unfamiliar material) look at comments submitted by other organizations to see what I should be looking out for.  This is especially true in the last day of the ballot cycle when I'm playing catch-up on my list of ballots to complete.

If you trust the comment submitter to properly represent the issue, you can even go one step further and simply refer to their comments.  Just be sure to support them through the ballot reconciliation process.

Borrowing from others is also a practice you can take advantage of when submitting your comments.  On critical ballots, I often point others to my comments (and try to get my comments out sooner).  This does two things:  It makes them aware of issues we might share, and saves them effort in finding the critical issues.

When you do that often enough, you'll find that other reciprocate, which can also make your life easier.

Happy balloting.

  -- Keith

Turtles all the way Down

IHE PCC has been struggling all week with three different workflow profiles.  One of the challenging pieces has been to identify the various systems involved.  IHE uses the term Actor to identify the useful feature sets that could be specified for a system.  We want organizations to be able to say:  I want to obtain a system that implements the ABC actor of the XYZ profile and have it be meaningful to both the purchaser and the developer of such a system.

PCC already layered content specific actors on top of the IHE ITI XDS, XDM, XDR and XCA profiles.  What we must now do is layer again, the workflow actors on top of XDW, and also associate these actors with content.  All of this of course uses a common infrastructure (XDS) to support automation of ad-hoc workflow.

I think we have the right idea now, and will be moving forward.  As with most design issues, it is fractal in nature, thus:  Turtles all the way down.