What do I need to know?

How do I get a job like yours?  How did you learn how to do what you do?  These are all variations of questions that I get from time to time that is a) quite complimentary, and b) extremely challenging for me to answer.

Be Passionate
Few people I know in the standards space ever planned to be where they are now.  That goes for me in spades.  If you had told me in my misspent youth that I'd be reading House, Senate and Conference editions of healthcare bills in the same week, or that I'd be commenting on federal regulation and be taken seriously, or that the work I'd been doing would impact as many lives as I think it does now, I'd have laughed you right out of the room.  I never planned to be in this career, but once I found it, and acknowledged it as a calling, I latched onto it hard and with great passion.

That's my first tip.  Be passionate about what you are doing.  Being passionate is not just about loving your work, or having fun at your job, it's about taking it really seriously, and loving it at the same time, even when it sucks.  If you don't love doing this work, you won't succeed in it.  There will be times that what you have to do to get a job finished sucks: It may be tedious and boring, impossibly frustrating or just plain painfully unrewarding.  You have to learn to take your rewards from a job successfully done, and done well, and with the impact that it can have on people.  Financially, the job can be rewarding, but if financial reward is your measure of success, this job isn't for you.

Become an Expert
What do I need to learn?  You need to learn something at the expert level.  That requires a good deal of commitment.  It's not just about spending 10,000 hours on something, but being passionate while you do it.  And by something, I mean something that others will value enough to seek you out for your expertise.  I can't tell you what to learn.  I can tell you to pick something where people are already confused and seeking help.  It's helpful to have another expert to rely on to help you out, but that isn't necessary.  It's a lot easier to become first in a field of one than it is to become first in a field of 10.  And if there are already 10 experts in your chosen field, branch out a bit.  What good is one more expert when there are already 10?

To learn something at the expert level means that you have to understand how the parts it relies upon work together.  You have to be more than a novice at XML before you will ever become an expert in CDA.  If you don't understand how XML and XML Schema work, there will be things about CDA that you just won't understand.  If you don't understand how a combustion engine works, you'll never become expert on motorcycles.  That doesn't mean, by the way, that you need to have expert skills in the underlying components, but it might.  The closer ties that the two things have, the more you need to know.

Have other Experiences
Being an expert about X is useless if you cannot apply X to problem Y.  You need to learn enough about problem Y as it relates to X.  I have skills in database management, natural language processing, data compression, digital signal processing, text processing, text and graphics rendering, text markup, and document analysis.  Those skills were developed over a twenty year career before I ever got into CDA and Healthcare.

Some of the best CDA experts in the world got their start in SGML.  At least one CDA consulting firm I know is made up of numerous people who had SGML, or similarly related skills first.  CDA experience (and subsequent expertise) came with the job.

Learn something new as part of your routine.  Challenge yourself.  Read a book that you don't understand fully.  Skip the parts you don't understand and then go back and read them again later.  One of the coolest things that I love about my job is when two (or more) things I've read go click, and all of the sudden, I gain a new insight.


Develop a Network
When I work on a problem, you don't get just me.  You get Glen and Charles and John and Harry and Lori and Gila and Bob and Tom and Rob and Tim and ...  the rest of my network.  You aren't alone, don't act that way.  Call on your friends and colleagues to get their advice.  Listen also to your critics as well.  Then make your own judgement, and use what you found valuable.  At the same time, when others call on you, offer your best efforts to help them out when you can.

The Health IT standards world may look like the good ole boy network, but it's not because the entry criteria is different.  That's where being an expert is important, because experts often need other experts, and will work well with other experts they respect, even when they disagree.  Some of the people I most respect in this field are ones I also have the most interesting arguments with.

Find (and Lose) a Mentor
I can count on one hand the number of mentors I've had in my life, and the number of people I've been a mentor too.  It's a very special relationship, and incredibly valuable on both sides.  If you want to advance your career, keep looking for mentors.  Don't expect to find one after a short search either.  I've been seeking my next mentor for years.

At the same time, there is a point in time that you will have to fly on your own.  Losing a mentor is not a sad event (usually).  Every mentor/mentee relationship I've ever had ends in the same state, in a strong relationship between friends and equals, where both are better off than they started.  In at least one case, the person I was a mentor to quickly surpassed me in my chosen career, and that was one of the prouder moments of my life.

Be Patient and Insistent
Patience by itself is a virtue, but doesn't gain what you need.  You must be not just persistent, but insistent to get what you want.  The persistent person will try the same thing over, saying this must be the way out.  An insistent person will try different approaches, saying, there must be a way out. Keep your goal in mind  and be patient and insistent in achieving the goal, rather than any specific solution, and you will find what you are looking for.


