Working with the best and the brightest

One of the joys of my job, and also its biggest challenge, is that I truly do get to work with the best and the brightest Health IT experts in the world.

I spend a good bit of time traveling to standards events, at least some part of two weeks every month on average.  This is a huge investment by my employer, and I recognize it.  Many others that I know don't travel quite as much, but the investment is still pretty significant, especially for those sole proprietors of their own consulting businesses.  Attending an HL7 working group meeting in the US can range from $1.5K - $3.5K for the week, depending on venue, distance traveled (inside the US), and add-ons (e.g. training and certification), and an IHE event can range from $800 to $2.5K for an individual participant, again depending on venue, distance traveled, and add-ons (e.g., Connectathon conference). I've attended an HL7 meeting on my own dime, it's not something I'm likely to do often, especially since I don't have my own consultancy to fund it.  For participants coming from abroad, it's even more expensive, and I truly admire the ones who manage to fund themselves.

Having said that, one of the results is that the people who DO attend these meetings are the best and the brightest. They are present at those events because their employers believe in them strongly enough to fund their participation, or they are successful enough in their own business to fund it. The cream naturally rises to the top here, and so when you find yourself in a room filled with 50 or 500 people working towards the same goal, it turns out that these are also the best 50 or 500 you could ask to be present.

With that kind of expertise present, things tend to work just a bit differently than they do back in the everyday world.  There's certainly plenty of ego to go around (although some of it exhibits itself in a very id-like manner), and academic games of dominance certainly take place.  But I don't want to focus on the dysfunctional side really, other than to acknowledge it exists.  What is so much better are the opportunities for much better relationships.  In the world of business, I've had one or two mentors, and been a mentor once or maybe twice.  In the world of standards, that's happened to me so much more frequently.  Most people are fortunate to have one or two mentors in their life, but in standards, this is an environment that is simply ripe for developing those sorts of relationships.  You could have two or more mentors in the same organization at the same time, even.  I know I have.  Imagine that!

