IHE Canada Announces New Partnership and 2012 N.A. Connectathon Dates Announced!

IHE Community,

IHE Canada Partners with Canada Health Infoway

IHE Canada enters into an exciting new phase in their history. The International Board approved a formal agreement with Canada Health Infoway that will see this organization in its Standards Collaborative function and take over the role of Canada’s IHE National Deployment Committee. This change is a natural and welcomed evolution for IHE Canada. It will provide a formal representation at all government levels that establish the direction and priorities for healthcare standards in Canada.

IHE Europe’s Connectathon a Landmark Event!

Over 400 participants gathered in Pisa, Italy in April for the European Connectathon, creating a landmark event with a diverse program of activities held in conjunction with IHE’s Connectathon testing. Over 75 organizations conducted 2,200 tests of IHE integration profiles. IHE Europe also hosted a new testing event called Projectathon where 13 Member States of the European Union exchanged patient information to prepare for a new cross-border pilot program. Learn more about IHE Europe and visit their website.

IHE North America Connectathon Announces 2012 Dates

IHE USA is excited to announce the IHE North American Connectathon 2012 will take place January 9-14, 2012. In preparation for this event IHE USA has posted the 2012 Policies and Guidelines for participants to review in advance and prepare for registration opening August 22 and continuing through September 30, 2011. View Participant Resources and information on IHE USA’s website.

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.

Call, call, call, call ... sounds like a raven.

Where does the time go?  

Tuesday's are the worst day of my week.  I get on the phone starting at 9:00 and don't get off until 5:00, with no break for lunch.  More than half of these calls are dealing with SDO efforts involving HL7, IHE or the ONC SI framework.  Others are related, e.g., EHRA calls.

In a typical week, for HL7 I have as many as 5.5 hours of meetings. For IHE PCC, I have from up to 3 hours of calls I could attend.  For the ONC Transitions of Care I could attend 7.5 hours of calls. For the ONC Laboratory Reporting Initiative I could attend 4 hours of calls.  For EHRA there are as many as 4 hours of calls I could attend.

That's 3 solid days (24 hours) worth of phone calls, leaving the remaining 16 to do the actual work, and doesn't count any time for internal calls or "real work".

Needless to say, I'm not on every call I could possibly be on.  After all, everything that is urgent is not necessarily important.  But for some reason, I cannot seem to make a free hour on Tuesday (internal calls are not shown above).  On Tuesday's everything seems to be important.  So, today's blog post is me whining about calls ... instead of something useful.

And of course, there's personal time needed to finish up proofs on the CDA book.  Fortunately, I finished last night at oh-dark-thirty.  It should be out in a few more weeks.

Sorry.  Maybe if everything wasn't so urgent it would be different.  Maybe next week will be better.  Oh.  I forgot.  It's the HL7 Working Group meeting.  We start at 8:00 with meetings over breakfast and go into Dinner and the meetings after dinner.  Well, at least I'll be in Orlando where the weather will be nice -- nope, sorry, not this time.

Some thoughts on Canonical Pedigrees

One of my colleagues is working on the HL7 Canonical Pedigree Project.  The point of this project is to develop reference content that could be used to test various representations of the pedigree.

One of the interesting challenges in Pedigree representation is being able to look the genetic information from the perspective of different probands.  Being able to look at a genetic history from different perspectives allows for a variety of different techniques to be used for analysis.

In order to represent the family tree, the HL7 Pedigree model allows for two persons to be represented with a coded relationship between them.  The coded relationship comes from the HL7 Family Relationship Role Type vocabulary.  The essential model is that the patient is related to (at least) one other person, who could in turn be related to other persons, et cetera.

There is no requirement for the "pedigree" graph produced to use any specific relationship (e.g., parent, sibling, spouse), unlike what would be found in a "historical pedigree" such as this one.  The vocabulary allows for exact (natural mother) and inexact (mother) relationships to be represented. Transforming when this sort of vocabulary is used to represent relationships, changing the viewpoint from one subject to another can be challenging.

I argued with my colleague that any canonical representation of a pedigree needs to also include a canonical representation of the relationships, and that the current vocabulary doesn't help at all, since it has a focal point that isn't really reversible.  Changing the proband requires changing the direction of relationships and associated vocabulary.

23 and me has a great video describing the cousin relationship which helped me work through some of this.  If you want to whether someone is your Nth cousin, and at how many removes they are, there's a simple answer.  Cousins share a common grandparent (or great-grandparent, et cetera), but not common parents (that would be sibling, nephew, aunt, et cetera).  To find the degree, count the number of greats between both parties to their common grandparent.  Take the largest number and add one.  If you and I share a common grand-parent, then the number of greats for both of us is 0, to which I add one, and discover we are first cousins.  Now, if it's my grandparent, but your great-grandparent.  To find the number removed, you are looking at the difference in generations.  Simply take the difference in the "great" count.

