Recapping the IHE NA Connectathon Conference 2014

Wednesday is  the day the IHE North American Connectathon becomes the Connectathon Conference.  IHE USA invites interested parties to hear about what the 500 engineers are doing downstairs at the Connectathon, and hear from National and International leaders in interoperability about how they are utilizing IHE profiles.

This year the conference was kicked off by Joyce Sensmeier, IHE USA President and vice president,  informatics, HIMSS. The keynote speaker was Doug Fridsma; other leaders from the Healthcare sector also spoke at the conference.

The big news for Connectathon participants is that this record breaking coldest Chicago Connectathon (with highs in the single digits and lows below zero) will indeed be the coldest Chicago Connectathon ever. Starting next year (Jan.26-30, 2015) IHE NA Connectathon will be held at the Global Center for Health Innovation in Cleveland, Ohio. A welcome change will be the natural lighting available to the Connectathon participants.  No more basement zombies!

We heard several times during the day from Mike Nusbaum, an interoperability leader in Canada.  He explained how IHE Canada is fully integrated into the Infoway Standards Collaborative.  While such a model could be successful in the U.S., it doesn’t seem likely in the near future, but the possibility hasn’t been ruled out according to Doug Fridsma.  Mike made the point that InfoWay has money like  the Office of the National Coordinator for Health Information Technology (ONC) does, to advance health IT.  Doug later acknowledged the point during his keynote, but gave InfoWay the nod for having more funding than he does.

Doug kicked off his keynote by first demonstrating that interoperability between different systems, such as projectors and laptops, was something that could be enabled by standards (his laptop to his video graphics array).  Doug walked the attendees through a Presioexplaining ONC’s key priorities, and explaining some of his deep thinking around interoperability.  Much of this included points I and others have heard before, but never before in one presentation.

Key points include:

• ONC is in charge of standardizing five things:  Meaning, Structure, Transport, Security and Services.  When you put the first four together, you get the last, which is services (or APIS).
• ONC has key priorities for how to advance the standards in each of those categories, and Doug explained those quite clearly.  I strongly recommend reviewing his presentation online.
• Doug also elaborated on a point that I’ve heard a number of times, and I think bears repeating:  ONC and its mission to advance Health IT is not limited to Meaningful Use.  Of course that’s one significant goal, but if you look at other things coming down the pike, like accountable care organizations, Veterans Affairs/Department of Defense collaboration, the European Union/United States collaboration, the recently signed United States/United Kingdom collaboration agreement, and other health IT initiatives, there’s more to ONC than just Meaningful Use.

ONC took on a new role with respect to participation in both Connectathon and in IHE this year.  Doug has been on-site all week working with teams testing out US extensions to Healthcare Provider Directory.  To get that kind of time from Doug is quite significant.  ONC is now an IHE International member, and is working with IHE on several other initiatives, including Structured Data Capture (getting data into the electronic health record), and data out using the Data Access Framework (DAF).  While I’ve been leading that effort from the IHE Patient Care Coordination (PCC) domain as the “editor”, the real work has been driven by Nagesh Bashyam or “Dragon,” working through ONC funded activities, with me to simply ensure that it has the right IHE flavor.  It’s been an awesome collaboration.

I’d love to say lots more about the conference, and will in later posts, but I’ve already gotten past the TL/DR (too long, didn’t read) point.  So come back later to my blog for more.

An IHE Connectathon Retrospective

My first connectathon was in 2004.  I've now been to 10 of the last 11 North American connectathons.  That first connectathon was held in a hotel in San Diego.  I remember the hotel well, because that's about all I ever saw that week.  I forced myself to go outside for an hour one day just to get sunlight.  Our network ran at a blazing 10Mbps.  We had one tiny little pipe to the Internet, through which, if someone turned on their VPN, shut down the entire network.  Network was spelled with two o's that week.

I shipped three tower configured boxes and a monitor to that event.  My ADT feed failed, and our support phone lines were down back at home, and VPN didn't work, so I had to rewrite my HL7 ADT feed from scratch in Java.  I did it in a day.  That was before I knew about HAPI, or I could have done it in much shorter time frame.  I was testing Request Information for Display (RID), and needed the ADT feed so I knew which patient to generate my CDA (Release 1.0) document for.

My favorite Connectathon related experiece was actually during the HIMSS Interoperability Showcase.  It was when, due to the overflow around the NIST booth due to the premature invention of XDS, that we had to move the table.  You can read more about that story here.

Besides the accidental invention of XDS, the biggest contribution of Connectathon for me has been the "Social Interoperability" that happens on the Connectathon floor.  This is where people exchange ideas about how to fix problems we haven't yet solved, and talk about where the organization, and our respective national programs need to go.  The brain trust that is here this week always has been incredible.

