Wednesday, November 3, 2010

The Circle Never Ends

Between mischeduling meeting, not scheduling meetings, being double-booked, and taking care of my daughter who has strep throat, I've been chasing my own tail quite a bit this morning.  Now that it is the afternoon, I've managed to settle down a bit.
One of the things that I did manage to get done this morning was arrive (late) at a meeting to discuss a Transfer of Care form being proposed for use in the state of Massachusetts convened by the Mass Health Data Consortium.
Now this truly is an interesting circle, or in my case, a vortex that sucked me in.
Massachusetts Transfer Form
ASTM Continuity of Care Record
 ►HL7 Continuity of Care Document
  ►IHE Exchange of Personal Health Record Profile
   ►ANSI/HITSP C32 Summary Documents using CCD
    ►ANSI/HITSP C83 CDA Content Modules
     ►CMS CARE Set Implementation Guide using HITSP C83
      ►Updated Massachusetts Transfer Form

I promised a review of the form based upon:
What is supported by the HITSP C32 Version 2.5
What is required under meaningful use
And I've also indicated what could be added based upon CDA

Page 1 Contact Information and Checklist

Patient Demographics


  • Name
  • Date of Birth
  • Gender
  • Address
  • Phone Number
  • Primary Language
Patient Contacts

  • Name
  • Telephone Number
Healthcare Proxy

Name

Telephone Number

Awareness of Patient Contact/Healthcare Proxy of Transfer

Whether a Healthcare Proxy has been invoked

Current Healthcare Providers
  • Name
  • Facility
  • Telephone Number(s)
Identification of Information Sent at Time of Transfer
  • Med List
  • Progress Notes
  • Pending Encounters and Labs
  • Advance Directives
  • Relevant Lab Results
  • Last History and Physical
  • Whether the Patient was sent with
    • Narcotics
    • Personal Belongings including glasses, hearing aids, dental appliances, et cetera.
  • Signatures of the: 
    • Attending Provider
    • Receiving EMS Personnel or Family Member
Page 2 Physician Orders and Nursing Assessment

Physician Orders

  • Advance Directives
    • DNR
    • DNI
    • DNH
    • Full Code
    • Reason for not completing this section
  • Heads Up -- Clinical Issues requiring special attention, et cetera
  • Reason for Transfer
  • Summary
  • Goals of Care
  • Diagnoses
  • Allergies
  • Vital Signs
Nursing Assessment

  • Mental Status
  • Functional Status
  • Pain Assessment
  • Immunization History
  • Devices/Special Treatments
  • Patient Risks (Falls, Restrained, Elopement, et cetera)
  • Isolation Requirements
Page 3 Patient Assessment

  • Treatment orders
  • Skin/Wound Care orders
  • Diet Orders
  • Insurance Information
  • Activities of Daily Living
  • Vision, hearing and Communication Ability
Page 4 Therapy and Behavioral Information

  • Restricted Activities
  • Weight Bearing Status
  • Physical/Occupational/Speech Therapy
  • Respiratory Care
  • DME / Medical Supplies Needed
  • Behavioral, Social and Family Issues and Interventions
  • Discharge Education Status
  • Signature of the Patient or representative acknowledging discharge planning
Page 5 Medication List


Page 6 Outstanding Tests and Encounters and Additional Notes

Page 7 Anticoagulation Orders and Wafarin Flowsheet

The above is just a preliminary analysis, I have to dig up the HITSP C83-based CARE implemention guide to see what they did because the C83 mapping is already done, and this new form is based on the CMS CARE Data Set.

What is pretty clear is that most of the information can be supported by a HITSP C32 document.  The real question is whether A) It belongs there, and B) how to best address the workflow requirements given what Meaningful Use is already requiring in the US.

This is not a 'Summary of Episode Note', rather it is a 'Transfer of Care Referral' document.  That would actually imply a different document type than is used for CCD.  There's a good reason to mark it as a different kind of document as well.  There will be millions of CCDs created in this state, for every patient visit where a provider can generate one in order to meet the requirements of meaningful use.  Do you really want providers to have to find the ones that are specifically for transfers among all the others?  Probably not.  CCD and C32 is a hammer, but this problem is not quite a nail.

The next issue has to do with alignment with the National program.  If providers are already going to be creating C32 documents electronically, and there are already requirements on their transmission, how should this problem be tackled electronically?