The unifying principal that I worked out is this:

In order to canonically represent relationships, you must only represent those between ancestors and their offspring.  You can take it in either direction, dealing with "begat" or "was begatted by" as the preferred direction.

In the canonical form, then, you wouldn't need to represent the "cousin" relationship directly.  Instead, you'd relate the two subject to their common *-grandparent.

We can construct a vocabulary to do that.  Just use F to represent natural father, and M to represent natural mother.  FF becomes my father's father, and FM my father's mother.  The vocabulary can be modified to be more concise.  Whenever F or M repeats, just put the repeat count following it.  FF could be represented as F2.

To deal with ambiguity of the ancestry (if X is my first cousin, is it through my father's or mother's side), we could simply use P to represent parent.  So, if X is my first cousin, we have a common grandparent, Y.  X is related to Y by P2, and I'm related to Y by P2.  If you don't know how far back the relationship goes, you could use the + operator.  My cousin (first, second, third or more) and I would be related to a common ancestor Y using P+.

The nice thing about using this form for a canonical relationship is that it doesn't matter who the proband is, the set of relationships that are in the pedigree don't have to be modified when the subject changes.

While this would seem to capture almost everything needed in a pedigree, there's one genetic relationship that isn't expressed.  See if you can discover which one.  The answer is in comments below.

Cross Enterprise Document Workflow

Automating workflows within an enterprise is very different from automating them across enterprises. Within an enterprise one can expect a common platform for workflow automation. Processes can be well-defined, controlled and responsibilities assigned for management and escalation. Think about what you go through to purchase a piece of hardware or software in your own environment. Across enterprises it gets quite a bit more complicated. A common platform is hardly likely. Obtaining agreement on processes is not easy, and can require quite a bit of manual intervention. Think about what it takes to approve a new supplier for goods and services. In most businesses though, dealing with a new supplier still works because there are well defined inputs and outputs at the interfaces between the organizational workflows. You issue a PO, the supplier responds with a well defined package of goods or services and an invoice. When all goods and services are delivered, you pay the bill.

Imagine how complicated cross-enterprise workflows would get in your organization if your IT department required detailed information about the steps used to diagnose and repair a broken laptop that it sent out to someone else to repair, and furthermore wanted to automate the workflow across the two organizations to keep track of status. Some will tell me that they even manage this, and I'm certain they do. Usually with one or two other organizations that they have developed a pretty strong business relationship with. Scale that up to hundreds of other organizations or more, and I can assure you that it isn't done.

But in healthcare, these sorts of workflows happen all of the time. And healthcare providers need to track and route what is happening. Enter Cross Enterprise Document Workflow (XDW). The purpose of XDW is not to "automate" workflows within or even across enterprises. Instead, it's about tracking what happens, or should happen in the next few well-defined steps, and being able to look inside any "sub-workflows" initiated.

Think about a simple referral. Provider detects finding, refers patient to specialist. Specialist examines patient, treats patient and report back to the orginal provider. Getting a bit more complex, the specialist has an additional finding that he/she sends off to someone else (e.g., pathology) to look at. That result is reported back to the specialist. Because of that result, additional treatment (e.g., surgery) is needed. Complications due to surgery require additional treatment (e.g., PT) for recovery. And so on.

Consider that each provider involved in care may have a referral network that includes hundreds of other healthcare providers and organizations. Consider also that the patient may decide to use other healthcare providers that aren't already known to the originating provider.

So we need to think about this differently. The function of workflow automation in healthcare needs to support tracking what is happening to a patient without requiring a "definition" of the workflow to exist up front. XDW allows a healthcare provider to initiate a task, provide inputs in the form of documents, and to track the status of a task, and look at the "outputs" (again, documents). A provider that is working on a task can "claim ownership" of it, generate outputs associated with it (e.g., diagnostic results or consult notes), and initiate new tasks to ensure the completion of the workflow that was initiated by the initial request for consultation.  As the workflow proceeds, it can take new and unanticipated directions without any pre-coordination being required by the initiating provider.

Sounds like cool stuff.

IHE PCC Reconciliation

IHE PCC just finished a week full of meetings in Oak Brook to complete development of its profiles and white papers for public comment. One of the profiles we are working on this year is Reconciliation of Diagnoses, Allergies and Medications, or RECON for short.

The RECON profile has one actor, the reconciiation agent. Usually this would be implemented by an EHR system. The actor has functional and technical requirements.

Functionally the actor is required to access clinical information about problems, medications and allergies. That information must be able to come from clinical documents, and may also come from queries using the IHE QED profile, or using data from other unprofiled sources.

