Improving SDO Inter-relationships

Sunday's Q4 session on HL7 relationships with other SDOs was a bit different this time around.  I promised Austin Kreisler that I would report on some of my thoughts that came up as we went through the meeting.  This is my report which I'm sharing with you.  The meeting started with the typical brief report from Liaisons, but we spend most of the times in a Panel Session that included:

Scott Robertson

Liaison to NCPDP and chair of the HL7 Organizational Relationship Committee

John Quinn

Liaison to the Standards Collaborative Organization

Tim Buxton

A participant in ISO initiatives

Christian Hay

Liaison to GS1

Lisa Spellman

Liaison to ISO TC-215 in her new role as ISO Secretariat

Myself

In my role as HL7 Liason to IHE

Each member of the panel briefly presented their role and issues they have in the Liason role with respect to the following three topics:

• Perspectives on cross SDO cooperation strategic road map (i.e., what the strategic priorities ought to be)
• Additional opportunities for cross SDO cooperation 
• Ideas on how to streamline existing cross SDO activities

One of the interesting issues that came up, especially with respect to the Joint Initiative Council, was the amount of rework and reiteration that has to go on as ballot items go through respective working groups in parallel.  Decisions made in one work group get reviewed and revised in another, which results in a great deal of reworking, sometimes with small but important divergences along the way.

Now, I remember when HL7, IHE and HITSP were all working together (quite well I might add), on the use case of sharing laboratory reports between healthcare providers.  HITSP was assigned the use case and was working on a solution, IHE was developing the XDS-SD profile (implementation guide) for sharing laboratory reports, and HL7 members were advising on the best way to go about it.  Austin and I were both deeply involved in that work, and were part of the core group of five that followed it through at least two of three organizations (I was unique in physically being present at meetings in all three organizations, others did T-con in).

There were several significant factors that led to the success of that effort that differ apparently from the JIC process.

1. All of us worked within the organizational governance of the meeting that we were present at, if HITSP, the rules of that organization, IHE or HL7 similarly.
2. The rules of all three organizations were sufficiently flexible to allow us to pull in outside parties to engage as necessary: Fracois Macary from France in a HITSP meeting, Austin who was involved in HL7 and HITSP as a member into an IHE meeting.  In fact, just about every SDO activity I know allows expert participation with appropriate process.
3. We reviewed progress at each meeting, but didn't reconsider progress just because we were in a different environment.
4. We deferred issues to the next appropriate meeting when we needed input from the right organization (e.g., several issues in HITSP and IHE were deferred until we could gather appropriate HL7 expertise).
5. There was enough of a core group to maintain both the momentum, and the collective corporate memory.
6. Everybody was willing to cooperate, and everybody got something out of the process, even if only one organization was publishing a guide.

The joint work on XD-LAB is still, to me and to this day, the best example of collaboration across multiple organizations that I've seen.  It was truly a grass-roots effort, where the participants were all interested in each organization, and so they were willing to work out a process to keep things moving forward.  One important contribution to this was that through HITSP (and also IHE), this project had a very clear deadline.

So, my suggestion for JIC projects in the future is that:

1. Each organization agrees to move the project forward serially through the organizations,
2. Each organization contributes its expertise in the way that is most appropriate to the project, and the project team agrees on the scope of each organizations contribution, so that issues clearly playing to one organization strengths are addressed by that organization,
3. Governance is handled through existing processes of each organization where possible, but with sufficient flexibility to allow "outside" contribution.
4. That a core group be put together to manage the project through each organizations process.  That core group should be committed to attending as many meetings across organizations as possible, and the SDO's should enable that participation as much as possible.
5. That these agreements be put into place across organizations is as formal a way as possible to enable 1-4.

I don't have the answer to the publication formatting issue that the querant who raised this issue also asked, and that still is a real problem.  However, as John Quinn suggested, I believe the ISO format is probably the best starting target for all involved, and I further believe that organizations should be agnostic as to how it gets into that format (if it starts as an HL7 V3 ballot, tooling should be used to massage it into the ISO format).  Let's not let how it gets there get into the way of getting it done.