The biggest change I've seen are the signs of profile and vendor maturity with respect to interoperability and interoperability testing.  This year I spoke with many teams who, by the end of day 1, had completed not just their basic network testing, CT tests, and document sample uploads and viewing tests, but many had also completed several other transactions, including XDS.b and BPPC, two of the harder profiles to test.  And nobody has yet run me down for ATNA assistance.  I guess the FAQ has done its work.

I look forward to another decade of connectathons, but this time in the sunlight.

IHE Needs Your Expertise

Learn how you can participate in the IHE Technical Committees. Join us for Lunch and an Informational session on Tuesday, January 28 at 11:30

Why are we asking for your help?

As an IHE Implementer, you, or a person from your organization, are needed in the IHE Technical Committees and Working Groups.  Each IHE Domain works on several profiles that need your experience and understanding to ensure IHE profiles are designed with practical considerations in order to facilitate implementation.

Learn More while at the IHE NA Connectathon:

Please join us for an information session on Tues. January, 28 at 11:30 to 12:30pm in a reserved section of the Riverside West lunch area to discuss what the IHE committees are working on this year, and how you can help!

What are the Opportunities?

Three Ways to Participate:

1. Planning Process: In the planning process, proposals for next year’s work item development are reviewed and prioritized. The planning process takes places every year in October-November. IHE members can also submit their ideas for new profiles.
2. IHE Profile Development Process: All proposals are voted on by the planning and technical committees in November and begin development immediately. Work groups are formed around each topic to develop a new Profile. IHE members who are interested in influencing the development typically participate in one or more of the following:
• Teleconferences: Provide active feedback to the lead authors of each work item.
• Email Discussions: Occasional email discussions on the technical committee and working group email mail lists related to technical issues.
• Face-to-Face Meetings: Committees meet occasionally throughout the year(travel is optional, but highly beneficial) where the focused work on the Profiles is completed.  Meeting schedule and dates vary by domain.
• Public Comment: Provide comments on work items when they are released for public comment, and/or internal committee review.
3. Change Proposal (CP) Process: IHE profiles have an ongoing maintenance process to develop and review change proposals that help clarify and improve established profiles. CPs are submitted and discussed regularly scheduled teleconferences. Your experience testing at IHE Connectathons is highly insightful and would help ensure that changes made in the CP process are productive!

What are the Benefits?

Participation in the IHE committees provides many opportunities.

• Support the development of IHE-based products in your company; Ensure your organization’s products and implementations are reflected in the development of new profiles and new changes made to the existing Technical Framework
• Establish subject matter expertise in IHE profiles and content and become an asset to your business and industry.
• Build name recognition for you and your company; active IHE members are highly visible and well known in the Healthcare IT world.
• Provide leadership to develop well written IHE profiles that benefit the broader IHE and Health IT community.

What is the Commitment?

Participation in IHE and your time commitment can vary based on your role.

• Observer (1-2 hours per week): Participate in technical email threads regarding CPs or new work items.
• Active Committee member (2-3 hours per week): Participate actively in the shaping and development of a new work item on periodic teleconferences. Active committee members may travel to Face-to-Face committee meetings. Participation is not required but time spent is very productive.
• Committee Leadership Role: Depending on your interest IHE members can take technical leadership or author of a work item or act as a co-chair. Hours vary by role.

How do I get Started?

Your company or organization must be an IHE International organizational member to participate on IHE committees. If you are active implementers, you are probably also IHE members, but if not – membership is free and very easy to accomplish. Visit www.ihe.net/join.

How can you Participate?

Getting started is easy! Just send an email to Gila Pyke (gila@cogna.ca) or Manny Furst (PCD@accenet.org) and indicate the following:

• Yes, I can attend the Tuesday’s lunch meeting or no, I cannot attend the lunch meeting but would like to learn more!
• Describe your technical background, work experience and indicate what IHE domain or profile you are interested in learning more about. Below is a full list of the IHE Domains for reference.

Anatomic Pathology	IT Infrastructure	Pharmacy
Cardiology	Laboratory	Radiation Oncology
Dental	Patient Care Coordination	Quality, Research and Public Health
Eye Care	Patient Care Device	Radiology

Behavior Driven FHIR Starting

Last weekend, my colleague Scott Bolte attended the FHIR Connectathon with intent, but like me at prior events, he really hadn't the time to prepare.  It's the nature of our work, sometimes, the best thing we are able to show up with is our brains.

Even so, he managed to be successful, as you can hear from his story below.

---

Two weeks ago, Keith extolled the benefits of user stories to capture interoperability needs.  This week, at the FHIR Connectathon, I demonstrated that user stories can also serve as executable tests to guide development and verify server/client interactions.  Building on that, I showed the potential of sharing user stories across implementations to improve interoperability.