Attending one of these meetings for the first time is like drinking from a fire hose, especially if you haven't been involved in activities before attending.  It's not for the shy and retiring, but you need not be a raging extrovert either (in fact, I'm simply a well-trained Introvert myself).  The volume and quality of information you'll be getting is huge and valuable.

Managing a group like this (e.g., as a workgroup or committee co-chair) requires a set of skills that is often quite different from your usual work-a-day stuff.

When I get back from IHE and/or HL7 meetings, I find myself both invigorated and exhausted.  Invigorated by new ideas, exhausted by the pace, and excited all over again about what I do for a living.

You are truly, the best and the brightest.  Thank you.

IHE Call for Proposals begins

Crossed my desk this morning...

---

Greetings IHE Community and Industry Partners,

It is with great pleasure we announce the IHE annual planning cycle has begun! The IT Infrastructure (ITI), Patient Care Coordination (PCC) and Quality Research and Public Health (QRPH) Domains are soliciting work item proposals for the 2013-2014 Publication Cycle. The Call for Proposals opens July 29 and concludes September 29, 2013 Interested parties are invited to submit a brief proposal (form attached) for new IHE Profiles and/or White Papers to be considered for development in the new Publication Cycle. 

This e-mail describes the annual planning cycle process from August – December 2013. Please continue reading for more details or visit the IHE Wiki for more information.  For any additional support surrounding the proposal process, please contact Nancy Ramirez, IHE Coordinator, at nramirez@himss.org.

Help Promote IHE Call for Proposals:

All IHE members and industry partners are invited share this announcement with their committee mailing lists and other interested parties. Additional information is maintained on the IHE Wiki.

All Proposals must follow the structure and format of the attached Brief IHE Proposal Template, specifically addressing the following:

1. What is the problem you propose to solve by this proposal, and how is that problem expressed in practice (e.g., a use case)?
2. How would fixing this problem improve health care in practice?
3. What specific components of standards could be used to solve this problem?
4. Your proposal should identify one or more potential editor(s) in the event that the proposal is selected for further evaluation and possible development. If possible, please include some indication of the business and/or clinical case surrounding the situation when describing the problem. For example, is there an economic motivation for addressing this problem immediately?

---

Summary of IHE’s Multi-Phase Proposal Process:

1. Submit Brief Proposals by September 29, 2013

·         QRPH, PCC and ITI Domain’s Call for Proposals Open July 29, 2013 and close on September 29, 2013.

·         Submit a Brief Proposal using the attached form to the domain email listed below.

·         If your proposal is accepted you will be required to attend IHE’s regular teleconferences and meetings where membership is required. Apply for IHE International’s free Organizational Membership today!

2. Planning Committee’s Proposal Review Webinars- Decision Meetings:

Save the Date! Webinars are held during the weeks of September 30, 2013 and October 7, 2013 on WebEx. 

·         All Proposal authors are required to present a 15 min. summary of their Brief Proposal on one of these Webinars.

·         Exact dates for each domain will be announced in August 2013. Join the committee newsgroups to receive regular updates. See links at end of the announcement.

·         Please anticipate participating on 1-2 webinars. These Webinars will be decision meetings, join IHE to exercise your IHE voting privileges!

3. 2013-2014 Planning Proposal Evaluation Kickoff:

Save the Date! October 9-10, 2013 in Oak Brook, IL.* Click here for more details.

·         We urge those who submit proposals or white papers to attend the Planning Proposal Evaluation Kickoff Meeting in person or phone. In-person advocacy has proven to be the most effective way to ensure your brief proposal are understood and accepted by the committee. 

4. 2013-2014 Technical Committee Proposal Evaluation Meeting:

Save the Date! November 12-13, 2013 in Oak Brook, IL.* Click here for more details.

·         Proposals that are accepted at the Planning Proposal Evaluation Kickoff Meeting and given to the IHE Technical Committee for review are required to write and present a detailed proposal during the Technical Proposal Evaluation Meeting.

**Deadline: September 29, 2013 at 11:59 pm CDT**

Email the completed brief IHE Proposal template to the corresponding domain email address below before September 29, 2013 at 11:59pm CDT.

Committee	Domain Email	Planning Co-Chair 1	Planning Co-Chair 2
PCC Planning Committee	pcc@ihe.net	Laura Heermann-Langford	Tone Southerland
ITI Planning Committee	iti@ihe.net	Eric Heflin	Karen Witting
QRPH Planning Committee	qrph@ihe.net	Didi Davis	Landen Bain

We look forward to working with you during the IHE 2013-2014 Publication Cycle. Please contact the IHE secretary at ihe@himss.org if you have any additional questions or need further assistance.

Apply for IHE International’s free Organizational Membership today! If your proposal is accepted you will be required to attend IHE’s regular teleconferences and meetings where membership is required.

Join the IHE Google Groups and stay informed on the 2014 Call for Proposals process!

·         IT Infrastructure (ITI) Domain Google Group: https://groups.google.com/d/forum/itiplan

·         Patient Care Coordination (PCC) Domain Google Group: https://groups.google.com/d/forum/pccplan

·         Quality Research & Public Health(QRPH) Domain Google Group:https://groups.google.com/d/forum/iheqrphplan

If you have any additional questions please contact Nancy Ramirez, IHE Coordinator, at nramirez@himss.org,  or the Domain Planning Co-Chairs listed above.

Thank you,
IHE Quality Research & Public Health, Patient Care Coordination and IT Infrastructure Planning Committee Co-Chairs

Lessons from a Collaboration

Charles Jaffe, CEO of HL7, writes a periodic news brief, which goes out to all HL7 members. He discusses his viewpoint of the the recent HL7 and IHE Collaboration in the following, which appears below with his permission.

-- Keith

---

Integrating the Healthcare Enterprise (IHE) and HL7 have worked together (and apart) trying to make interoperability a reality. At the best of times, we’re partners, working to solve the same equation. To some observers, we go about it very differently. But, partners we are and we have proven it time and again. The collaboration on Consolidated-CDA® was a tribute to the willingness of idealists to put aside process difference and achieve a critical goal.

Last year, the Board of IHE agreed, in principle, to venture well beyond the road less traveled. This spring, after a year of negotiation, HL7 and IHE began a pilot to ballot IHE artifacts with the HL7 consensus process. Purists on both sides of the table shouted foul. Fortunately, the potential benefits to each organization were too great to ignore.

To date, the results are mixed. After all, it’s difficult. The participants from IHE know the outcome they want, but learning the process is not easy. Some of the more patient souls from the HL7 are doing a lot of hand-holding. The most important part is that it’s being accomplished…warts and all.

After the initial pilot, there will be a careful post-mortem about the best and the worst of this partnership. It was a challenge to IHE loyalists to take the first step toward reconciling processes. There have been moments of rancor and disbelief and times of great sensitivity and caring, characteristics of an honest and productive relationship. Almost certainly, we will move forward with another ballot on a far more challenging problem. It’s critical that we succeed. The healthcare IT world is depending on us to develop standards by a process that compresses our typical timeline and enhances their quality.

Charles Jaffe, MD, PhD CEO, Health Level Seven® International

For Once and for All

I think I've finally discovered how to explain the difference between functional requirements of a system and requirements of an instance of data produced by that system.  The distinction is based on the different between the logical qualifiers ∀ and ∃.  Given that we (IHE, HL7 and others), express requirements on content of the document (or message);

To express a constraint that is true for all instances of every document,
 ∀ documents: X shall/should/may Y.

And to express a constraint that must be true for at least one instance of a document,
 ∃ document: X shall/should/may Y.

This is fairly clear to engineers who have not been trained in "standards terminology" such as the distinctions between mandatory and required.  For a document X and data element Y: To say that Y is mandatory in X is the same as saying: ∀ documents X: X SHALL contain Y.  To say that Y is required in X is the same as saying ∃ document X: X SHALL contain Y.  To test the system for the first case, you must verify that Y is present in all cases.  To test the system for the second, you must verify that Y is present in at least one case.

In both cases, the system MUST be able to produce Y, the distinction is whether is must do so all the time, or just some of the time.

If I'm right, then I've managed to explain it for once ∃ and for all ∀. [ouch]

   Keith

What does BlueButtonPlus / FHIR provide that CCDA doesn't have?

I joined the NwHIN Power Team last week.  I was asked likely due to my experiences with Blue Button Plus Pull and HL7 FHIR.  Today on a join call with the Privacy and Security workgroup, the question came up about what FHIR and/or BB+ provides that isn't available with C-CDA.  I always struggle here because I'm involved in the SDO activities, and get this.  Yet many C-levels who are reviewing the work of these groups are don't yet. The communications from one to the other is always a challenge.  SDOs typically don't spend whole lot in targeted marketing to the C-suite on their work, and this is especially true during the development time frame.  I'll try to approach the question from a C-level perspective:

Let's start with this qualification: FHIR and Blue Button Plus are related but not identical initiatives.  The former is an HL7 International standards effort.  The latter is a US initiative that is using parts of FHIR to enable consumer access to clinical data.

What is different with BlueButtonPlus / FHIR from what I'm doing today?
What Blue Button Plus (pull) provides is access to a  FHIR-based resource by which you can query for CCDA documents in a RESTful manner, and subsequently download them.  It doesn't ask you to aggregate your content differently, or use some new format to describe problems, medications and allergies.  So, content is structured the same, but metadata is structured and queried RESTfully.

The mechanism by which access is granted via BB+ Pull makes use of OAuth 2.0, which is the same thing that FaceBook, Twitter, Linked In, and other services on the web enable other applications to access your data stored in those services.

Why is BlueButtonPlus / FHIR good?
This is good because it vastly simplifies the way that consumer applications can access health data, making it possible for smart phones, tablets, wearable devices, et cetera, to participate in consumer data access and use of healthcare data.  It also prepares sources of consumer data to move towards an architecture that can support more granular access in the future (but doesn't require it today).

Does Blue Button Plus / FHIR eliminate the need for CCDA?
Blue Button Plus is not eliminating CCDA, but rather building from the use of it.  Blue Button Plus REQUIRES the use of CCDA.

You've probably heard about "Green CDA" and I've said in the past that FHIR is to HL7 V3 what Green CDA is to CDA.  FHIR greens HL7 Version 3, and so EVENTUALLY, there will be a new Document resource in FHIR that is a composite of clinical resources (like problems, allergies, medications, lab results, et cetera).  But we (HL7 Structured Documents) aren't working on that right now.  Eventually this will occur, and those resources will be key components of it.

How is Blue Button Plus / FHIR retaining compatibility with CCDA?  
CCDA and Green CDA and content from similar efforts are being used to help define FHIR resources.  The document resource enables access to "FHIR-based" documents as well as those that existed prior to the development of FHIR (like CCD or CCDA documents).  Present efforts in Blue Button Plus focus on the latter.

When the stars align

I don't know what to say.  I've just been one a whirlwind tour of the globe, and not quite back again.  All the stars seem to be aligned, and everything is going my way.

My IHE profile work on CDA Harmonization is getting closer to being done, and will go out for a second round of public comment.  The data driven content was generated just in time for the IHE meetings in Oak Brook, and I'm quite happy with where it is at.  I've got a ton of editing to do, but it's mostly just that, editing. All of my outstanding questions have been addressed, and I'm no longer struggling with how I'm going to do it, now I just have to finish it.

I just had an outstanding HL7 board meeting.

I was invited to join the NwHIN Power Team today.

I just heard back on a book chapter, and it looks like I'll be given the time I need to finish that.

I've got an opportunity to reuse CDA Book and blog content that may work to my advantage.

I heard from my new advisor that my admission was approved to enter a master's program in Medical Informatics.  It's a part time, remote program that I can do while I remain employed doing what I love.  That ends a three-year search and I look forward to starting that in the fall.

The ABBI work I've been doing is getting the attention in the right places.

That's about it.  I need to go find some wood to knock on.

Growing Pains

I think the September Working Group Meeting is when I'll have a new ribbon on my HL7 badge.  I joined HL7 as an individual member either late summer or early fall in 2003, and became an organizational member later that year.  That means I'll get to wear the 10-year member badge if they are still using those.  I guess that makes me an HL7 old-timer, although I must say, that I still feel quite young.  HL7 has a few 30-year members, which still makes me feel like the baby in the room.

Even so, I've been through a lot of HL7's history.  When I joined, HL7 was considering how to become a more international organization.  I seem to recall they even had a grant to work on that, I think it was from RWJF. One of the outcomes from that effort was a board decision to have one working group meeting every other year in an international setting.  Up until that time, all working group meetings for the 19 years prior had been held on the North American continent if my understanding is correct.

In 2005 I worked on my first HL7 specification, called the Care Record Summary (CRS).  It was clear at that time that HL7 V3 was troubled and delayed.  Ballots were taking forever to pass and we needed to clean up that process. The CRS was conceived of in February, launched in March 3, and went out for ballot in the beginning of April. I spent most of March working on, and writing the text of that document, with a copy of another specification sitting open beside me to use as a model.  That was the e-Medical Summary created by Vancouver Island Health Authority, that they had freely shared with HL7 members.  Schematron became the way of doing things because I learned it first from there.

The CRS has now been superseded thrice in HL7, once by CCD, a second time by CRS Release 2, and most recently by C-CDA. However, the CRS is one of the intellectual ancestors of the C-CDA, and for that I am quite proud.  It took almost another year to get the CRS ballot approved.  We went for three more ballots, and had a bit of a bother with ASTM over alleged IP misappropiration.  I may never get over that accusation, but while I freely admit reusing ideas from eMS (with permission), and harmonization (before we called it that) in CRS of Claims Attachments with the then notional sections of CCR, there was no "theft".  But perhaps few believed that someone in HL7 could write a hundred page specification and have it ready for ballot in a month without copying from somewhere, given it's challenges with V3 at the time. It used to be that it could take years to get something through committee.  Today, a project that takes longer than 18 months is the exception rather than the rule.

In May of 2005, my wife and two children joined me in the Netherlands for the first European Working group meeting, where we reviewed that ballot.  Not only was that HL7's first experience off the North American continent it was also my first and my children's.  My wife and children had a blast on that trip, and we've tried to do something international every few years since.  CRS was the first step in a two step collaboration with IHE on what became XDS-MS, and I wrote that specification in short order as well.  The first edition of XDS-MS was produced for Trial Implementation in August, having started sometime in July, also quite a record.

In 2006, HL7 held its 20th annual plenary meeting, and the organization was still changing.   In the January WGM I'd been handing out resumes to a few select folk. At the May WGM I was gainfully unemployed but starting my new job doing standards full time the week after.  It was fun being the last person in the Claims Attachments workgroup, standing up, identifying myself, and indicating a complete lack of affiliation with any company.

That was the year I'd finally put CRS to bed, became a cochair in Structured Documents, and later kicked off the Continuity of Care Document later.  It took most of that year for HL7 and ASTM to bury the virtual hatchet.  Over the next year, the two organizations worked together to produce what is now the most widely implemented CDA Implementation Guide in the world.  And at the same time IHE PCC and HL7 did their second collaboration, which resulted in the development of XPHR.  And the Bush-era ONC was born.  Back then, they had the short-lived acronym ONCHIT (say it with a soft CH and you'll understand why).

The CCD finished in January of 2007, HITSP adopted it shortly thereafter, and IHE had to play quite a bit of catch-up on use of the CCD standard in the C32. Oh, and I had to rewrite XDS-MS to support CCD now instead of CRS.  HL7 standards had taken on several of the lead roles in the US National program.

At the same time as HL7, ASTM, IHE and HITSP were all working together on what would eventually become the C32, I participated in another collaboration with IHE, HL7 and HITSP on the XD-LAB specification.  The former was chaotic, filled with personalities, and quite hectic.  The latter was chaotic, filled with personalities, and also quite hectic, but fortunately I wasn't leading that charge, so I think I remember it more fondly.  In the XD-LAB work, I recall having a T-Con with Francois Macary (located in France), the HL7 O&O Workgroup, and I think we listened to it in a hotel in Washington DC while at HITSP meeting.  Now that was a collaboration.  We would follow each other from one organizational meeting to the next polishing off the next chunk of the XD-LAB specification.  I think I was the only person who was involved as a member of all three contributing organizations.  It was a grand collaboration, and I recall how impressed I was with HL7 O&O for being so open to it.

As April 2007 rolled around, I found myself in Germany, in the City of Cologne, at HL7's second international WGM.  The international meetings piled on after that, as HL7 moved into an every year plan. There was Vancouver (2008), then Kyoto (2009) and Brazil (2010).  HL7 truly had become much more international in flavor.

Along the way, the balloting process got much cleaned up, and the HL7 Governance process changed, new intermediate steering divisions were formed, and the TSC took on a much more aggressive role in organizational governance.  At the same time, ballots got a lot shorter.  Instead of taking three years or more, we were averaging less than 2, and there were some special cases where work was run through the process in 6 months.

Brazil was my first international meeting as a member of the HL7 Board, and I was about to learn what little progress we had made on the business planning we had made since the original grant back when I started.  I joined the Internationalization Workgroup, and then moved on to the new business planning workgroup as a member the board.

Through two years of effort on the board, we wavered from one extreme to another, first considering the IHTSDO model of selling HL7 to national governments as a way of supporting the organization (starting with the US), and subsequently thinking about alternative structures.  Somewhere in the just past middle of all that (in the summer of 2012), we realized that to remain competitive in both the US and international markets, HL7 standards would have to become free for non-members to implement.  Now business restructuring was critical.  With IP not being the dominant reason to join HL7, the board was now in a position where we needed to put up or shut up.  We needed to deliver new value to members, or could expect the membership growth we had been experiencing as a result of organizations needing to acquire access to the CCD specifications as a result of Meaningful Use to dry up.

Here we are a year later, and tonight I got to retweet the following tweet from HL7:

Today the #HL7 Board approved new membership benefits to be announced at the September Plenary meeting. More details to follow. #HealthIT

We've been working on this since September of last year.  I won't steal @HL7's thunder by telling you the details of the new benefits, but what I can say is that they do create more value for existing members.  And they provide a reason for new members to join the organization.  There are a number of new programs we'll be piloting or initiating as part of this benefit package, and we'll be working hot and heavy to roll many of those out in time for the 27th September Plenary.  Keep your eyes on @HL7 in the coming weeks to learn a bit about what's in the package, and join me and the HL7 leadership at the Wednesday morning business meeting of the working group to learn the full details.

It's been a long haul from my first HL7 activity to today, and I expect I still have many more miles to go.  But I think HL7's going to be headed for a better future.  We aren't all grown up yet, but we've certainly made quite a bit of progress in the last two years.  There are still issues to address (e.g., one member one vote, a US Affiliate, and still more challenges to come), but I think we have the will to pursue these.

IHE 2013/2014 Publication Cycle Calendar

Crossed my stream not too long ago. Check out the new IHE logo as well -- feels sort of Star Treky.

Keith

---

IHE Int’l Planning & Technical Meetings

IHE Development Cycle – October 2013 to July 2014

IHE Domains: IT Infrastructure (ITI), Patient Care Coordination (PCC), Quality Research & Public Health (QRPH)

Visit the HIMSS Sponsored Meetings wiki page for the full list of meetings for the 2013-2014 Publication Cycle. Please note the PCC & QRPH may hold four-day Technical Committee meetings, based on workload. For final agenda please refer to your specific domain IHE wiki page.

Unless otherwise specified, all meetings will be held at the RSNA office located in Oakbrook, IL. Please visit our IHE Wiki Page for further details.

2013

Planning Profile Evaluation Kickoff – Planning Meeting

v  Tuesday & Wednesday, October 9 -10, 2013

v  ITI, PCC, & QRPH will be meeting during the same dates.

v  Location: RSNA Headquarters

Meetings will be held early on Wed. October 31, 2012 so members can leave early.

New Location for Technical Profile Evaluation Meeting

v  Tuesday & Wednesday, November 12 -13, 2013

v  ITI, PCC, & QRPH will be meeting during the same dates.

2014

IHE North American Connectathon 2014

v  Monday – Friday, January 27 – Friday, January 31, 2013

v  Location: Hyatt Regency, Chicago, IL

v  For more information visit www.iheusa.org.

Volume One Finalization Meeting  - Location TBD

v  Monday – Friday, February 10 – 14, 2014

v  ITI, PCC, & QRPH will be meeting during the same dates.

Preparations for Public Comment and Issuance Meeting

v  Monday – Friday, April 28 - May 2, 2014

v  ITI, PCC, & QRPH will be meeting during the same dates.

v  Location: RSNA Headquarters

Preparation for Trial Implementation and Issuance Meeting

v  Monday – Friday, July 21-25, 2014

v  ITI, PCC & QRPH, will be meeting during the same dates.

v  Location: RSNA Headquarters

Bring on the Accessories

We are all fairly familiar with products that are designed for use with other products.  My favorite iPad accessory most recently was a car we rented while I was on vacation in England.  Essentially, the iPad recognized the car as an accessory iPod appliance that would allow me to play music through the radio, and could also integrate (if I used my iPhone) with the car's hands-free system.

In fact, sometimes it is the existence of the these accessories that makes us want the original product that it works with.

It's another IHE week in Oak Brook, and we are talking about CDA templates quite a bit, as we usually do in PCC Committee meetings.  At one particular point, one of the committee members, and I can't remember who, but I have a few suspicions, made the point that we should start thinking about designing templates to fit into different places, e.g., the accessories that go with the original system.  The idea was that this disconnected the document, or section or whatever you were creating the template to fit into from every having to know about the template in the first place.

This evolves into a comment I expect to make in the future HL7 templates ballot on metadata necessary for a template to support this kind of adaptation.  Because in many cases, a template should tell you where it works best, rather than the thing that might actually benefit from its existence.

I repeatedly get requests from friends and standards colleagues about this group or that group not making templates that support "our requirements", and looking for my assistance in bringing those requirements up.  But that isn't my specialty, or my need, and while I'm willing to consider these requests, I do have to focus on where the demand is.  Consider:  Would you complain to mega-corp about your special niche need not being supported in their latest and greatest iThingyMaBob   Or would you instead work on your own cool accessory that worked with the iThingyMaBob's published interface or developer kit, and made it able to support your niche's accessory?  If the iThingyMaBob is so cool, go for it, build your accessory, and if the world needs it, why you already work with it in the most popular ThingyMaBob out there, all they need to do is acquire your accessory.

This goes back in some ways to the discussion earlier this year about Context Sensitive Templates.  The key piece here is that your "accessory template" is adding features to an existing template (or collection of templates), to support some context sensitive behavior.  Designed well, this can be very powerful, and is reminiscent of the Decorator design pattern.

Done well, your template can provide capabilities such as employment/work history, or support for dietary specialties, as a couple of examples.  This would work for any niche for which you could probably create demand for an accessory, but not for an entire niche focused product.  After all, who would buy a combination phone/EKG device?  A rather small market, and propably not one who would do phones all that well, but they might make a great EKG. So, leave the phones to the folks that want to build em, and bring on the accessories.

And so my comment on template metadata is to ensure that in it there is a way for templates to communicate how they can connect, and to declare the ways in which they do so, so that the accessories aren't just useful, but decorative as well.

Such That

One of the challenges with the C-CDA specifications is in understanding a particular kind of constraint.  The general form of this constraint is described in the title of this post.

Here's an example from the specification:

3. SHALL contain exactly one [1..1] templateId (CONF:5252) such that it
    a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).

