Tuesday, October 21, 2014

JASON and the EHRnauts

I thought I was done with JASON and the EHRnauts for a little bit, when this query popped into my inbox via Will Ross over at Redwood MedNet.  He points to this bit of wisdom:

From the report:
To the extent that query capabilities are included in MU Stage 3, we are at an awkward moment in standards development: Older standards such as XDS/XCA are mature but inherently limited, whereas newer API-based standards are not yet ready for large-scale adoption. We believe it would be detrimental to lock the industry in to older standards, and thus, we recommend that ONC mobilize an accelerated standards development process to ready an initial specification of FHIR for certification to support MU Stage 3.
I love it when people raise the point about limits, without delving into what those limits are.  It always sounds so authoritative.  Yes, documents are limited.

Here are some of the limitations of documents:
  1. You can only operate on what appears within documents.  
  2. You have to have some idea about which documents you want.  
  3. When dealing with multiple documents, you have to deal with redundancy and ambiguity.
  4. Documents are coarser grained than some problems want to deal with.
There are also benefits to documents:
  1. A document can be operated on by a human using very little technology (Human Readability), or by a computer.
  2. Documents link each fact reported to an encounter or visit, a healthcare provider and and institution (Context).
  3. A document provides the complete record of the encounter or visit, not just individual parts that can be interpreted out of context (Wholeness).
  4. The content of a document can be retrieved at any point in time in the future in a way that is repeatable (Persistent).
  5. A document links data to the organization that gathered, uses and manages it (Stewardship).
  6. A document can be signed by a healthcare provider (Potential for Authentication).
Anyone who has studied CDA will recognize where these properties come from.

Now, as to the limits, all of these can be overcome, the question is who does it.  The fundamental organization of data in an EHR around information documented during an encounter isn't likely to change whether you look at a large grained document-centric approach, or a finer-grained data item-centric approach.

You'll only ever be able to find information that has been gathered, or the fact that it hasn't been gathered.  The document based approach means that you need to look at several documents to determine that for a time period, a finer grained approach means that the system you ask for that information must look at all data items in that time period.

You will always have to have some idea about what you want to ask for.  In the document-centric approach, that can be based on document metadata such as who, where, what or when.  Those questions are often asked at the first level of the physician's workflow in their search for more information.  Finer-grained approaches will allow more detailed questions to be addressed that come later in the evaluation of the patient: Did they have this test? If so what were the results? Was ____ ruled out?  When was the last time ___?

When dealing with multiple facts over time, you will have to deal with redundancy, ambiguity and disagreement.  It is quite possible in an EHR today to have one physician assert something, and another deny that same thing, and both may be correct, or they may conflict.  This is true regardless of whether the data items are accessed through coarse- or fine-grained mechanisms.  Documents increase the degree to which this occurs because of the wholeness principle, you get all of the relevant data about the encounter, not just a few small pieces of data.  But you should be able to readily resolve those issues, because you will always have them to deal with as soon as you have multiple data sources.  Documents just make that problem visible sooner, because each document can be (and often is) treated as a single data source, whereas it only shows up in fine-grained access mechanisms once you have more than one data source.

The key issue is that some folks want to get right down into the computer automation of tricky bits, which means that they often don't want what they consider to be the excess baggage of documents. Agreed, we need a better way, and the industry is working on it.

I also love it when I hear "lock in", because frankly, when something better comes along, people will use it, regardless of what the government says or does (consider how mobile has driven healthcare). In most cases, the best thing it can do is get itself out of the way ;-)

To say (as the JASON Task Force does) that "There is currently no industry- or government-led plan or effort focused on ubiquitous adoption of standardized Public APIs." is technically correct.  But let me ask you, where was the plan to adopt HTTP and HTML and CSS for the World Wide Web?  XML and Schema?  MIME and SMTP and POP for eMail?  If anywhere, it was in the minds of the creators of those standards and the implementers. There was no government program driving adoption.

Right now, HL7, CDISC, DICOM, IEEE, OpenEHR, and IHE have all rallied around FHIR as the way forward for a variety of different use cases (see for example IHE's Mobile Access to Health Documents effort).  Major vendors, national programs, industry consortia, and other organizations have publicly announced support for FHIR in products, programs and services currently being developed.  This kind of thing is nearly unprecedented in health care.  To come upon if after the fact and try to impose some US federally crafted plan to make it happen is just a bit ambitious don't you think?  After all, it worked so well the last time with Direct.

My advice is to tread carefully, as ONC has already been doing.  Offer support and assistance, encourage communication among different groups, maybe even fund some development.  However, I think HHS needs to avoid the arrogance of thinking that it could plan this much better than is already occurring naturally in the industry.

I leave you with these thoughts:  The Web took about five years to be widely used, and another five to really mature.  FHIR has been with us for a bit more than two years.  Rather than asking whether we can we afford to wait, consider if it will be worth it to rush.  It won't be too much longer.

-- Keith

P.S.  I was very impressed with the JTF report.  It was a very thoughtful response to the original work.

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:

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

      <content ID='sig-1'>one capsule daily</content>
    </paragraph>
  </text>
   ...
  <entry>
    <substanceAdministration classCode='SBADM' moodCode='INT'>
      <text><reference value='#med-1'/></text>
       ...
      <consumable typeCode="CSM">
        <manufacturedProduct classCode="MANU">
           ...
          <manufacturedMaterial>
            <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>
            </code>
            <name>Amlodipine 2.5 MG / Benazepril hydrochloride 10 MG Oral Capsule</name>
          </manufacturedMaterial>
        </manufacturedProduct>
      </consumable>
       ...
      <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>
        </substanceAdministration>
      </entryRelationship>
    </substanceAdmnistration>
  </entry>
</section>

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'/>
  </effectiveTime>

  <participant typeCode='LOC'>
    ...
  </participant>
</act>

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'>
  <time>
    <low value='Starting Date for this Location'/>
    <high value='Ending Date for this Location'/>
  </time>
  <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)'/>
    <addr>
      <city>...</city>
      <county>...</county>
      <state>...</state>
      <country>...</country>
    </addr>
  </participantRole>
</participant>

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...

   Keith


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.