User stories have long served as the source for system requirements.  Unfortunately, stories are typically translated into detailed requirements with corresponding unit tests.  Not surprisingly, important information is often lost in translation.  To make matters worse, repeating the translation for other implementations increases the odds that interoperability peers will fail to communicate.

An Agile Development practice called Behavior-Driven Development (BDD) fundamentally changes the approach. User stories are structured as a series of Given, When, and Then statements.  The statements, written in simple prose, serve as both a narrative and as test drivers.  The narrative remains accessible to all stakeholders, essential for everyone from the domain expert to the implementer.  At the same time, once glue code is written to map each statement to a small code fragment, the story is a complete test.

One benefit of BDD is that as statements are tied to glue code, they can be assembled into new, unique stories.  Different pre-conditions, the Given statements, can be combined in novel ways to set up a new starting point.  Different triggers for interaction, the When statements, can be used.  Finally, the expected results, expressed as Then statements, allow simple or complex outcomes to be assessed.

I arrived at the FHIR Connectathon pretty much a novice.  I had reviewed the FamilyHistory resource earlier, but had not delved into RESTful APIs or any of the available toolkits. I started by writing some bare bone scenarios to confirm connectivity with a FHIR server; scenarios that evolved in lockstep with the Perl client I was writing.

Here is an early example:

Scenario: Fragile, low-level FHIR server query

  Given FHIR base URL "http://hl7connect.healthintersections.com.au/open"

   When making a "metadata" query

   Then the status should be "200 OK"

One hazard of the example above is it is tied to the implementation.  Appending /metadata to the provided URL is just one way to check for availability.  The literal use of one particular HTTP status code (200 OK) precludes other success codes from being accepted.  However, the worse aspect of that scenario is it is cryptic to anyone but a developer.

Scenario: demonstrate use of symbolic terms to capture stories.

  Given "Grahame's" FHIR server

   When confirming the server is available

   Then the query should succeed

The second scenario is a big improvement.  Referring to Grahame Grieve's test server by name allows for the underling URL to change.  Asking for server availability, instead of a specific URL, allows the client implementation to use alternate techniques such as an OPTIONS request instead of GET.  Finally, simply asking broadly that success be checked allows for different status codes.  In the end, it concisely captures a behavior in a way that anyone can understand.

Before the end of the day, even starting from scratch, my BDD scenarios progressed so I could query resources, create simple reports, and request different data formats.  The example below illustrates table driven capabilities though the use of <SERVER> and <FORMAT> markers.  Furthermore, a multi-line report - the list of medications found on Grahame's server, is verified for both XML and JSON data.

Scenario: bare Patient query of server

  Given "<SERVER>" FHIR server

    And a format of "<FORMAT>"

   When searching for "Medication" resources

   Then the query should succeed

    And the search summary should be

"""

Search results for resource type Medication

     1. Combivent

     2. Crestor

     3. Enalapril

     4. Flucloxacillin

     5. Metoprolol

     6. Paracetamol

     7. Penicillin VK oral suspension 125mg/5ml

     8. Salmeterol/fluticason

     9. Tolbutamide

"""

  Examples:

    | SERVER   | FORMAT |                                               

    | Graham's | xml    |                                               

    | Graham's | json   |                                               

It is a testament to alignment of FHIR to mature web technology that I was able to create such tests from scratch in a few hours.  However, what I find most encouraging is that the final scenarios are completely independent of the underlying implementation.  Users of Java, C#, or any other FHIR client API can write their own glue code. Once they do, they can use the exact same BDD scenarios.  That is not a big deal for the simple scenarios above, but as more complex behavior is described, the reuse benefits will become significant.

‹xi:include href="wheel.xml"/›

The topic of incorporating components from one HQMF in another came up today in an SD/CQI discussion today at the HL7 Working Group Meeting.  On a related note, one observer pointed out that if we are successful, we should also be able to use decision logic from one resource, such as a CDS Intervention, in another, such as a quality measure.

Fortunately, we really don't have to reinvent this wheel in HL7, because W3C already foresaw the need to include parts of one resource within another resource.  It's defined in the XInclude specification, and it provides a way to reference an entire file, or component of a file within another XML resource.  All you need is an XML processor that is capable of performing the inclusions.  Even if you don't have such an animal, you can create one quite readily through an XSLT transform on an XML resource, provided you limit the features of xi:include element that you use (and you can probably implement the whole thing with the right XSLT processor).

If you are familiar with the #include preprocessor directive of C (and C++), then you already have a good idea of how this works.  You name the resource to include (e.g., the file), and can even specify the [fragment] identifer (or other expression) to select the appropriate content.