There are 344 occurrences of the phrase "such that it".

Think of the "such that it part" part as a where clause:

SELECT templateId from ClinicalDocument 
WHERE (@root='2.16.840.1.113883.10.20.22.1.1')

The cardinality constraint applies to the templateId values after matching the WHERE clause.

This constraint above (and many more) could have been simplified into:
3. SHALL contain exactly one [1..1] templateId where @root = "2.16.840.1.113883.10.20.22.1.1"
Or
3. SHALL contain exactly one [1..1] templateId/@root = "2.16.840.1.113883.10.20.22.1.1"
Or even
3. SHALL contain exactly one [1..1] templateId[@root = "2.16.840.1.113883.10.20.22.1.1"]

In fact, I prefer the last one because [] effectively gives you a WHERE predicate in XPath.

But this doesn't work when there are multiple constraints, and you want to separately indicate which identify each constraint.  See for example the general participant which I slightly simplified below (there's another constraint at 5.c.i. which I omitted):

5. MAY contain zero or more [0..*] participant (CONF:8504) such that it
    a. SHALL contain exactly one [1..1] @typeCode="IND" Individual (CodeSystem: HL7ParticipationType 2.16.840.1.113883.5.90) (CONF:8505).
    b. SHALL contain exactly one [1..1] functionCode/@code="PCP" Primary Care Physician (CodeSystem: participationFunction 2.16.840.1.113883.5.88) (CONF:8506).
    c. SHALL contain exactly one [1..1] associatedEntity/@classCode="PROV" Provider (CodeSystem: HL7ParticipationType 2.16.840.1.113883.5.90) (CONF:8507).

