Friday, October 17, 2014

Take as Written

One of the requirements for the HITSP C32 as specified by AHIP was that a medication entry provide the free text sig.  That specification met the requirement by indicating that it could be found in the <text> element of the <substanceAdministration> element.  This has resulted in implementation confusion because some feel that it meant that ONLY the sig should appear in substanceAdministration/text, and others felt that it could be part of it, but that it could also include the medication and other details (such as preconditions or other cautions or instructions like take with food).

The latter interpretation is what the HL7 RIM specifies should appear in the medication template's substanceAdministration/text element.  Some systems want access to just the sig, and cannot determine where it begins or ends in the medication template.  So Structured Documents is now working on a new template that can be used within the Medication template to show JUST the sig. Rick Geimer and I have been tasked with coming up with a proposal.

Here's essentially the proposal that we discussed on the SDWG call yesterday.  We add a new template called "Medication Free Text Sig" (or some similar name) which provides the free text sig component of the medication.  This template becomes a recommended component of the substanceAdministration template now, and perhaps becomes required in future editions of C-CDA.  It looks something like this:

    <paragraph ID='med-1'>
      <content ID='medname-1'>Amlodipine-Benzapril 2.5-10mg</content>

      <content ID='sig-1'>one capsule daily</content>
    <substanceAdministration classCode='SBADM' moodCode='INT'>
      <text><reference value='#med-1'/></text>
      <consumable typeCode="CSM">
        <manufacturedProduct classCode="MANU">
            <code code="898352" 
      displayName="Amlodipine 2.5 MG/Benazepril hydrochloride 10 MG Oral Capsule"
              codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm">
              <originalText><reference value="#medname-1"/></originalText>
            <name>Amlodipine 2.5 MG / Benazepril hydrochloride 10 MG Oral Capsule</name>
      <entryRelationship typeCode='COMP'>
        <substanceAdministration classCode='SBADM' moodCode='INT'>
          <code code='422096002' displayName='Take' 
              codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED-CT'/>
          <text><reference value='#sig-1'/></text>

This component simply provides access to the free text content of the sig portion of the medication entry.  Like the travel history section, certified EHR systems could start using a template like this today.  Consider this my prescription for how to solve the problem.

   -- Keith

Thursday, October 16, 2014

On a Process for Rapid Template Development

Recently a question crossed the Structured Documents Workgroup List about how to record information about a patient's recent travel.  You can probably guess what recent media events motivated that question.

IHE had long ago developed a template for foreign travel, as part of XPHR. Since this section wasn't required in the HITSP C32, it was not further developed in C-CDA.  However, that doesn't stop anyone from using it, even under Meaningful Use.  The Foreign Travel template is simply a section containing a narrative description of travel.  Narrative capture of travel history is what most EHR systems today support.  This usually appears somewhere in the social history section of the patient chart, and is accessible to any provider caring for the patient in most EHR systems.

For cases of communicable disease, if you want the EHR to be able to apply clinical decision support to recent foreign travel, you would need coded entries, or natural language processing over the narrative.  To code the travel information, you will need to do more in this section.  The basic activity being documented is travel, and so you could readily capture that in an act, with location participants for each place visited.

<act classCode='ACT' moodCode='EVN'>
  <code code='420008001' displayName='Travel'
      codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED-CT'/>
  <effectiveTime><!-- This might be optional, see participant/time below -->
    <low value='Starting Date for Travel History'/>
    <high value='Ending Date for Travel History'/>

  <participant typeCode='LOC'>

The participant would represent the various locations visited during the time period described in the travel act.  We need not go into the entity level since participant.role can capture what we need.

<participant typeCode='LOC'>
    <low value='Starting Date for this Location'/>
    <high value='Ending Date for this Location'/>
  <participantRole classCode='TERR'>
    <!-- This might be optional, and could identify locations using a value
         set such as Geographic Location History -->
    <code code='Code identifying location
      codeSystem='Code System for Locations (e.g., ISO-3166)'/>