The reason I like this approach is because no matter how you slice it, an HQMF instance, or a CDS intervention is still defined in code.  You may not look at it as a piece of software, but I certainly do.  And you'll want to manage that software in ways that allow you to reuse components over and over again.  HL7 doesn't need to define this capability, it already exists as part of the base XML standards which we are all using.  We might just have to get a little bit smarter though about how we load XML resources in order to take advantage of that capability.

However, if you are having to interpret HQMF (or HeD), or any other complex XML component, it's surely worthwhile building support for xi:include into your code base.

Running for HL7 Chair?

HL7 is in the process of nominating candidates for a Chair to replace the previously elected chair who had to step down for personal reasons.  We are in the middle of a 45 day nominating period.  I was informed today that I had been nominate.  I was very complimented to receive that nomination, however, I had to decline THIS time.

I'm in the middle of a degree program, and need to devote additional cycles to that.  There wouldn't be any "transition year" as chair-elect in this cycle, because the incoming chair would take office immediately, and in the midst of some very important activities, including moving forward with the Internationalization of the organization.  So, not this time.

However, later this year (in May), there will be a second round of nominations for Chair continuing the normal cycle, and I will stand for nomination at that time.  That cycle will include an opportunity for a year as Chair-Elect, and I believe that I will be able to manage my work and education responsibilities along with that role.

So, to whoever nominated me, I thank you, but I'm not quite ready for that yet.  But, I will be very soon.

   Keith

The Unanswered Question

Where does a newbie go to get more information about HL7?

That's a question I get about 5 times a month, and which I'm sure many HL7 members and staff get over and over again.  The person asking the question isn't asking about where to find the HL7 web site.  I've never been able to satisfactorily answer that question, and I recently discovered why.  The reason is that the answer varies depending on who is asking it.

The dialogue usually goes like this:

Q: Where do I go to find out more about HL7?
Me: Well, what are you trying to do?
Q: I'm a _____, and we do _____, and I'm presently trying to ____ so where should I go?

Fill in the first blank with:

• Software Developer
• System Architect
• Physician
• Nurse
• Public Health Official
• Informatician
• Insurer
• Pharmaceutical Executive
• Executive at a Hospital
• Executive at a Vendor Organization
• Consultant
• Student
• Government Official
• Researcher
• et cetera

Fill in the second blank with:

• Make EHR Systems
• Make Radiology Systems
• Make Immunization Information Systems
• Make Patient Monitors
• Make Personal Health Records
• Make Health Information Exchange Systems
• Make Patient Registration Systems
• Make ePrescribing Systems
• Make Master Patient Index Systems
• Make Medical Devices
• Generate Clinical Guidelines
• Create Quality Measures
• Use (any of the above)
• Integrate (any of the above)
• Make Drugs
• Regulate (any of the above)

Then fill in the next blank with any of the following:

• Integrate with (any of the previous)
• Comply with Regulation
• Develop a new system to do something useful
• Understand how I can use ____ HL7 Standard
• Help to develop ____ HL7 Standard
• Find out more about ____ HL7 Standard

Depending on how they fill in the blanks, the answer varies.  Most of the answers can be resolved in a few clicks from the HL7 Web Site.  Understanding the highway system (the questions to answer), maybe now we can start building the map.

    Keith

What's your HITGender?

This is a particularly difficult post for me to write, because of my gender.  Yesterday I happened across a tweetchat called #HITChicks.  Now, I know most of the women involved in this chat, so I started listening in.  Of course, my challenge in participating in this conversation is in being male.

I find issue-based affinity groupings like this to be very challenging (for me).  Either I'm not a member of the group, and so am challenged by offering any input, or I am a member of the group, and while input I find that is most useful is what others have done or suggest which might work to address my issues, it rarely comes from those outside the members of the affinity group that are trying to address the issue. Or, I'm a supporter because I have some close ties to folks who are affected by the issue (e.g., my two girls). But it is in fact, in outside the affinity group where the solutions must be enacted, and where they likely might be found.  Otherwise, all we might be accomplishing is to have a bitch session.

My major observation to that chat was encapsulated in this tweet:

So #HITchicks, help a guy out. How can men help? This isn't an exclusive club either way, right? How do/should #HITguys get involved?
— Keith W. Boone (@motorcycle_guy) January 16, 2014

Click on the date above to see the responses, which were all fairly positive.

In this field, the people enjoy working with the most are mostly women, and it also seems to be the gender I work best with.  I don't understand why, but it is something that I have observed about myself.  And some of the women I work with have commented on it directly to me.