Book Review: Ten Faces of Innovation

Friday, a book showed up in my mailbox, sent to me by my manager's manager. It saved me a trip to the bookstore for airplane reading, since I travelled to the HL7 Working Group meeting yesterday. The Ten Faces of Innovation is written by Tom Kelly of IDEO. IDEO is a design and innovation consulting firm that has worked with many large organizations; showing them how improve their innovation skills. I finished reading it on the plane yesterday. In brief, the author describes 10 key roles that are important to promote innovative ideas within an organization.

Anthropoligist

The person who views a process from the customer's viewpoint.
I've done this a few times and really enjoy it. I don't get the opportunity to do it often enough. My favorite experience was playing fly-on-the-wall during rounds at Intermountain

Experimenter

The person who enjoys quickly prototyping and demonstrating possible solutions.
I've built a number of prototypes over the years for IHE Connectathons and demonstrations (one of my favories is here). Some of them have made it into production systems, which I always find pleasing.

Cross-Pollinator

Someone with breadth in many spaces who can bring experiences from another domain into the problem domain.
Bringing together past experiences with current actiivities is something I did in this post.

Hurdler

A can-do person who figures out how to get over (or around/through/under) obstacles in creative ways.
My favorite method is around, after all, it is easier to get forgiveness than permission ;-)

Collaborator

A person who brings diverse groups together to solve a problem
I'm less of a collaborator that brings together dierse groups, and more of one of those people who gets pulled in to diverse groups

Director

Someone with the overall vision that helps the team solve problem.
Sometimes I have visions. It could be the hour, or too much caffeine, but at least they are consistent. But I'm not very good at building the right team and getting out of their way.

Experience Architect

Someone who looks at and develops the customer experience, thinking about "what are we trying to do" in refreshing ways
That's one of my favorite questions

Set Designer

A role that looks at how spaces and people interact
I've moved my office to be closer to people that I interact with, but these days that's a bit difficult

Care Giver

A role that anticipates customer needs and delivers what is needed to them.

Story Teller

Someone who communicates fundamental insights by relating them to well told, authentic stories
A lot of what I write here is storytelling.

In any book looking at and classifying roles, of course my first response was to find myself. You can see my comments on where I found myself in italics. The author points out that these are roles on a team, and that different team members may take on multiple roles at different times as appropriate.
One role that I've often taken up that he also mentions is that of "Devil's Advocate". While I won't ditch that role, I think I'll try to combine it with the others so that when I find problems, I also think about solutions.

Hacking my data

This post was spurred on by @NateOsit's comments about QS apps earlier today.  The conversation ended with this tweet (you can see the whole conversation in reverse order by clicking on the time/date of the prior tweet that each was in reply to).