Which would be restated in one line as:
5. MAY contain zero or more [0..*] participant (CONF:8504) WHERE @typeCode="IND" AND functionCode/@code="PCP" AND associatedEntity/@classCode="PROV"
(or in preferred form)
MAY contain zero or more [0..*] participant[@typeCode="IND" and functionCode/@code="PCP" and associatedEntity/@classCode="PROV"]

See the problem?  We have all these constraints around how to express the value of the different coded pieces.  Each one of these is wanting a separate constraint to hang the coding system on, and the value set, et cetera, at least at the modeling level, and more likely at the validation level as well.  A validator that can tell you that you have failed to meet CONF:8506 in the former is much more informative about what you need to do than one that simply tells you that you failed to meeting at least one of the AND criteria in the clauses attached to CONF:8504 in the latter.

There's probably a better way to state these, and it also seems likely that they are overused.  That's the problem when you develop methodology at the same time as you try to use it.  However, in my own experience, there's really no better way to develop methods than to use them at the same time.

So, hopefully you now understand what that construct means, and why it is used, and also understand, if we can fix it, we likely will in the next round of work on Consolidated CDA.  It will certainly be one of my ballot comments if we don't.

   Keith

P.S.  England was fantastic, even if I almost had heart failure more than a dozen times sitting in the passenger seat while watching my wife drive.  I know I would have blown my top if I'd have had to listen to me (or anyone else) while I drove under those conditions.  She's a sweetheart, and so she did all the driving.