The actor must then determine which of the various diagnoses, allergies and medications reported from the various information sources are in agreement, and which are different. It must then suggest changes to make to a final list. IHE doesn't say how those changes are suggested, but does offer some guidance in this profile on what information might be used to help make those decisions.

The healthcare provider using the system that supports this actor will then be able to make any corrections, additions, or updates to the lists.

Finally, the system must be able to report the reconciled results. The results reported include what was accepted by the healthcare provider during the reconciliation process, of course. But they also identify the healthcare provider(s) who reconciled the data, and the information sources that were used during reconciliation.

This profile will enable systems to take advantage of information communicated in, for example multiple CCD documents, and to coordinate it with information stored within an EHR. One benefit of this profile that because it also records the sources of information which have already been reconciled, a receiving system can also avoid work by taking advantage of that fact. Thus, if a system receives information in document C which contained information reconciled from document A and B, then it could avoid reconciling against document A and B again.

It will soon be published for public comment and I look forward to your feedback.

Comments on the CDA Consolidation Guide

This is the last thing you are going to hear from me on this topic for a little while ... at least until the HL7 Working Group Meeting later this month.

I just uploaded my ballot comments (an Excel spreadsheet) on the HL7 CDA Consolidation Guide.  I copied my comments verbatim from what IHE prepared and agreed to this afternoon.  There was barely enough time to prepare those, and all we looked at were problems, medications and allergies.  Some of the comments also came out of the CDA Documentation Work group's review of the project against  requirements the work group agreed upon.

Overall, I'm very disappointed with what has been produced to date.  I'm also uncertain as to the future of this project.  We sorely  missed our goals in this round of balloting.  There's a tendency in the Structured Documents workgroup to push to meet arbitrary and/or unreasonable deadlines (in my personal opinion).  This is especially true when there are external forces like our national agenda pushing so dreadfully hard on this project.  It's hard to get anyone to slow down.  The idea that this guide could become the basis for Meaningful Use Stage 2 still has a lot of people excited.  

The project has got a LOT of potential, and I still support it.  We need to take a step back from the current deadlines.  If they remain, I don't believe the project will succeed.

What we need is a tool that will solve the problem.  To get there, we need to understand the requirements that tool must meet.  That includes the template meta-model the tool must support, the requirements on the documentation that the tool must produce, and requirements on production of the end result.

We also need the data of the pre-existing work, entered into the tool, and vetted against existing conformance critiera.  Getting at the HL7, IHE and HITSP conformance data is not an insurmountable task.  Much of it is already in machine readable form (Schematron) and structured text (even if it is Microsoft word tables or PDF files).  Extracting and Vetting the data is tedious but doable.  I've previously extracted data from IHE and HITSP specifications before -- it truly can be mind-numbing.  It takes about a week or so (effort, not elapsed time -- that's much longer in my world).

This is what it takes to get the data:

• For documents:  Extract table to spreadsheet.  Normalize to common format.  Generate XML from spreadsheet rows.
• For sections:  Same general idea.
• Conformance constraints:  Extract these from source documents based on a conformance style (I built a list of constraints in HITSP specs by ensuring all constraints used the same style, then generated a TOC using word from that style (w/o page numbers).  If no common style is used, create and apply one manually (mind-numbing but actually pretty quick work).

After we have the existing template data, we can import it into MDHT.  Then we need to modify the constraints to produce the new templates, and compare the differences.  That comparison can be automated if the template meta-model is appropriately designed.

Trying to re-architect something that took six years to develop across three organizations which includes hundreds of templates and thousands of rules should NOT be done manually.  I was involved in most of these efforts, and I did quite a bit of that work manually.  It wouldn't hold together today if it hadn't been for the efforts of one person who QA'd that work across the same set of organizations.  It won't scale.  People cannot keep up with what we need.

But what did we do in the CDA consolidation process?  We relied on people to identify inconsistencies when software would have done a better job.  We relied on people to create examples when software could have done so more accurately.  We still rely on people to produce the final schematron. We relied on people to produce a change log.  We relied on people when what we wanted to start with was automation.

Let's get smart, and go back and build the automation that we want.  MDHT is a great start.  All you need do is compare this (HL7 Genetic Testing Report Guide ZIP file using MDHT) to this (CDA Consolidation ballot).

And what should we do in the interim while we develop MDHT?  Well, six years of effort may not have produced the greatest set of implementation guides, but C83 and C80 work for us already today.  More than 250 EHRs support much of it already.  A couple of small changes in Meaningful Use stage 2 would accomplish many of the documentation goals that the Transfers of Care project has.  C83 already includes templates that support H&P, Progress Notes, Consult Notes, Emergency Deparment Encounters, Referrals and Discharge Summaries.  These come from the very same source projects that the CDA Consolidation project is working with.  If you cannot wait for harmonized output from MDHT, then the next best thing is to work with the harmonized results that we humans produced over the last six years.