This is probably not the answer you were looking for when you asked me that question.  If you want a simple formula, I simply don't have one.  I meandered through mine fields to get here.  It was through incredible luck, incredible mentors, and incredible patience and perinsistence that I've reached the middle of the mine field, and I plan on someday getting through to the other side.

أنا كيث بون

For those that cannot read Arabic, a semi-literal translation is I am Keith Boone.  The Arabic script reads right to left, rather than left to right, and while there are no capital letters, each character in the script takes on a slightly different appearance depending on whether it appears at the beginning, middle or end of the word.

Arabic script is an Abdjad, essentially a syllabary but missing vowels (because those sounds are inferred by rules of the language).  Japanese writing uses a syllabary that has consonant sounds built in and from that we have the ひらがな and カタカナ writing systems as well as romanji transcriptions commonly used for those names (Hiragana and Katakana respectively).

In healthcare, one of the challenges with matching names is that the best matching algorithm varies depending upon the cultural patterns associated with the name.  And so, in a culture where the name patterns are Arabic, the name matching algorithm needs to account for that as a source of possible variation.  One of the popular names in the world is that of مُحَمَّد, also the name of the prophet of Islam.  There's really only one way to spell it Arabic, but at least 9 different spelling variations using the Roman alphabet.

In countries where Arabic is the official language it is still challenging because most software still doesn't deal well with the Arabic writing system, especially given the script changes necessary for rendering an the beginning, middle and end of the word.  It wasn't until the advent of smart fonts in the late-1990's/early-2000's that software could really deal with the script changes necessary to properly render Arabic script on many computers, and those capabilities weren't well integrated into operating systems (some would argue that they still aren't) until a decade or more later.  And so, Arabic names are still often romanized when entered into that software.

But knowing that the name was a romanized form of an Arabic name is a crucial hint that name matching software can use to better determine how to look up appropriate matches.

One might be tempted to offer this hint to the name matching software, for example using the IHE PDQ Version 3 Query's matching algorithm parameter.  In fact, I even suggested this idea myself.  But I'm probably very wrong to do so, as I think about it.

If I were designing a search algorithm to locate names in a master patient index, I'd probably leave the algorithm tuning to the computer.  Here's how I would go about it:

In the context of looking a patient up by name and potentially other demographics, there are many other features present that may provide this and many other hints about how to tune the name matching algorithm.  This includes location (e.g., Riyadh, where I am now), nationality, place of birth, et cetera, and these values may also be provided in the query.

These features, along with the character sequences in the name (and other fields), become a set of features which can be used to compare two names for a proximity match.  In the fields of machine learning and linguistics, there are sufficient ways to describe features and feature distances, and to combine these into matching algorithms.  It's a Big Data problem, and the computer will be better at determine which features will be helpful to decide on the matching algorithm.  I'd let it do that work, and it would do a much better job than my simple hint.

What might be the most important that could be provided in a name matching algorithm is something that the receiving system doesn't necessarily know, and cannot deduce or induce from the data that it is provided.  What information is that?  It might well be the keyboard layout or input device used to enter the name.  If the device is the tiny little keypad on my smartphone, the kinds of human input errors I make will be far different than if from my keyboard.

This is where human interface design intersects with something with what many would consider to be a largely compute bound, human interface free context.  But it's not.  There's spelling correction mistakes I make on my phone (or that my phone makes for me) that I would never make on a real keyboard.

Peace.

  -- Keith

Implementation is always the real test

When HL7 implemented the board decision at the beginning of the week to make selected IP free, many of you noted that DSTUs were still marked as being available to members only.  The board intention somehow was not implemented as some (including me) thought it had been clearly specified.   I'm told that will be corrected shortly now that the board has clarified its intentions.

I certainly never expected DSTUs (including CCDA) to be treated any different from anything else.

It just goes to show you that what seems to be obvious isn't always.

I don't think even RFC 6919 would have helped here.

It means what I want it to

We struggled for the longest time today trying to figure out how to say the following in HQMF:

Find me the first instance of this medication (e.g., Aspirin), in these kinds of encounters (e.g., ED visits where DX = MI).

The challenge wasn't the medication, or the type of encounter, or even encounters where DX = MI, but rather how to apply FIRST and DURING operations at the same time so that FIRST returned more than one item.  E.g., it was the first item of its type in the time period expressed by the temporal relationship.

We struggled with it for quite a while, and I'd written something on the board, and then Dragon pointed out that we'd added the <subsetCode> attribute to the <temporallyRelated> act relationship and it all came together.

I don't know what that means I said, but we can define it to mean what we want it to.  Marc said "Wait, let me see if I can make this work before I agree." and he started digging into code.  The rest of use looked at it some more to poke more holes in it.  "Does it still work if we change LAST to FIRST?" I asked, and yes it did.  "Does it work if we use a different temporal relationship?" I asked again, "Like BEFORE?" Chimed in Dragon.  Yep, that worked too.  And Marc said, "Yes, I can make it work.  I like this."