Can I ask You a MeaningfulUse Question on CDS and Imaging?

This question came in via Ask me a Question. Since 1) I'm on vacation and 2) I've little experience with Radiology workflows, I thought I'd see what crowd sourcing can do to get an answer.  Here is the question:

---

Hi Keith 

I was wondering if you had any thoughts how a vendor for a Radiology Information System program would implement clinical decision support for MU Stage 2. It seems like the MU CDS rules are geared more towards providers, in that it helps them decide on a course of action depending on a list of variables. However, when a patient arrives in a radiology department the decisions have already been made by the provider. There's not much else anyone in the radiology department can do. To make things even more difficult, the ONC's testing criteria "Test Procedure for §170.314(a)(8) Clinical decision support" states over and over that each CDS intervention be automatic and based on the patient's problem, medication, medication allergy, demographics, labs, and vitals. Like I said, all of those variables have already been sorted out by the time a patient has arrived in the radiology department, so do you have any thoughts on how a radiologist can incorporate CDS?

---

I have to agree that the rules are more geared towards traditional providers.  I also seem to remember a few cases where there were exceptions available when a provider did not directly interact with a patient, but I don't believe that was addressed in CDS.  And while I could look it up, I'm on vacation ;-)

So let me see what you can do to help this reader.  Please respond in comments below.