So, there's a style differential somewhere that seems to be somewhat gender related.  And it has an impact on me, and others.  It seems obvious (to me) that we (#HITFolk) cannot ignore that there is a gender differential, whether it is considered in either a positive or a negative light.  What is needed then, is an appreciation of the value of that differential, in both line and leadership positions (FWIW: The women I'm talking about above are all serious leaders).

I don't know what that differential is really, but I do know this.  If there really is an issue, and you want to resolve it, the best way to address it is not by forming an affinity-based group to address "your" issues, but rather to engage a wider audience in those issues, perhaps through some affinity-based leadership on those topics.  If we divide along the #HITChicks and #HITGuys line, we won't get there.  So, if you want to address gender issues in #HIT, how about an #HITGender chat?  The #HITChicks might lead it, but if you really want a solution, it's going to have to involve some #HITGuys.

Think about it.  I still am.

     Keith

The Rules for Displaying what isn't there in MeaningfulUse are Invisible

The following question showed up in my inbox since I subscribe to the Transport Testing Tool Google Group:

---

We have come across an issue with the human-readable display of C-CDA sections. It is our understanding that systems receiving C-CDA documents must render all human-readable content from the received C-CDA. However, our certifying body is expecting certain sections of the C-CDA to display when that section is not included in the xml file that we receive from the TTT.

Is it appropriate to display sections of the C-CDA in the human-readable when they are not included anywhere in the xml? If so, can someone point us to the documentation that explains how to best accomplish that?

---

Here's how I responded:

---

From the CDA standard and C-CDA implementation guide perspective, there is NOTHING that says you MUST make content not in the human readable narrative visible on the display.

What the CDA standard suggests can be found in sections 1.2.3 (Human Readability and Rendering CDA Documents), and in 1.3.3 Recipient Responsibilities.

What the MU Certification requirements say for view (the critical component of the query above) for 2014 is (see 45 CFR §170.314(e)) found under Patient engagement requirements:
(e) Patient engagement.
(1) View, download, and transmit to 3rd party.
(i) EHR technology must provide patients (and their authorized representatives) with an online means to view, download, and transmit to a 3rd party the data specified below. Access to these capabilities must be through a secure channel that ensures all content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).
(A) View. Electronically view in accordance with the standard adopted at § 170.204(a), at a minimum, the following data:
(1) The Common MU Data Set (which should be in their English (i.e., non-coded) representation if they associate with a vocabulary/code set).
(2) Ambulatory setting only. Provider’s name and office contact information.
(3) Inpatient setting only. Admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization.

The NIST test procedures must be followed by testing labs, you can find the approved procedure for VDT here.  That does not specifically state that data not present be shown, only that the MU Common Data set be shown. Items 1-6 and 16 in their list actually come from the CDA Header, and so would have to be shown according to the test procedure and Meaningful use requirements.

So, if the document doesn't contain data from the MU data set, what should you do? That's really an implementation decision. That strikes me as being a sub-regulatory implementation decision, but one that should be different across certifiers. It sounds as if your certifier has determined that the right behavior is to do something that shows that there is missing data from that data set.

For items 1-6 and 16 in the list, if the item isn't present, best practice (my opinion, not an ONC rule or NIST requirement) would be to indicate that it wasn't there, since you wouldn't expect a user to remember what those items are all of the time. Items 7-15 in that data set all show up as part of the narrative portion of the document, and there should be way in the document to say "unknown", although admittedly that can be challenging sometimes (as for labs). So if it's a compliant document, displaying the narrative section content should address the display issues for items 7-15 in the common data set.

You can find some guidance on how to address these issues in the S&I Framework Transfers of Care Companion Guide. While this guidance does not have official status anywhere yet (other than S&I Framework consensus), it is presently going through HL7 Ballot, and I fully expect this to show up in the 2015 Optional Certification criteria (in fact this guide makes much more sense than trying to include C-CDA 2.0 for 2015, because it is compatible with the existing requirements for 2014). However, you won't find much on dealing with display of missing data in that other than what I've already said above.

I'd love to hear what some of the authors (especially David Tao) of that guide have to say.

Basically, the rules about what to do when the data isn't there, aren't there.

   Keith

Let's Start this FHIR Right

A long time ago in HL7 there was a rule that any specification had to be re-balloted if there were substantive changes before it could be published. Back then, getting a specification published also took a very long time, and the bars to getting things past were very high. For a normative specification you had to have 90% approval, and for DSTU or Informative, you had to have 75% approval or something like that. So things took very long, and in fact, some specifications took almost a decade to get out.  HL7 was made fun of and everyone was very sad. Once HL7 realized it had a problem, it began a process improvement effort, and many of these constraints were reduced or removed as being barriers to completing the work of creating standards in a timely fashion.