And so, even though we weren't sure what it meant when we looked at it at first, by the time we were done, it meant exactly what we wanted it to, and it wasn't even a stretch to believe that someone had actually designed it to work that way.

So now, if you want to know what the average time is for a patient who needs it to be given Aspirin in the ED if they are having a heart attack, we know how to A) specify that measure, and B) compute it from the specification.  Being able to do A is nice, but the biggest change in HQMF Release 2 is that we can do so much more of B from A.

   Keith

Back to QueryHealth and HQMF and a gratuitous Star Trek reference

We are trying to finish up HQMF Release 2.0 this week, seven of us, meeting in MITRE's offices in Bedford, MA.  Initially this meeting was scheduled so that we could complete the big push to get the standard out in time to be referenced in Meaningful Use stage 3.  With CMS' announcement that Stage 3 will not come out this year, I don't see the need to rush, rather I'd like to get it done well.

One of the challenges we worked out today was how to combine and reuse different criteria.  We worked out a fairly elegant solution that allows a data criterion to be further refined, or be used with other criteria in union and/or intersection operations.  We also worked out some simplifications around excerpts, realizing that we could just limit ourselves to FIRST, LAST, MIN and MAX and use that to be able to support Nth, or Nth from the end, without having to support the entire value set possible.

There are a few other simplifications in the works, and the combine and reuse solution also seems to allow us to address what I had quickly relabeled the 7 of 9 problem.  The problem is that some measure developers want to be able to create numerator or denominator criteria where what is being counted meets N out of M other criteria.  This is a pattern than is often used in certain kinds of assessment instruments, and rather than using an assessment result, you could just compute it based on the known data.  Using the combination solution, there's a way we can say that.

Some Restrictions Apply

Yesterday, HL7 implemented a policy that I've been working towards as a member of the HL7 Board for quite some time.  Under that policy, anyone can implement HL7 standards in their products without paying a license fee to HL7.

Yes, you can download the standards from the HL7 web site today without charge.  They do ask you to do a couple of things (hence, the title of this post):

1. Register on their website.
2. Agree abide by the license terms and policy.
3. Update your agreement status annually.

Is that so hard?  What this means for developers is that you can use the HL7 standards free of charge to develop software products.  It doesn't mean that you can incorporate parts of the standard into your documentation, or give parts of it to your customers, or otherwise distribute it.

Organizational members still retain some of those benefits that non-members aren't freely given.  They are able to share copies of the standard internally to their organization and to share parts of it (not whole chapters or domains) with their customers, or use parts of it to create implementation guides or product documentation.  

Some will complain that it's not fair that members can still do things with the standards than non-members cannot.  I have to say that if it has value, then maybe you should be willing to pay something for it.

Over time, I think the "paper work" to download the standard (which takes all of about 15 seconds to fill out) will get even less intimidating.  For now, we probably need to give the lawyers their due.  

Personally, I think that the new policy is a great move in the right direction.  What do you think?  Have you downloaded the standards yet?

    Keith

I don't know is not the same as none

I keep hearing that "There's no standards for that.", or that "There's too many optional features in that data element."  Sometimes these pronouncement come from people who should know better (at least by reputation, not necessarily according to knowledge or skill), and other times, it simply comes from folks who don't know that there are other places to look.

I think the main challenge is that so many folk looking for standards don't know what is there or where to look.  Organizations like HL7, IHE, IHTSDO, and LOINC that put forth such standards don't necessarily make them easily accessible in ways that implementers expect.

Clinicians and researchers are accustomed to looking up stuff in publication directories such as MedLine/PubMed.  Developers are accustomed to looking to publications from one or two (or maybe even three) SDOs or profiling organizations.

We can readily determine at a clinical level the appropriate treatment for a particular disease, or how to effectively use a particular medication, but have no similar resource to determine appropriate ways to communicate information about a particular disease or treatment to those who need to automate it.

USHIK is a good start for those of us working the US, but it doesn't really address the issue.  For example, what do you need to know about communicating an A1C result?

1. What standard is used to order this test?
2. What standard is used to communicate the results of this test?
3. What standards are used to transport the information in steps 1 and 2?
4. What code is or should be used to identify the result in step 2?
5. How do we codify units?
6. What other data need to be communicated to the lab to perform this test?
7. How do we communicate the normal range for results?
8. What information in the above is necessary to make determinations about quality of care related to this test?
9. Among all variations in 1-7, how do we identify the right combinations that should be used for quality measurement?

I could answer the questions above, but I can tell you that there are likely to be eight or nine different publications that the implementers need to be aware of.  And none of these really address any of the clinical issues, just the technical issues with respect to the communication.