One way would be to divvy up the workflows so that they can work with what will be deployed at the national level.  Creating a new form that requires only that data not already required by our national program will augment that program, introduce a workflow that can, where necessary, be completed separately from functionality supported by systems certified for use under that program.  That form could optionally duplicate information found in the nationally required content.  In that way, the maximum number of healthcare providers can support the regional program without requirement them to further modify workflows that are part of a certified product.

That is in fact another challenge that institutions face.  You can think of this as being 'as simple' as modifying or changing product configurations to support the local requirements.  But if you do that, you've probably introduced enough change to features that have been certified by the supplier that you may need to consider self-certification of your system.

Vocabulary and workflow are other challenges.  I can find vocabulary that represents concepts like DNR, DNI, et cetera, in internationally recongized systems like SNOMED.  But those same terms have LOCAL definitions in law or regulation, and so don't mean the same thing as soon as you start operating across borders.  The Massachussetts form is very heavily influenced by a similar form in Rhode Island, but what happens if you get a Rhode Island form with respect to translation of some of these concepts.  The same is true for other concepts such as 'Healthcare Agent'. 

On the workflow side, when you create lists like this, the question I have to ask is how this impacts workflows of a wide variety of providers.  For example, while Mental Status and Functional Status are data sets that are captured at almost every nursing home and skilled nursing facility, and would be captured at the level of detail in these forms, that same information would never enter a pediatric workflow in the usual case.  It would be captured in the exceptional cases, but for the rest, information about for example, mental status, would have to be reported as 'Unknown', because it isn't part of that providers usual workflow.

The challenge for the Massachusetts Department of Public Health is to figure out how to align this work with the existing National Program, and do so in a way that introduces the least amount of disruption in the workflows of local healthcare providers.  Fortunately, Massachusetts is very well represented on both the HIT Policy and Standards advisory committees, and some discussion will hopefully be occuring with those members and people involved in this project.

When I spoke two weeks ago to a group in Pennsylvania, one of the important points that I made was to be aware of, and contribute to the national discussions.  This is especially true when trying to coordinate activities like this one.

One final note:  Ideally, the 'transfer of care referral note' should also be acceptable as a communication meeting the requirements of meaningful use.  That is not presently allowed at this time under the current regulations, because the document must be a HITSP C32 meeting specific requirements.  But those same content requirements could be met with more encounter focused CDA documents for H&P, Consults, Discharge Summaries, and Transfer of Care referrals.

For phase 2, I hope that the HIT Standards committee thinks about the wider context of clinical documentation, and how it need not all be about the C32.  After all, we are gifted with a whole toolbox when using CDA, not just a hammer.  If we look at the HITSP C83, instead of C32, we can communicate the same data, and support quite a bit more than 'patient summaries'.  That is in fact what we designed it to do.

FW: IHE Pharmacy Technical Framework Supplements Published for Public Comment

The latest batch of IHE Profile Supplements, this time from the IHE Pharmacy Domain are now available:


IHE - Changing the Way Healthcare Connects
IHE Community,
Pharmacy Technical Framework Supplements Published for Public Comment
The IHE Pharmacy Technical Committee has published the following supplements to the forthcoming IHE Pharmacy Technical Framework for Public Comment:
  • Common Parts document
  • Community Medication Prescription and Dispense (CMPD)
  • Hospital Medication Workflow (HMW)
  • Pharmacy Dispense (DIS)
  • Pharmacy Pharmaceutical Advise and Dispense (PADV)
  • Pharmacy Prescription (PRE)
These documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm.  Comments should be submitted by December 2, 2010 to the online forums at http://forums.rsna.org/forumdisplay.php?f=591.

Tuesday, November 2, 2010

How open should a standards project be?

David Tao asks on the Direct Project Blog:  How Open and Broad Should an Interoperability Project, like the Direct Project, Be? John Moerhke provided his response focusing on numbers (which for Direct seemed to be of a good enough size to generate the necessary code, and on process).  I want to look at it from a slightly different angle.

It's a great question, but I want to analyze it a bit further:  How are decisions about who gets to participate made, and under what rules of governance?  One of the very early complaints (and I know because I made some of them), is that the "rules" under which the Direct project operates are not clear, written down or or even developed through any sort of consensus process.

The goal of the Direct project was to support the "little guy" in the small physician practice, without even an EHR system.  If the bar is set to high, little guys won't be able to participate unless there is some other mechanism established to pull them in.