So now we get to the point where, if some 50-75% of members are agreed, a (non-normative) specification can pass ballot and be published in one balloting cycle. However, this means that many substantive changes can be made, and it is up to the working group developing the standard to decide whether or not a re-ballot should be performed. I've not seen a case where they ever do in the work groups that I'm involved in, and I think that's a mistake.

Which brings me to the real topic of this post. I've been firmly behind FHIR as a specification since very early on. I've been involved in some of the early Connectathons (hack-a-thons really), and in promoting the use of it for IHE specifications and ONC specifications. I firmly believe this is great stuff. But…

We just went through a HUGE ballot cycle (HL7 received over 800 comments from 122 ballots), and made numerous changes, many of them substantive. The last time we had more than 100 votes on an HL7 Ballot was in May of 2011 on CCDA Release 1.0 with 104 people voting (and CCDA Release 2.0 had more than 900 comments).

I haven't been able to be involved in many of the reconciliation discussions (although I know my colleague John Moehrke has). So, I'd like one more chance to look over the specification and comment on it ONE LAST TIME before it becomes a DSTU. I firmly support the effort of Graham and the entire FHIR team. I've been promoting the standard internally and externally in the strongest words I have. But I'm not ready to say that it is fit to be published as a DSTU yet, and I don't want people to think that I'm against FHIR when I say that. I just want to make sure we get it right. This is brilliant stuff, the best thing to come out of HL7 in many, many years. Just let me have one more ballot. FHIR and HL7 will be better for it.

See John's post over on his blog for his thoughts on the same issue.  And if you have any questions for either of us, feel free to ask us.  We'll both be at the HL7 WGM next week!

Knowing Who to Talk to is Half the Battle

Have you ever been in a situation where someone asks you to follow a procedure that you know doesn't make sense?  And complaining about it does you no good because the person making you follow it isn't in a position to change the procedure, they are simply doing what they are told.

When someone tells you that it has to be done this way because of "HIPAA", the solution is to talk to the right person.  However, who would that be?  Fortunately, HIPAA helps you out here, because a health system has to have a named "Privacy Officer".  So the person to ask for, and who might be able to resolve the issue, or at least do something productive with your complaint is the "Privacy Officer".  So, while I cannot tell you the name, I can tell you the job title.  And if the organization is paranoid about HIPAA, anyone you talk to will know how to find out who the privacy officer is.

I'm taking my own advice with this, and complaining to my physician office's privacy officer, because while the organization will FAX records to another healthcare provider (whom I identify over the phone), they will not FAX them to my FAX machine AT MY home phone number (which is included in the record) at my request.

So, I get to do a little 'splaining of HIPAA to my HCP, and I'll be using OCR's memo if I need it.

   Keith

P.S.  I just spoke with the person with that title, I can tell you it isn't going so well thus far, but she is referring me to her manager.  They really aren't set up to deal with patient feedback, are they...

P.P.S. And later, after speaking to her manager, I'm more mollified.  I understand their process, and what they have to go through to change it, and offered to help them out when they were ready.  The manager was quite happy to hear from me.  We'll see where things go from here.  I have some hope, but I also know it will take time.  It will be time well spent for my family and the other patients in this practice.

The Little Changes that Last

In going through HL7 ballots, especially those developed using Word instead of XML, I find some old friends.  Bits of boilerplate that didn't exist ten years ago but which I now see in ballot after ballot (some of which I wrote, others that I suggested changes to), fragments of text which sound quite familiar used in places that I didn't expect.  Even document properties which don't really make sense except when you know the history.

Knowing where these pieces came from and why they exist is knowledge of very limited use, and it really only comes with longevity.  Some of this stuff goes by without hardly a question, but I remember when it was hotly contested, and widely discussed.  It seemed as if the sky would fall if we did not get this right.

A decade later, the sky is still (mostly) in one piece, and these little things have become part of the organizational culture.  Remember that next week when you go through reconciliation.  In a decade or so, nobody will remember who wrote those lines originally, only that they are good, and should be used again. Nobody will recall what the debates were or what the alternatives were.  So get it right, but don't overdo it. If it isn't right, it will get fixed later, and if it is right, all we will do is remember that it was right, not necessarily why. Save remembering why for The Historian, or The Venerated Ancient.

    Keith

Valid CCDA Instances vs. Valid EHR Implementations for MeaningfulUse Stage 2

A number of folks have asked the question about what they can do in CCDA for Meaningful Use Stage 2 when there are no medications, allergies or problems to report in the document, or when, because MU Stage 2 allows the physician to customize the content.