We would probably want to constrain participantRole so that only one addr element was present (and was mandatory), and had at least one element of city, county, state or country.  I would also recommend that country always be present, and that if city or county is present, that state also be present.  For disambiguation purposes, you might need to know which of the twelve New London's in the US your patient was recently in.

Some have suggested that location could be rolled up into a code, as I have shown above in participantRole/code.  While I agree that would make certain kinds of decision support easier, it is something that could be done within the clinical decision support module, rather than being specified within the EHR.  The Geographic Location Value set referenced above shows why this might be a problem, as it contains codes describing locations at different levels.

So, now back to the main point.  We quickly went through this model on the Structured Documents workgroup list service in less than three days.  It would take us several months to role this out as a new template.  We need a model of development and consensus building somewhat like what OpenEHR does for archetypes, allowing for quicker development and deployment of these sorts of artifacts.  I also think that this is the way some of these templates should be developed in the future. We should develop a model that can be approved through a general call for consensus, and then periodically, we can roll up several of these templates into a release which gets a more thorough review through the HL7 ballot process.

This would allow HL7 to be responsive to rapidly developing health issues, without having to make it something that we have to panic about.  Note that foreign travel is relevant only for some cases. There are plenty of other ways to be exposed to disease, including everyday activities like going to school or work, or shopping.  For that you might want to be looking at other information in the patient health record, such as their home address, and workplace and school contacts.  IHE also included entries for those contacts in XPHR.

   -- Keith

Wednesday, October 15, 2014

A Short and Sensual Sojourn

One day last week I took a ride on my motorcycle to pick up my daughter from school. Having recently moved into this rural neighborhood, I took to the back roads to explore. To ride is to be connected to the environment around you. The roads were narrow, winding and tree covered. Gleefully I followed them over to her school, absorbing all I could see, smell and feel. Combining the visuals of fiery fall foliage with the aroma of recent rain and fallen leaves, and the soft touch of cool fall air brushing by me, I almost reached a sensual nirvana. All too soon I arrived at my destination. After collecting my daughter, we reversed my original course back to our new home. She also marveled at our new surroundings. The more I explore this new place, the happier I am to have moved here. Why I made such a lifestyle shift was readily answered in a single and all too short ride, I realized, as I pulled into my space at the end of the driveway.

About this text: This was originally part of a homework assignment for my Scientific Writing class, which I then updated a bit. I enjoyed it and am still digging out of boxes, so there is no excess brain to write with for something else today. I promise there will be something with meat on it soon.

Thursday, October 9, 2014

Worth Waiting For

About 12 years ago I was to have given a sermon at my church.  In planning for it, I asked our rector how long a sermon should be.  He answered with this bit of wisdom: "It takes as long as it takes."  Of course, he didn't realize I was asking about what I needed to do next week, and was thinking I was commenting on the length of his sermon that week.  But the phrase stuck with me, and the next week, when he realized WHY I was asking, we had a good laugh over his non-answer.

It is now October 2014.  This time last year HL7 was hurriedly trying to put the final pieces together for C-CDA Release 2.0, so that we could get it out in time for regulation.  It's still not published yet, although it soon will be, and the reality is that we apparently didn't need it in such a hurry.  Recent discussions on HL7 FHIR and the CDA and C-CDA on FHIR projects indicate that the dates for these don't all line up for the DSTU FHIR Ballot schedule.  There's some discussion about whether or not we should delay it.

I for one am all for taking as long as it takes to do things right.  I'm a bit tired of rushing stuff out to ballot to meet deadlines that were made by people who don't necessarily understand real world healthcare provider upgrade and deployment schedules.  We have plenty of work to do, and the industry has gotten itself pretty convinced about the right way to go.  Now we just have to convince folks that it will be worth waiting for.

Thus ends my sermon for this day...


Wednesday, October 8, 2014

Assumed Ignorant