One of my recent acquisitions was an iPad 2.  I purchased it from proceeds of my advance for The CDA Book.  I also got another toy, an iHealth Blood Pressure Monitor (I'm at risk for hypertension), and an app that lets let track my weight. These are both problems my father suffered from, and in part they contributed to his death, so I'm paying attention to them.  And, because like my father, I also have white coat syndrome, my BP is higher in the office than the rest of the time.  Having the BP monitor and a record to show my doctor has kept me off BP meds thus far.  But it's also made me more aware of my blood pressure.

One of the things that I don't like about the iPad, or most of the apps for it, is how difficult it is to get data out of them.  But then I ran across this article by Adam Crosby.  It explains how to find the files that are on my PC that correspond to files on my iPad.  It also suggests that many of them are easy to hack.  So, I went digging.

If you have an iPad and a Windows PC (like me), you can find the backup folder in a place something like C:\Documents and Settings\YourUserName\Application Data\Apple Computer\MobileSync\Backup\SomeLongHexString

That folder contains a file for every data store on your device.  For me, that folder contained more than 100,000 files, and took about 30 seconds just to list the directory.  Almost all of the files are named using a hexadecimal string.  Trying to find your data in all of this for any given app would seem to be a nightmare, but it really isn't that hard.  It took me about an hour.  Most of that was waiting time.

1. Close all of your iPad apps, or shut down and restart your iPad.  This step makes sure that only files you want are changed.
2. Sync your iPad with your PC
3. Make a copy of your backup folder somewhere else.
4. Twiddle your thumbs, or catch up on your RSS Feed while the disk churns.
5. Open the one app whose data files you want to find.
6. Change some data in it, and close the app.  Know what data you had and what you changed it to.  This could be important later when trying to decode the data.
7. Resync your iPad.
8. Make a copy of your backup folder again, in yet another location.
9. More thumb twiddling.
10. Using WinDIFF or other directory comparison tool, locate the files that have changed.
11. Reread war and peace.  This takes a while. (Don't really worry about the time, it took me longer to write this post than this whole process, and that was less than an hour).
12. Copy those files (there should only be a few) to another folder.
13. Do it again!  There's a reason for this, because you are going to modify some of them.
14. Now, go find plutil.exe on your computer.  I found it in C:\Program Files\Common Files\Apple\Apple Application Support.  This is a utility that lets you unpack binary PLIST files.  PLIST is an XML format for property lists, somewhat like the Windows Registry, but in an XML format (I mentioned it briefly in this post).  Binary PLIST is a compressed format that the plutil application can make readable for you.
15. Next, download a tool that will allow you to access SQLite databases.  This one worked just fine for me.
16. Now, dig through the files that you found that changed.
1. Some of them will likely be in PLIST format.
2. Others will be in binary PLIST format.  These can be detected by the presence of "bplist" at the type of the file.
3. Others might be in SQLite format.  These can be detected by the presence of "SQLite format" followed by a version number.

The files in PLIST format you can just decode yourself.

The files in BPLIST format you need to unpack using plutil.  Assuming you've added PLUTIL.EXE to your path, the command to "unpack" is PLUTIL -convert xml1 FILENAME

The files in SQLite format you will need to export to a CSV or other file format.

Once you've found your files, remember those nasty hex strings for them.  They'll be in the same place the next time.  So now you can start dumping data.

For my iHealth, the data file I wanted was in PLIST format.  It looked something like this:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<array>

 ...

<string>34</string>

<string>07-07-2011</string>

<string>08:10</string>

<string>117</string>

<string>79</string>

<string>65</string>

<string>6</string>

<string>1</string>

<string>0</string>

<string>0</string>

...

</array>

</plist>

The format is a big array of strings.  Each measurement has 10 strings.  The first is the measurement number.  The next two are date and time.  The next is systolic, followed by diastolic, then heart rate.  I haven't figured out the next four, but they don't much matter to me yet.  I can create an XSLT to reformat this into an HTML table, which I can then import into a spreadsheet and start graphing.

For the weight measuring app, it tracks four numbers in a SQLite database.  The userid (it can be used with multiple users), the date (recorded as the number of days since January 1, 2000), the weight, and something they call my "true weight" which appears to be a formula used to generate some sort of weighted moving average.  My weight is clearly recorded in grams (the app displays weight in lbs, stone or kg).

So, now I need a command line tool which will automate the export of the SQLite table file.  Another quick web search finds this collection of utilities.  The shell is what I want.  I can easily script that to load the file and dump its contents.

So now I can hack my data.  While I hate the iPad's closed architecture, one thing I do love is how easy it is to hack the data from it.  I think I'll turn this into an app to generate a table of values in HTML 5.  Then I'll add microdata tags based on my CDA R3 proposal.  Next I'll write some Javascript to plot the data  on a canvas with some pretty colors by getting at the raw figures in the Microdata.

If I can find a browser that supports the microdata DOM, I could have this app ready in time for next week's HL7 Working Group meeting.

Floating to a new Norm

Yesterday's original posting was interrupted by the Query Health call.  Another of the favorite phrases at ONC is "Ultra-Large Scale Systems".  It is often used to describe the extremely interdependent, hugely complicated, collection of systems across payers, providers and the federal government that is used to manage healthcare today in this country.

A number of Federal initiatives are driving for change in this complex patchwork quilt of enterprise applications.     Many of these initiatives are planning on changing the system by introducing large perturbations, in the hopes that it achieves a new norm.

One of the things that constantly interests me though, is how difficult it is to create a large change in a ULS.  These systems seem to have antibodies that reject any large change.  Change in and of itself is scary, which may be one reason for that.

What I like to think about are small, seemingly insignificant changes that can eventually result in a large scale effect.  One of the design principles of the IHE Reconciliation profile is a sort of self-correcting effect that eventually perturbs a collection of health records into something that contains fully reconciled data.  They don't immediately get that way and stay that way.  But as soon as a significant volume (the tipping point) of providers begin using it, the accuracy of patient medications, problems, and allergies data recorded in systems should improve dramatically.

The profile creates a set of small nudges, over and over again, to the data, improving the accuracy on each iteration.  The end result is appears to the uninformed as something like the butterfly effect.  In fact, what it is really doing is exerting a lot of small changes over time.  Those small changes add up, and the system floats up as it were, to a new norm.

Finding big things to change is easy.  Finding those little things to change, that's something worth thinking about.

  -- Keith

The Pace of Query Health

I'm still on the Query Health technical call.  It is very clear that there is a push from on high to move Query Health full speed ahead.  They want the project charter,  requirements, and use cases done by the end of the month.

Never mind that:

• Next week begins the HL7 Plenary meeting where many folks involved will be attending.  
• Our first work group calls were today
• Work group calls were pre-scheduled without any regard to the participant's calendars.  
• Or the conflicts between of the summer concert series and the CDC Public Health Informatics conference.

I've talked a lot about work group development processes.  The number of times that I've linked to this article is escalating.  Work groups need time to get started, to form and storm, and figure out what they are going to do.  Expecting them to generate a charter, use case and requirements in three weeks is a bit extreme, especially given that there are other healthcare standards activities happening that overlap.

Yes, there is a lot of material already supplied.  In fact, I applaud ONC for making them available.  But the volume is overwhelming, and spending some time getting us all on the same page would be very useful.  If you want original ideas, people need time to get acclimated to the work groups and to start participating.  Strawmen are good, but the work group needs to be in a place where they feel comfortable throwing tomatoes (or stones) at them to improve them.

This is really interesting project, but I'm very concerned that we are moving extremely fast, and that syncing up will really cost us later.  The technical work group will clearly need review use cases drafted by the clinical work group before they can cut their teeth on requirements.  Starting too soon on requirements will involve a good bit of rework.

There are a lot of technical decisions that the project team have referred to, but the technical work group hasn't yet bought into the publish-subscribe model.  It may in fact be the right model, but without having had the same background as the project team, they aren't ready to agree to that.  In fact, two points made in the kick-off meeting are that the summer concert projects described are mostly supported by organizations with healthy IT resources, and that publish-subscribe would seem to require more infrastructure.  It may well be for large IT, publish-subscribe is the right model, but for other smaller provider organizations, a different model is better.  It really is to early to tell.

ONC has used the phrase Do-ocracy so many times (perhaps even overused).  They've also talked about the fact that these efforts are designed to support participation by the "little guy".  The real challenge of deadlines like this is that the volunteer expertise is already out there "doing"; keeping businesses, healthcare IT projects, and healthcare in general going.   Unless you are backed by an organization with the resources to commit to several hours of calls and activities, it's very difficult to DO at this pace.

One thing that I am very glad about is that the work groups will be able to take advantage of face to face time early in the project.  There will be an SI Framework face to face meeting mid-October.  That kind of meeting does quite a bit to help work groups get through the forming and storming process.  The effectiveness of the TOC Work groups after the last face to face increased greatly after it occurred.

For the Next HL7 Ballot

Balloting HL7 Documents is always a challenge.  The CDA Consolidation Guide is 356 pages.  I made over 125 comments.  The easiest way to make comments for me is to make them inline in the document.  The easiest way to keep track of comments and manage them is to use a spreadsheet.  Transferring data from the document to the spreadsheet is really tedious and time consuming.

When I started on the CDA Consolidation guide this morning, I knew I was in trouble (I had intended to start over the weekend -- but it was a holiday weekend, and my family won out).  So this morning, I spend a few precious hours writing a Word Macro (the Lord only knows what I would have done had I needed to deal with PDF).  It paid off, and I was able to do my review quickly using Word, and then gather the comments in a nearly decent table format, which I could transfer to the spreadsheet.  I could (and did) submit my marked up word document to HL7 (to ensure my comments were registered).  But I knew that if I hadn't submitted them in the spreadsheet format, there would be hell for me to pay later.  So, I built a tool, and used it, and submitted both.

PDF also has tools for revision marking, but unfortunately, I don't know Acrobat well enough to even know if I could gather the revision marks into something nearly as useful.  I can also use this Word Macro to comment on IHE documents (since I can always find the Word versions of the PDFs).  You can find the macro in the window below, or download it from Google Docs.  It may not help you this ballot cycle, but it could be very useful in future ballot cycles for you.  I expect to get a lot of mileage out of it.



Code fixes are welcome.  There are still a couple of things that don't work:

1. It doesn't grab the heading number correctly, I had to fix that manually.  It worked during design-time testing, but not when I really needed it.
2. It doesn't grab the page number.  This too worked at one point, but I don't know why it isn't anymore.  I ignored this problem for now.
3. Comments spanning multiple lines should replace paragraph breaks (in both the commment and the text it spans) with a special character so that the table rows don't get messed up.  I fixed that with global search and replace manually.
4. Some things are slow and could use speeding up.  I used very simple algorithms.  Linear search, bubble sort, et cetera.  Simple was good to get it working, but when I had more than 100 comments, I found I had to make at least two optimizations to the linear search algorithm to make it run acceptably (less than 10 minutes).

One of the things we need to look at as we develop tools to create ballot content is to also ensure that we have good tools to support commenting on it.  If we have great tools to generate content, but lousy support for comments, we'll have a problem generating good content, because it will be hard for people to comment on issues.  This is one thing that some folks in the OpenEHR space understand really well.  Some folks over there have created some excellent tools for collaborative review of archetypes.  It's something that HL7 can learn from.

Learning Series on HIE Leadership: Rochester RHIO and THINC

Another one...

---

Learning Series on HIE Leadership: Rochester RHIO and THINC The Office of the National Coordinator for Health Information Technology (ONC) is a cooperative agreement partner of the National eHealth Collaborative (NeHC). On Wednesday, September 7, 2011 at 1 p.m. ET, National eHealth Collaborative's NeHC University will kick off its Fall 2011 semester with the first class in the Spotlight Learning Series on HIE Leadership and Sustainability. NeHC University will host the Executive Directors from Rochester Regional Health Information Organization (RHIO) and Taconic Health Information Network and Community (THINC) to discuss their organizations' backgrounds, business models, critical success factors, key challenges, connectivity strategies, value propositions and impact in their communities, and future outlook. Leaders will also discuss how they are positioning their organizations to be successful in an environment requiring increased accountability, their strategies for consumer engagement, and how they have designed their business models to help ensure long-term sustainability.  We invite you to join NeHC for the first installment in this free webinar series. Register today!   Check out the full Fall 2011 NeHC University semester schedule! Questions? Email NeHC University.