This is an interesting question.  MU Stage 2 says you have to provide the content for 17 different data elements, but it doesn't specifically say what you do when that isn't present.  Certified products have to pass tests which verify that they can create the data elements, but those tests at present DO NOT verify that they've correctly produced a CCDA document where there is no data for a medications, labs, allergies or problems section.  But clearly this can happen, and CCDA has allowed for it, although it is missing good examples (that's a work stream happening in the Structured Documents Example Document task force)

My recommendation is to supply the empty section with an appropriate flavor of null for the entry that would be required in that section.  You can find some information above in my various posts on moving from C32 to CCDA. This needs to be addressed better in future certification and regulation.

These would be valid instances of a CCDA for Meaningful Use, but using them won't get you certified.  In other words, what you have to do for certification is everything.  What you have to do in the real world is report the data that you have, or in some cases, report that you don't have that data to report.

   Keith

Telling Stories

People really like to tell stories.  A few weeks back I was leading a workshop where I was trying to get a bunch of non-technical folk to explain to me what their needs were.  I had blocked off some time in the workshop to get into the details of what they needed.  My visioning exercise had totally bombed a half hour before (from my perspective).  Trying to get people to imagine what technology could do for them who hadn't ever been exposed to anything like what you have to show them is really challenging.

So what I did was ask them to tell me a story.  I broke the group up into smaller groups, and separated them from their usual cliques and colleagues, making them work with people in different specialties that they wouldn't normally run into.  Then I had each group tell me two stories.  The first story was about a normal event, when everything goes the way it should in a text book.  The next story was to expand on that, adding detail that can only happen in the real world.

PAYDIRT!  I hit Gold, or perhaps Oil, and it sure was a gusher.  The amount of information that shows up in a person's story (or a small group's) is tremendous.  As one of my instructors hinted there's untold information in the smallest details.  This is a really simple exercise to execute on, yields a wealth of information, and really gets the people participating with each other.  The next step was to have one person from each group tell their story, and have the participants comment on it.  If you ever need to fill a two-hour block in a workshop, this is a great way to do it.  And the content you get (especially if you are requirements gathering) is tremendous.

   Keith

P.S.  In case you hadn't noticed.  This too is a story.

Agile National Standards

I'm working with some colleagues to develop a way to apply Agile methods to standards development for regional and national (and I eventually hope to apply this to International) programs.  It's an interesting process to consider.  We don't have code to test, only interoperability specifications which makes it harder. However, it seems that many of the same principles could apply.

Use Cases and transactions become epic stories and user stories.  Parts of the specification instead of the code become the items in the backlog to create and work through with the customer. Many of the same things apply, and there's even some testing to introduce into the matter (e.g., certification/conformance testing to the specifications).  As a side project, I'm thinking we should write a paper about our experiences once we see how this turns out.  It should be interesting.  I'd love to hear your thoughts about this.

   Keith

The Next Term

Next week starts the new quarter in my MS in Clinical Informatics program.  Again I'll be taking two classes.  This time I'm going to be taking:

• Project Management
• Medical Decision Making

I've been doing project management for years.  I cannot find my copy of the PMBOK Guide, so now I have the Kindle edition, which will be more useful.  Some of my texts will be paper though, but hopefully not so much that it makes travel difficult.  I'm looking forward to that class, because while I'm not wholly self-taught, there's still plenty to learn and be refreshed on about managing projects.  I'll also be interested in seeing what is new in the field.

Medical Decision Making promises to be interesting because there's at least some degree of math involved. This class should also be a good lead into Evidence Based Medicine which I don't get to take for a while because of the course scheduling (I missed the chance last term, but was glad to just do two classes).

I did get my grades from the last term, and as Bill alluded to in this post, I did just fine.  Two A's.  One of the challenges I had with the last term was keeping up with this blog, since I was writing a 500 words or more a day for class.  I'll have to figure that piece out.

One of the things I remember from my last degree (an AA) was the challenge in scheduling everything so as to finish within a set period of time.  So I've got the next two years already planned out.  And of course, as soon as I do that, Bill writes this post discussing how he's working on curriculum changes.  So, I'll probably have to change my plans, which doesn't disappoint me at all.  After all, a plan is simply a framework that rarely survives the first engagement with reality (as I'm sure I'll be hearing about in my Project Management class).  The idea behind the plan is to know where you are headed so that when you come to an unexpected fork in the road, you know which direction is likely to lead you where you want to go.

Where am I going?  I'm not really sure, but my plan is to take an interesting journey, where ever it is.  So, my choices get to be a little bit different when I see a fork in the road.  Because I get to pick the path that looks the most interesting.  Oh, and just so you don't get confused, I expect it all to lead me right back to where I started, but with new tools and skills to apply to what I'm doing.

Call for Participation: a LOINC Order Code Initiative