As David points out:
On the other hand, if an arbitrary limit is set (e.g., no more than 20 organizations) then a project might face credibility problems down the road due to lack of openness, and lower probability of people "buying into" and adopting specifications in which they could not participate.
The notion of openness is so important that the Federal government has public OMB circular A-119 which provides guidelines on use of and participation in the development of concensus based standards.

This circular defines a consensus standards thus (see the second link in the sentence above):
... A voluntary consensus standards body is defined by the following attributes:
  1. Openness.
  2. Balance of interest.
  3. Due process.
  4. An appeals process.
  5. Consensus, which is defined as general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments.

ANSI (The American National Standards Institute) publishes ANSI Essential Requirements which includes in its table of contents the following headings:
1.0 ESSENTIAL REQUIREMENTS FOR DUE PROCESS
1.1 Openness
1.2 Lack of dominance
1.3 Balance
1.4 Coordination and harmonization
1.5 Notification of standards development
1.6 Consideration of views and objections
1.7 Consensus vote
1.8 Appeals
1.9 Written procedures
   ...
I highlight that last point, because that is what the Direct project lacks, and before any limits are set on participation, what is needed are those procedures, and they surely ought to be agreed to by a consensus process.  I applaud David for ensuring that there was a forum in the Direct project to have this discussion...

So, Direct, and more broadly, ONC, if you want to play in the standards game, you should do so under the rules that have already been established for Federal agencies and for SDOs.

Monday, November 1, 2010

How can you be sure you have the right HIE solution?

I do have something else to say today, and it's about Wes Rishel's post: Surescripts Announcement Confirms Simple Interop Incremental Approach.

My frustration with Wes's response is not his clear appreciation of what Surescripts has done.  In fact, as a patient I too appreciate it.  It is with his first recommendation given in the Gartner Quick Take that he wrote last week:
HDOs that plan to deploy HIE to community physicians: Delay deciding on a solution, or choose one that can incorporate Surescripts if it is proven effective.
Wes talks about the challenges of setting up an HIE, and then throws yet another one at them.  Wait until a single vendor proves itself (a one to two year proposition), or figure out whether your current solution will be able to incorporate the technology they've chosen.  It's not even that he's provided the "wrong" advice.  He's simply written it in such a way that most people will have only two choices:  Wait, or trust what others tell you without being able to evaluate their answers.  As an analyst, one should really try to do more than just identify problems, the real work is to explain the solutions.

So, here's the nitty gritty from my perspective:

The Direct Project uses the same technology that e-mail uses to send information.  This is primarily SMTP and for security S/MIME.  These solutions and tools to support them are ubiquitous on the web, which is why it was chosen in the first place. If you cannot make something work with software that is this widely available, you need to find another line of work, or a different staff.

For anything more than a simple document, the Direct Project recommends wrapping the content in the IHE Cross Enterprise Documents Sharing for Media format.  That format is a ZIP file structured (alos ubiquituous) in a very simple way, with one additional file to store a metadata wrapper describing the clinical content in the files that you send.  That metadata wrapper supports health information exchanges that use the IHE XDS family of profiles.  In fact, The Direct Project also describes how systems which use one of these specifications, the IHE XDR profile to provide an alternative channel for communication.  The IHE XDR profile uses the XDS Provide and Register transaction to send the content and metadata.  The Direct Project demonstrated during the early development process the capability of a solution to take an XDR communication and forward it using the Direct protocol, and visa versa.

So, if you want to know whether the solution your HIE is looking at will support the technology used in the Direct Project, you need to ask whether the proposed HIE solution works with IHE XDS or IHE XDR.  And you need not just take someones word for it.  You can also find a list of solution providers who have tested their products against the IHE XDS specifications, IHE XDR Specifications, or the IHE XDM Specifications at IHE testing events.  These are the HIE solutions that are already poised to take exchange from beyond point to point push, onto the next level

Solutions which implement the recommendations made in The Direct Project specifications will be able to work with these HIE systems quite readily.  Given the popularity of the IHE XDS profile for use in Health information exchanges around the world, I quite expect that anyone who fails to account for these in any sort of Healthcare exchange is simply setting themselves up for failure.  I think the leadership at SureScripts has already demonstrated by their support of the Direct Project that they are smarter than that.

   -- Keith

Not much to say today...