Chaos vs. Order

I had a couple of interesting (in the not-so fun sense) experiences with various airline challenges.  In one location, where I expected chaos because chaos was part of the routine, what I found was that even though chaos "ruled", they still manage to get everyone on the plane.  Yet, in another place, where order was the rule of the day with one irregularity, a passenger wound up missing her flight.  How is it that in changing gates twice for one plane, and at least once for two others, one airport still manages to get every one off in the middle of a national holiday, another, having to deal with one irregularity still manages to cost a passenger extra trouble.

My wife observes that practice makes perfect, and where chaos reigns, the challenge is not deciding what to do, so much as it is figuring out how to get it done, and they have practice in figuring things out.  Whereas elsewhere, what is practiced is a process, which may be completely unflawed, but as soon as you step outside the process, utter chaos rules, because those that are bound completely to process haven't the experience in "figuring it out".

Somewhere there is a middle road, but I've never seen anyone make a big deal about it.  It is perhaps, uninteresting, because on that road, neither chaos nor order reigns (or rains).

If you had the chance to do it all again...

... how would you design a national healthcare system?

How would it be paid for?

What would the various roles of the various stakeholders be?  Ignore traditional healthcare titles and borders for the most part (e.g., doctor, nurse, hospital, clinic, payer, pharmacy, et cetera), but include the other members of society (governments, employers, people).

Who would be the professional members engaged in healthcare delivery?  What other roles would they also have?

How would services and supplies and equipment be developed and distributed?

Who would be in charge of its governance?

Think really big, and really long and hard.  Be very creative.  Ignore existing limits and boundaries.

Work through a few scenarios, including routing care, emergency care, catastrophic illness, normal illness, health and wellness, all the rest.  What does it look like.  Change it around until you think you like it.

NOW.  How would we get there?  What are the steps?

OK, you have the next 10, 20, 30 ... 50 years.  Don't tell me your plan.  Just do it.

Is your Doctor good at their Job?

It started with a simple tweet, as some of my better posts topics do:

Sitting at son's urologist, filling out medical history. Really? This #healthdata exists already. #ehr & #hie won't solve this. #hitsm
— CLOUDHealth™ (@CLOUDHealth) July 5, 2013

If you read through the whole thread, you'll understand the title of this post.

Here's the point.  Until patients judge healthcare providers by the non-medical things they do, most providers will just continue to give us the same kinds of service they always have.  Paper forms, crazy bills that we can't understand, lousy communications, et cetera.

We put up with those things because the providers are "good at their job."  But are they really?  Isn't customer service part of their job?  We all complain in one breath about how the system needs to change, but how many of us have ever changed doctors because we couldn't get our data easily?  There are providers that have the capability and use it, and there are many others that don't, and there are some, like my own, who are working on it, but still aren't there yet.

How do we make physicians understand that making our data available to us is a critical part of their job?  The easy answer is to pick physicians and hospitals that do.  But that is not so easy now is it.  Do you really want to give up the doctor that you have a 20-year relationship with?  I know I don't.  Do you even have those choices?  I do to some degree because of where I live, but not everyone else does.

One of the intentions behind Blue Button+ is to change that.  But making technology available is only the first step.  And while @CLOUDHealth and I might argue about the shape that technology takes, I don't think he'll argue that it takes more than the availability of appropriate technology to change society.  It has to be used.

In the The Forever Hero Series, L.E. Modessitt's main character Gerswin discovers that it isn't just the development of appropriate technology that is necessary, it has to be used by, and demanded by the common man before change can occur.  The BestMeat plant that his institute funds the development of fails to change society until Gerswin starts sharing the fruits of that plant with others.  This is where S&I Framework stands today.  We have developed some of the appropriate technology, but we need to get the word out, and create the demand for it.

That is one of the key messages from the Patient Access Summit II.  As I summarized it: More needs to be done to raise awareness among patients, providers and health IT vendors about patient rights and technology available to access data, and Blue Button Plus alignment with Meaningful Use incentive programs.

But of course, if we expect ONC to make that change happen, we'll still be waiting for it.  The government is not well known for their marketing prowess.  I'm a patient and a technologist, not a marketer. I don't know how to do this, or what it would cost to get the word out.  But I know that's the next step.  I think we need to spin up a simple yet viral marketing campaign to make patients aware that a) they have a right to their data, and b) they should ask for it.

I can teach that to an eight-year-old, why is it so hard with adults?

Deduplicating Lists in XSLT

I'm in Saudi Arabia for a couple of days before I head off to a 10-day vacation in England with my family.  I'm not sure how much I'll be writing on my vacation, we'll see how it goes.

I have a few projects to finish up before I get to take some well-deserved time off.  In one of those projects I needed to generate a set of lab results, ordered by the date and type of test performed.  However, the XML I was presented with was not normalized in a way that would make that easy.  Instead of each result being organized into separate panels with the panel reflecting the test performed (a complete blood count), with each result in the panel, it was instead organized into a table where each result included the panel, the result and the date performed.

That can be pretty challenging to handle in XSLT.  What I wanted to do was loop over each separate panel, which could be identified by the panel type and date performed, and then within that list, iterate over the separate results.  I could do it using the EXSLT set:distinct function, but this was one of those cases where the code I'm writing doesn't allow me to use EXSLT.  I suppose I could have changed the rules, seeing as how I was the one who made them, but I had gotten pretty far into the code without needing EXSLT and I didn't want to add third party dependencies.

I've done this before, but it always relied on some rather tricky code using the preceding and following axes. I knew there had to be a better way, so I started searching and found the solution. It shows up in the XSLT: Programmer's Reference by Michael Kay, but you have to know where to look for it.

The key as it were, is in the key element and key() functions.  The key element allows you to define an index on a set of elements that you want to find.  It's syntax is:

<xsl:key name="name" match="match pattern" use="key expression">

The name specifies the name of the key and is used later in the key function.  The match pattern provides the list of elements for which you want to generate a key for.  The key expression defines the expression that generates one or more keys in the context of the matched node.

Later, you use the key function, giving it the name of the key that you are looking things up from, and an expression that generates one (or more) keys to locate.  The function returns the list of nodes matching the match pattern that have one or more of the specified keys.

For my example, we'll pretend I had a list of items like this (it was more complex than this, but this is sufficient to show you the technique:

<test test="name" date="date" result="result" value="value"/>

I created a key like the following:
<xsl:key name="myKey" match="test" use="concat(@date,@name)"/>

Thus, each row was indexed by name and date.  

The next step was to select all the test and deduplicate them based on their keys, producing a list of elements with unique key values.  Here is the code that does that:

  <xsl:variable name="tests" select="./test"/>
  <xsl:variable name="distinctTests" 
    select="$tests[generate-id() = 
                   generate-id(key('myKey', concat(@date,@name)]))[1])]"/>


The tests variable defines a list of tests that I want to deduplicate.  The distinctTests variable iterates over each test element in $tests, selecting it if the unique id of the node matches the unique id of the first matching test that has the same key identifier.

One problem with this technique is that it fails when your selection context and your key contexts aren't aligned.  I didn't run into that issue with the problem I was working on.  I'm sure there is a way around it, but I do need to get some sleep.

My HIT100 Picks