The first Common LOINC Laboratory Order Codes project was developed for referenced the HITSP C80 Clinical Document and Messaging Terminology Construct and is also used in the current HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 in HL7 and developed in collaboration with the HHS S&I Framework Laboratory Orders Interface Working Group.

This project intends to improve that work. I'm thrilled to see that work going forward. I used many of the techniques pioneers by Clem McDonald recently to develop a similar set of order codes for the work that I'm doing in Saudi Arabia, where I'm headed again today.

-- Keith

---

Call for Participation: a LOINC Order Code A new project has joined the S&I Framework community:   a1 LOINC Order Code   The use of non-standardized local codes or terminology to describe laboratory test orders varies widely among laboratories. Universal use of LOINC coding for laboratory order and result information in a structured and systematic fashion is an essential component of interoperability between providers, clinical laboratories and public health laboratories. This project will focus on the enhancement and expansion of Logical Observation Identifiers Names and Codes (LOINC) Codes for commonly ordered clinical laboratory tests in the ambulatory care settings and for tests ordered in the public health settings. This goal is for Regenstrief Institute to publish up-to-date lists of clinical and public health Order Codes Value Sets that could be recommended for incorporation to support EHR Meaningful Use (MU) stage 3 certification requirements. If you would like to volunteer to participate in the a LOINC Order Code project, please review the documentation on the S&I Framework wiki: http://wiki.siframework.org/Getting+Started+as+a+Volunteer  Once you have read through the material regarding participation, levels of commitment, guidelines for participation and voting rights,  please sign up to participate in the a LOINC Code initiative by completing the registration form at: http://wiki.siframework.org/a+LOINC+Order+Code+Join+the+Initiative  by January 8, 2014, 5:00 pm EST. a LOINC Order Code Project  – Building agreed upon, stakeholder, consensus-based Laboratory Order Code Value Sets for ambulatory and PH settings http://wiki.siframework.org/a+LOINC+Order+Code+Charter+and+Members 1 a stands for agreed upon, based on a consensus approach, amongst various stakeholders

Bike Week

Not quite a decade ago I edited text for my first IHE Profile.  That text was originally authored in support of the metadata used in Cross-Enterprise Document Sharing (XDS). I spend many hours on that content, reworking it from its original structure, and adding numerous examples.

Since that time, many IHE profiles have made use of the metadata defined by XDS, sometimes making small adjustments to accommodate the profile requirements.  These "minor" adjustments, as well as the many Change Proposals incorporated over time, led the contents of Section 4 getting even harder and harder to comprehend, especially for those not implementing the profile for which this section was originally written.

For the past two years, a team of brave, dedicated people have been restructuring volume 3, section 4 to add clarity and make it easier for implementers to read and comprehend. They have added examples, explanations, context, sample code, diagrams, and reduced ambiguity wherever possible and have grown the section from 20 to over a 100 pages in size in order to best support the implementer community.  

That additional 80 pages represents a good deal of data that was hidden away in historical context, implementation experience, or simply locked away somewhere in the brains of the original committee members.  But it also includes better explanations, great examples, and awesome UML diagrams. The end result is something well worth looking at.  Normally we’d have them all show up at a sushi bar, or a beach or mountain resort for a celebratory party, but given the distributed nature of the team, that would be a bit difficult.

In that spirit, I delighted to present to you -  The Redoc Dozen (in alphabetical order):

Bill Majurski: For getting the redocumentation effort started, and being patient and supportive when it veered off in a different direction.
Dave Pyke: For diving into the deep end to help with the editing and cat-herding when it got really busy preparing for public comment.
Derrick Evans: For being the quiet voice of encouragement, and for giving us so much time at face to face meetings when we begged for it!
Elliot Silver: For reading through over a hundred page document over and over, and single-handedly identifying more opportunities for improvement than everyone else combined.
Jeremy Huiskamp: For jumping in feet first out of the blue to write XML code, provide implementer’s insights, and put in more hours than most seasoned volunteers ever do, and for doing it with unfailing cheerful enthusiasm!
John Moehrke: For providing context and content on topics where the rest of the group was silent.
Karen Witting: For being the brains and inspiration behind much of the content and reorganization.
Lynn Felhofer: For practical insights and contributions when the rest of the team was too sick of it to look at it anymore.
Marke Sinke: For providing comments and insight and his incredible patience for comment resolution.
Nancy Ramirez: For keeping us on schedule, making sure we have time to meet, and putting up with so much change and last-minute requests!
Rob Horn: For providing historical content and rationale, and for putting in so many evening hours to make sure CPs and other items got done right.
Sylvie Colas: For doing all the UML and updating it over and over, and for being our ebRIM source of truth.

And for their efforts, I proudly award them The first ever... 

Ad Hoc Bike Week Award

for making my life easier, and therefore more fun.