If a picture paints a thousand words, then this picture has about an 86:1 compression ratio.
It may not be done, but it sure is close.  Feature freeze has been declared.  There shall be no new content without an appropriate ECO.  Now I throw it over the wall to QA ;-)

   Keith


Sunday, October 31, 2010

An analogy for Viewpoints

I was trying to explain something in the CDA Book, and in so doing came up with an analogy that may help explain the use of viewpoints in SAIF and RM-ODP.

There have been many times in my engineering career where someone would give me requirements for an object in a system.  After listening to the requirements, I would start breaking them down into the classes that the system would use.  Time and time again I would run into situations where the class I had created could be simply extended to support some new behavior in order to meet other requirements.  This is pretty normal in engineering.

Then I would go explain what I did, and the person who gave me the requirements would say "No, that has to be wrong, because Y is not the same as X".
"But,"  I would argue, "except for these extension points, they work exactly the same way."

And then we would sit down and look at it.  And lo and behold, we would see that we were looking at the same thing from two different viewpoints.  I was looking at it from an engineering viewpoint, trying to understand how it worked, and the other person was thinking about it from a business viewpoint, how it was used and managed. it would turn out that we were both right.

Let's take another example.  To an auto-mechanic, a cam-shaft, a transmission, an a differential are all different things.  But they are all made up of gears, and to a mechanical engineer, these could just be viewed as different kinds of gear-cases (I do realize I'm drastically simplifying this, but you should get the idea).

I used a shift in viewpoint to explain the acts in the HL7 CDA clinical statement model in the book, so that I could build from students knowledge of simpler things.  A substanceAdministration is like a procedure, for example, save that it has these extra things.  Given that they already understand the procedure class, I no longer have to explain all of the details of the substanceAdministration class again.  I can expect the student to make the viewpoint shift to the clinical aspects of medication administration independently from the data transmission aspects.

I wound up not using this analogy in the book, but only because I couldn't make it fit with what I had already written.  It's still an interesting analogy.

Saturday, October 30, 2010

A proposal for HL7 XML Extensibility

I'm in the process of finishing the CDA Book, and was writing the chapter on extensions.  As I was writing it, the following idea came up.

The HL7 XML Implementation Technology Specification, or ITS, defines how HL7 message elements are to be sent using XML.  Section 2.5 of the XML ITS: XML Structures (Release 1) specification allows for the include of extension elements.  The only real requirement is that they come from a namespace other than urn:hl7-org:v3.

As part of the best practices for CDA templates created by the Structured Documents Workgroup, we determined that:

  1. All CDA extensions should be RIM derived, and
  2. They should be placed where they would have been placed had the CDA standard included that RIM attribute.
This is a nice idea, but has some  unfortunate consequences when validating CDA content that contains extensions.  Each possible extension can appear in a different place in the CDA schema, and it becomes nearly impossible to modify the CDA schema to support validation of  CDA containing extensions. 

I propose a new rule:  All extension elements must appear after all content defined by the standard. This rule has a great benefit.  Take a look at the following revised definition for POCD_MT000040.ObservationRange for CDA Release 2:

‹xs:complexType name="POCD_MT000040.ObservationRange"›
  ‹xs:sequence›
    ‹xs:element name="realmCode" type="CS" minOccurs="0" maxOccurs="unbounded"/›
    ‹xs:element name="typeId" type="POCD_MT000040.InfrastructureRoot.typeId"
                minOccurs="0"/›
    ‹xs:element name="templateId" type="II" minOccurs="0" maxOccurs="unbounded"/›
    ‹xs:element name="code" type="CD" minOccurs="0"/›
    ‹xs:element name="text" type="ED" minOccurs="0"/›
    ‹xs:element name="value" type="ANY" minOccurs="0"/›
    ‹xs:element name="interpretationCode" type="CE" minOccurs="0"/›
    ‹xs:any namespace="##other" processContents="skip"
  minOccurs="0" maxOccurs="unbounded"
  ‹/xs:sequence›
  ‹xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/›
  ‹xs:attribute name="classCode" type="ActClassObservation" 
    use="optional" default="OBS"/›
  ‹xs:attribute name="moodCode" type="ActMood" use="optional" fixed="EVN.CRT"/›
  ‹xs:anyAttribute namespace="##other"/›
‹/xs:complexType›

This schema supports extension following that rule, and furthermore, the HL7 tooling can be modified to easily add these statements to any existing schema.  Thus, we can, with the addition of this rule, have our XML extensions, and validate the message too.