My internet was down for about an hour yesterday.  It could be readily traced back to a specific piece of hardware, and fortunately for me, I happened to have a replacement on hand that wasn't the same make and model that was causing massive internet outages all over the world.  Even when I upgrade, I hardly ever throw anything away.  I have at least three routers and a Hub sitting in my office, unused since they've been replaced with faster equipment.  So, once I knew what the problem was, I dug out my old Netgear Wireless router, reset it to factory defaults, and plugged it in to get us limping back along until Belkin could fix whatever it messed up.

The tech at Charter couldn't explain to me what was wrong, only that it was a problem with the Belkin router.  Belkin couldn't explain what was wrong, only that some software change had caused the problem.  My bet is that the server at Belkin that the routers used to ping to determine that they really had Internet access were either down, decommissioned, or renamed.

In trying to work through the problem with my Internet tech support guy, I ran into a problem that patients (especially chronic ones) have with their doctors.  I know more than your average Internet user about networking.  By the time I've called the cable guy, I've gone through all the standard Tier 1 fixes, sniffed the network if necessary, and have a pretty good idea the problem is NOT at my end. I tried to explain that to this guy, but he didn't have ANY training about how to talk to a tech savvy customer.  He only knows his scripts.  I've had doctor's like that too, who try to dumb stuff down for me because "It's too complicated."  I'd like to show them some of the code I've had to maintain in my life.

In any case, I wish there was something we could do about the attitude that customers or patients should be assumed ignorant until proven otherwise.  I think that there are some basic skills, such as being able to reset your internet box, fill up your tank, change and flush your oil and coolant, throw a breaker, or understand our health, and the healthcare system (such as it is) that should be part of everyone's basic education.  And I think the same thing goes for Physicians and technology!

When did assumed ignorant become the default, and why do we let people get away with it?

Monday, October 6, 2014

Life Flow

For the past few weeks I have been rearranging my life so that I could move. As we move into the new house, my family is redesigning our spaces and technology solutions to better fit our life.  The kitchen is not just about making and eating meals, it is about breakfast, lunch and dinner.  So now part of my kitchen is devoted to making the appliances accessible that we ALL use in the morning, from coffee maker to toaster oven to microwave in one part.  While another part of the kitchen is devoted to more intense meal preparation for dinner done by one or two persons at a time.  

My office which used to hold half our books now has over 90% of them.  The internet router, telephone base station, and main printer, which used to be spread throughout the house are all right next to me so that the "hey Honey, why won't the printer print?" (Or wifi connect, or phone dial) question need not be shouted across half the house.  I can watch the smoker outside from my desk. The exercise and entertainment centers can now be used together, synergistically.

There is so much stuff, we are still in the just get it out of boxes, get it to work stage in many places.   We'll rough out the life flow as we do that, and then fine tune it as we find the problems (afte a coffee spill it was noted that we probably want the marble topped sideboard under the coffee pot rather than the oak topped one).  This is real, rational and agile all at the same time.  I wonder if there isn't a lesson to be learned from this for healthcare.  Except that I don't know if most Physicians could live through the kind of chaos that roughing out and testing workflows would require.

Friday, September 26, 2014

Finance and Twentieth Century Medicine

I'm moving to the country in a few days, to a small farm about fifty miles from Boston.  The process of buying a house is rather complex, sort of like getting healthcare.  The next time someone mouths off to me about how the financial services sector has interoperability down pat, I am going to laugh so very hard at them.

1.  We transacted most of our data exchanges through e-mail and fax, with some telephone and web mixed in.
2.  Every data exchange was paper or PDF based.  Structured data?  I can hear the underwriter evilly laughing in the background.  Yes, please, send me your structured data so we can print it out and transfer it into our underwriting forms manually.
3.  Get me a quote and fax it... (On the hazard insurance policy).

Sure, that is interoperable... As 20th century medicine.


P.S. What the finance sector has learned is how to use interoperability to take THEIR costs out of the system, not MINE.  We should remember that for healthcare too.