I always hated popularity contests in high school.  I was never very popular.  The only teams where I was ever highly sought after was in math, and even there, I always came in second after Michael C, who was even more of a geek that I was.  I also get rather frustrated with most of the Health IT media attention on top N Health IT leaders.  Yes, CEOs and CIOs and CMOs and CMIOs of major healthcare providers are important.  But rarely in those contests does it ever say you need to have "Chief" in your job title, and while I know about the importance of support and leadership and air cover at the C-level, usually their technical understanding of what it takes to make the Health IT projects work that they get credit for is at Sea-level.

I do OK in the HIT100 because for the most part the initial stages really do identify the folk worth watching.  So, I kind of like the contest.  Though once you get past HIT100 into HIT10, HIT5 or HIT1, it becomes not just a popularity contest, but a vote stuffing contest, and I never try to win that.  The recognition might be nice, but it never lasts beyond the end of August. Do you recall who won in 2011 and 2012 (I do, but that's another story, I can't get dumb facts out of my head).

I made it a point this year to nominate people to the HIT100 who I hadn't yet seen a nomination for.  There are a couple of folks working on Blue Button Plus, a couple on FHIR, and a good chunk of my nominees are from outside the US.  Here are a few of my nominees:

John Moehrke (@johnmoehrke): As I told @SusannahFox, when Health IT mixes with privacy and security, John is my go to guy, and his blog is my go to blog.  It helps that I have his mobile on speed dial.

Heather Leslie (@omowizard):  One of the few Aussie's with a Regina Holliday jacket, Heather's blog is to OpenEHR as mine is to CDA.

Ewout Kramer (@ewoutkramer): Ewout is second only in my mind behind Grahame Grieve (who had already been nominated) as one of the leaders of the FHIR-storm that is taking over HL7.  He's building the C# reference implementation of a FHIR Server.

Rene Spronk (@Ringholm): Rene is one of Europe's best sources for information on HL7 CDA, and also a strong promoter of FHIR.  Rene's blog is another good source of information, although he publishes less frequently than I like.

Margalit Gur-Arie (@margalitgurarie):  Thoughtful, insightful and cutting. Margalit's posts are almost always all of the above.  Her twitter presence is almost completely dominated by links to her blog posts, but with that kind of content, little else is necessary.

Eric Poiseau (@ericpoiseau): I can't think of anyone else other than Steve Moore who has contributed as much to the success of IHE Connectathons.  Eric is the brain behind the IHE Connectathon test management tools, and also contributes a great deal to IHE Europe and the IHE Laboratory Domain.

Josh Mandel (@JoshCMandel): A leader in Blue Button+ Pull efforts, and lead architect for SMART.

Nayan Jain (@supernayan): Up and comer, Presidential Fellow and fellow Blue Button+ aficionado, Nayan may be new to our scene, but look out, I expect great things from him.

Thomas Sullivan (@GovHITEditor): I like his stuff.

Hacking HIPAA (@HackingHIPAA): I think this is a great project that deserves more attention.

Six yes, but months or years?

I was conversing with a colleague about scales of change.  He argued that you could not implement X, that it was just impossible to do.  I agreed that nobody would ever be able to solve it in one go, there were simply too many moving parts.  However, I pointed out that there was a way to solve X in stages.

Rather than go into the details of our discussion, let's work with another example more relevant to you:

Is it realistic to believe that a provider would be able to connect his or her system to any other provider in the US, and be able to query that system for patient data, get it back in a semantically interoperable way, and then be able to use it?  Would you like to work on that use case?

I wouldn't.  Not in a one year project, or even a two year project.  This is more like a three to five year effort, and you have to develop it in stages that bring significant value in each stage.  Here is one way to break it down:

1. Agree on an interoperable data format for exchange of data.
2. Agree on a common transport of that same data.
3. Enable some mechanism that allows you to securely identify healthcare providers and find them.
4. Enable individuals to authorize applications they control to access the data that they have a right to access.  To simplify in this step, you might ignore the distinction between proxies for an individual and the individual, treating them as the "same case" for most intents and purposes.
5. Add to the previous step the ability to deal with distinctions, and support also the concept of limited rights.
6. Be able at some point to have an individual give to some other person or organization something that grants them some sort of limited right.
7. Let that other person or organization be another healthcare provider.

These step together will take a lot of time. Let's go back and identify the activities associated with these various stages:

1. CCD and then C-CDA, eventually moving to something better (e.g., FHIR)
2. NwHIN Exchange, NwHIN Direct, ABBI Pull
3. Direct Certificates
4. OAuth 2.0/IHE IUA and HL7 FHIR XDS Entry w/ IHE MHD using CCD/C-CDA
5. More on OAuth 2.0/IUA, possibly with IHE BPPC or HL7 Consent Documents or their successors
6. IHE BPPC or HL7 Consent Documents or successors, possibly including Digital Signatures (e.g., IHE DSG)
7. Done

This isn't a six month process.  It's more like six (or more) years.  But you can see a progression that makes it work, and there is value at each stage to be delivered.  Putting together a program like this isn't something that a bunch of architects and systems engineers and all the rest do all at once.  Instead, it takes years, and progresses from step to step, moving not like a photon transporting light from start to end, but more like electrons, headed randomly, but generally in the same direction, under the influence of an electronic current.

The impact can be great, but you have to allow for the proper staging.  Nobody every planned on using connections originally designed to support teletypes and terminals to handle web traffic, but eventually we got there.  If we had started with the idea that we were going to build the web, we'd probably still be working on it.

Would it be better to try for a laser like approach?  I don't think so.  I cannot think of a single example where that ever worked.