Healthcare Standards

IHE Pharmacy Technical Framework Supplements Published for Trial Implementation

2012-01-30T09:55:00.000-05:00

IHE Pharmacy Technical Framework Supplements Published for Trial Implementation

The IHE Pharmacy Technical Committee has published the following supplements to the forthcoming IHE Pharmacy Technical Framework for Trial Implementation as of December 31, 2011:

Community Medication Prescription and Dispense (CMPD)
Hospital Medication Workflow (HMW)
Pharmacy Dispense (DIS)
Pharmacy Pharmaceutical Advice (PADV)
Pharmacy Prescription (PRE)

These profiles will be available for testing at subsequent IHE Connectathons. The documents are available for download at http://www.ihe.net/Technical_Framework/index.cfm. Comments should be submitted at http://www.ihe.net/pharmacy/pharmacycomments.cfm.

IHE IT Infrastructure White Paper Published

The IHE IT Infrastructure Technical Committee published the following white paper on January 24, 2012:

Health Information Exchange: Enabling Document Sharing Using IHE Profiles

The document is available for download at http://www.ihe.net/Technical_Framework/index.cfm. Comments can be submitted at http://www.ihe.net/iti/iticomments.cfm.

IHE IT Infrastructure White Paper on HIE Published

2012-01-27T11:42:00.000-05:00

This white paper shows you how the IHE profiles work together to provide a standards-based, interoperable approach to health information exchange. If you are involved in an HIE, and want to understand the standards and technology that can be used to support information exchange, this is a good document to read. At 35 pages, it is a short document, but it packs a great deal of information that HIE CTO's and architects should know.

The white paper addresses four key technical challenges:

Sharing models, including push, pull (Query/Retrieve), and Federation
Patient Identity Management
Patient and Sharing Partner Discovery
Security and Privacy

Because it is focused on the technical infrastructure, the white paper does not address the content profiles that have been developed by a number of IHE domains which can be used with the technical infrastructure. That will likely be the topic of a future white paper from Patient Care Coordination.

-- Keith

IHE Community,

IHE IT Infrastructure White Paper Published

The IHE IT Infrastructure Technical Committee published the following white paper on January 24, 2012:

· Health Information Exchange: Enabling Document Sharing Using IHE Profiles

The document is available for download at http://bit.ly/IHEDocSharing. Comments can be submitted at http://www.ihe.net/iti/iticomments.cfm.

In Honor of Kay Hammond

2012-01-26T18:19:00.002-05:00

I usually never give away the recipient of the Ad Hoc Harley award, because that is part of the fun of it. But this one is different. Kay Hammond died yesterday. Kay is the wife of Ed Hammond, and a long time supporter of Ed's work at HL7. What I remember of Kay is her ballroom dancing with Ed at an HL7 reception, and her exceptionally strong support of him through the years. She was an exceptional dancer (as is Ed), and she loved to travel, often joining Ed at HL7 International working group meetings.

What Kay did in her life should help us all remember is that among all the volunteers who make the Health IT Standards happen, there are a number of people who didn't volunteer, but without whom, some of this work would never happen. They get to deal with long absences of their spouses several times a year (weeks at a stretch at times), sometimes going to sleep alone even when their spouse is home because they are up until impossible hours wrangling with some crazy deadline. But they keep the home fires burning, caring for children and managing their own careers at the same time while we are working on the standards. They willingly share their garage with stacks upon stacks of paper or computer parts, deal with missed birthdays, anniversaries and holidays with great poise, all for relatively little reward -- perhaps the occasional exotic (or more often, not so exotic) trip with their spouse who is only free some part of the time.

Please keep Ed and his family in your thoughts today as they mourn the passing of Kay. Remember also those in your own families who support you in your work in standards, as Kay always supported Ed.

This Ad Hoc Harley is awarded posthumously to

Kay Stuart Forrester Hammond

for her demonstration of support for

Healthcare Standardization

Thank you Kay. The award is virtual, but so now are you. God speed.

Please join me also if you wish in making a memorial contribution in memory of Mrs. Kay Hammond to Duke Cancer Institute supporting cancer research, checks may be written to the Duke Cancer Fund, and mailed to Duke Cancer Institute DUMC, Box 3828 Durham, NC 27710.

The XSLT document() function

2012-01-26T09:32:00.001-05:00

Yesterday, someone asked a question about how to address issues of translating a code to a display name on one of the the Structured Documents workgroup's e-mail lists. There's a technique that I've been using in XSLT for quite some time that allows me to access look-up tables very easily without having to embed translation logic in the XSLT stylesheet. Before I describe the technique, I thought I'd share some of the various uses for it:

Code translation. Often you will have codes in a one code system that need to be translated into codes from another code system. This technique allows you to look up the translation. I've used this to translate local codes to codes from standard vocabularies for:

Unit translation from ANSI+ to UCUM
Local codes for problem severity to SNOMED codes for severity used in the HITSP C32
Local codes for problem status to SNOMED codes for problem status.
Local codes for problem type to SNOMED codes for problem type.
Local codes for vital signs to LOINC codes for vital signs.

Display name lookup. Closely related to #1 above. Often times, I have a standard code, but not the display name associated with it. I can use this technique on small value sets (less that 1000 codes) to look up the display name (this is the use case for the problem presented on the list).
Mapping from an identifier to a web service end point. You can use this technique to map from:

The home community ID to an XCA Web Service address
A DICOM AE Title to a WADO Web Service endpoint.

Validating against a dynamically changing rule, such as the validation of a code element against the current version of a vocabulary or value set.

The basic technique is to create (or have access to) an XML document resource which you will use in your stylesheet. To declare this resource, you do something like the following:

<xsl:variable name="myDocument" select="document('mydocument.xml')"/>

This creates a variable which can be used in an XPath expression subsequently in your XML. In the use case the querant posed, the issue was how to get a display name for a language code, to that the patients preferred language (expressed as a code) could be displayed in the UI. The patient's language preferences are stored in the patient/languageCommunication/languageCode/@code attribute.

The following XSLT fragment shows a template that will return the display name of the patient language by looking it up through an XML document.

<xsl:variable name="langs" select="document('lang.xml')"/>
...
<xsl:template name='patientLanguage'>

<xsl:variable name='lang'
select='//patient/languageCommunication/languageCode/@code'/>
<xsl:variable name='mappedLang' select='$langs//language[@code=$lang]'/>
<xsl:choose>
<xsl:when test='$mappedLang'>
<xsl:value-of select='$mappedLang/@displayName'/>
</xsl:when>
<xsl:otherwise>Unknown</xsl:otherwise>
</xsl:choose>
</xsl:template>

The same technique can also be used to access a resource that is created dynamically through a RESTful web-server end-point. I demonstrate one use of this technique in the post on Values Sets and Query Health.

Another use for this technique is to check value-set conformance inside Schematron rules. If you have a requirement that code/@code come from a particular value set, you can write a rule that accesses a web resource based on the value set, as in the following example:

<rule context='*/cda:templateId[@root = templateIdentifier]'>
...
<let name='code' value='cda:code/@code'/>
<let name='valueSetDoc' value='document("https://example.com/RetrieveValueSet?id=1.2.840.10008.6.1.308")'/>
<assert test='$valueSetDoc//ihe:Concept[@code = $code]'>
The code/@code element must come from the XXX Value Set (OID: 1.2.840.10008.6.1.308)
</assert>
</rule>

The use of external XML data files is a very powerful feature of XSLT. Combining that use with dynamically created XML resources through web services makes it even more capable.

A Hex upon all your charsets

2012-01-25T11:02:00.001-05:00

Today's post results from a question someone posed to me about how to render XDS-SD content using an XSLT stylesheet. If you've tried to do this for application/pdf content, you've probably already discovered that there is no way* to use an XSLT stylesheet to render your content on either the server or the client side.

The critical issue for this morning's querant was how to render text/plain content, and that can be done (see this post), provided that you have a way to access a procedural language from your XSLT stylesheet (which almost all production level XSLT transformers do). The solution is platform specific but is generally applicable. In fact, if you are using Xalan, the solution works across most Java implementations and Xalan versions. A C#/.Net solution is certainly possible along the same lines as the one I suggest.

But there is a challenge here, and that is determining the base character set of the text/plain content. When that content is purely ASCII, it is likely to work on any system, because almost all character sets use the same first 128 characters as ASCII does (the main exceptions are EBCDIC, which you may never encounter, and UTF-16 or its older sibling UCS-2). The problem only occurs when someone base-64 encodes text that contains extended characters (like any of these Å æ ç é í ñ ö ß û). At that point, character set becomes critical for correct rendering.

Let's take Å for example. In ANSI/ISO-8859-1/Windows Code Page 1252, this character is Hex C5, and is encoded in a single byte. In UTF-8, this character would be encoded in two bytes, the first being Hex C3, and the second being Hex A5. In UTF-16 or UCS-2, this character would be encoded in two bytes, the first being Hex 00, and the second being Hex C5, or Hex C5 followed by Hex 00.

These bytes will render in interesting ways on systems that aren't handling them right. For example, the UTF-8 character represented by the sequence C3, A5 will show up as Ã¥ in a system expecting ANSI/ISO-8859-1.

So, this matters for display purposes, and you need to know what character set the text/plain data was represented in. So how do you figure this out? The first thing to do is look at the IHE XDS-SD profile, but it doesn't say (because that's a property of the HL7 CDA standard that IHE didn't profile in XDS-SD). nonXMLBody/text is of the ED data type in HL7. When we look there, we see that data type has the charset property, so all we need to do it get that, and we're all set, right? Wrong.

Unfortunately, while the data type covers it, the XML Implementation of the ED data type does not. It says:

charset is not explicitly represented in the XML ITS. Rather, the value of charset is to be inferred from the encoding used in the XML entity in which the ED value is contained.

The problem with this statement is that it is entirely true when the ED data type is not base-64 encoded, it is false when it is so encoded. At that point, the encoding is of text/plain content that is entirely independent of the character encoding of the XML document. In fact, the character encoding of the XML document can change independently and without any disruption of the XML content (because XML is Unicode, no matter how the document is transmitted). But the base-64 encoded text/plain content will not change its encoding because the characters are now those of the base-64 encoding. The encoding of the base64 characters can change, but that won't change how the content they are encoding will decode. Confused? Yeah, me too.

My hope was this would be corrected in Data Types R2 ITS and/or Data Types R1.1, but apparently its been totally missed.

My advice for now: If you are a content producer of XDS-SD documents using text/plain content is to use only ASCII characters in your content if you can. I'll bet more than 95% of the documents using that format do that today in any case. The long term solution will be for IHE to apply a CP to XDS-SD that says that for text/plain, the content must be stored in the _____ encoding, where the blank will be filled in after a good bit of discussion. I would expect that UTF-8 would be a strong contender. And in HL7 we need to fix the ITS, because charset on ED needs to be present when it is base-64 encoded.

If you are a content consumer, when you decode the text, look for any non-ASCII characters in it. If there are some present, you are going to have to guess at the encoding. If not, you can just stick with ASCII.

In the meantime, all I have to say is ?@*#$%~!

-- Keith

* Actually there is a way described here, and it uses the data: URL described in RFC 2397, but this is not supported across all platforms and media types (IE for example, does not support the data: URL for all objects, only images).

Balance is of the Essence

2012-01-24T10:43:00.002-05:00

Time is of the essence.

In a contract this means that failure to complete the work by the agreed up deadline constitutes a breach. Deadlines enable cost controls and ensure predictability. In yesterday's post I talked briefly about Federal Engagement in Standards development. One of the key phrases used in communication at the Federal level about their standards strategy is "Impatient Convener". There are a number of other activities where speed seems to be essential.

A counterpoint to this focus on "speed" is doing it right.

There is never enough time to do it right, but there's always enough time to do it over. -- Jack Bergman

Make Haste Slowly - Anonymous

Only that which is well done is quickly done. -- Augustus

How do you balance the imperatives of time and quality? In the three-legged triangle of project management, you must be able to balance resources, quality and functionality. When any two are fixed, the other must be variable.

According to the triangle inequality (|A| + |B| > |C|), there are collections of triangle sides that don't work.

We (standards professionals) have to be careful with how we address issues where time is of the essence. A failure to meet the deadline is certainly a problem, but even worse would be a failure to deliver on quality or worse yet, to deliver something that doesn't add the necessary value.

What is truly essential to success is balance.

On Principles for Federal Engagement in Standards Activities to Address National Priorities

2012-01-23T11:43:00.000-05:00

The following showed up in my inbox this morning.

In general, I think this is great policy advice, especially the section on Agency Responsibilities starting at the bottom of page 3.

What I'd liked to emphasize is this statement found on the middle of page 2:

To accomplish these objectives, the Federal Government, as directed by Congress, is taking a convening role to accelerate standards development, by working closely with domestic and international private sector standards organizations.

I work closely with SDOs, and I know what it means to do so. I cannot give the Federal Government high marks here, although I have to admit that they've gotten better over the last year. If they mean to sustain the good work going on in the S&I Framework activities, they'll have to do better. The S&I contracts will end, and that means someone will have to maintain the outputs.

I hope we won't have another situation like the one where HITSP wound up orphaning documents that were the result of more than 100,000 hours of community expertise. We really do need to figure out how to get to level 5 in this country.

New MeaningfulUse Rule will likely impact Stage 1 Criteria

2012-01-20T00:52:00.000-05:00

Most Health IT folks today are concerned about Meaningful Use for Stage 2, but they should also be concerned about stage 1 as well. Under new Federal Regulation for meaningful use, it is certainly possible that the definition of stage 1 meaningful use can change. As the Meaningful Use Standards final rule stated:

The stages of criteria of meaningful use and how they are demonstrated are described further in this final rule and will be updated in subsequent rulemaking to reflect advances in HIT products and infrastructure. We note that such future rulemaking might also include updates to the Stage 1 criteria.

The real question for many is what that will mean for vendors implementing products, and providers attesting to meaningful use at a particular stage. For vendors, it is very clear that EHR products will need to be certified against the new criteria as soon as possible, because again, according to both the final rule for temporary certification and for permanent certification:

Regardless of the year and meaningful use stage at which an eligible professional or eligible hospital enters the Medicare or Medicaid EHR Incentive Program, the Certified EHR Technology that they would need to use would have to include the capabilities necessary to meet the most current certification criteria adopted by the Secretary at 45 CFR 170 subpart C.

When Stage 2 becomes effective (anticipated for 2014), providers will need to upgrade to EHR technology that is certified to that criteria, regardless of whether they are attesting to Stage 1 or Stage 2 of Meaningful Use criteria. The new incentives rule will contain criteria defined for those organizations who are a “Stage 1” Meaningful User and for those who are a “Stage 2” Meaningful User. Stage 2 users will have more criteria to attest to, and for those capabilities already existing in stage 1, a higher degree of use of those capabilities (e.g., A higher percentage of orders performed electronically at stage 2 than stage 1). Regardless of whether they are at Stage 1 or Stage 2, both kinds of organizations will have to use EHR technology that has been certified to support the Stage 2 criteria.

The table below shows the current Stage 1 standards and the stage 2 standards that I’m currently projecting for the new Meaningful Use Standards rule.

	Stage 1		Stage 2
	January 2011 – December 2013		January 2014 – ?
Purpose	Standard	Implementation Guide	Standard	Implementation Guide
Generating a Clinical Summary	CCD 1.0	HITSP C32 V2.5	CDA R2.0	CCD 1.1 (Stage 1)
Generating a Clinical Summary	CCR			CDA Consolidation Guide (Stage 2)
Viewing a Clinical Summary	Both CCR and HITSP C32 V2.5		CDA Consolidation Guide, CCR and HITSP C32 V2.5
Immunizations	HL7 V2.3.1	CDC 2.3.1 Guide
Immunizations	HL7 V2.5.1	CDC 2.5.1 Guide	HL7 2.5.1	CDC 2.5.1 Guide
Public Health Lab Reporting	HL7 V2.5.1	ELR Guide		ELR Guide and/or updated LRI Guide
Disease Surveillance	HL7 V2.3.1	No Guide Selected
Disease Surveillance	HL7 V2.5.1	No Guide Selected	HL7 V2.5.1	PHIN Guide

The new certification criteria for Stage 1 and Stage 2 will almost assuredly require use of new standards, and some standards previously acceptable will be dropped. The biggest challenge for many will be the change from CCR/HITSP C32 V2.5 to CDA® and the CDA Consolidation Guide, and that is what this post will focus upon. The key question is how systems conforming to the new standards will address the issue of the legacy data stored using either CCR or the HITSP C32 2.5.

Fortunately, ONC cleverly created two separate criteria for the clinical summary. The first was generating (and subsequently transmitting) an electronic summary. ONC allowed two formats for that capability: CCR or the HITSP C32 2.5, of which a provider need choose only one (but could support both). However, all systems must support viewing both (and need not do any more than that).

In order to support viewing of legacy documents, I fully expect that the new certification criteria will require certified systems to support viewing of legacy content. I also expect it to support viewing of any document found in the CDA Consolidation guide. With the exception of the Unstructured Document, viewing is not a challenge. IHE implementers have learned over the years to sign up for the “Content Consumer” actor for all PCC Profiles of the HL7 CDA if they can support content consumer for ANY document because you get it nearly for free. Most implementations transform CDA to HTML or XHTML and display the results. A good stylesheet handles all content equally well. Thus, it is reasonable to ask these systems to support viewing of any CDA based content under the new certification criteria. If you can view one kind of CDA document using an XSL stylesheet, you should be able to view many. There are numerous sources of code for CDA stylesheets freely available.

The Unstructured Document in the CDA Consolidation guide needs more work for viewing but there are plenty of viewing technologies available to support its requirements as well. There's another whole post that I will devote to that topic.

On the creation side, I expect that systems must be able to create content using the CDA Consolidation Guide. A stage 1 meaningful user might only be required to generated CCD 1.1 documents, but a Stage 2 user might be required to support not just CCD 1.1 but could be permitted or even required to generate other document types in the CDA Consolidation Guide (e.g., discharge summary).

Where backwards compatibility becomes a problem for organizations that are exceeding the meaningful use requirements, such as the Beacon programs. Those organizations have been working with CCD 1.0 and will now need to support CCD 1.1. That is one of the penalties of getting out in front. The key for those programs will be adapting their technology that uses the HITSP C32 V2.5 to use CCD 1.1. It may be a PITA, but this is really not a hard challenge.

Given the origins of CCD 1.1, it should certainly be feasible to transform from CCD 1.0 to CCD 1.1 automatically. While there are some incompatibilities between the two versions, a valid HITSP C32 Version 2.5 will almost certainly transform into a valid CCD 1.1 for the purpose of importing, reconciliation, et cetera. The transition to CCD 1.1 even prior to its adoption as a certification requirement could be done within the context of the single system that makes use of it, enabling innovators to take advantage of it before it becomes a requirement.

Shortly HL7 will be releasing the latest CDA Consolidation template database, and the Model Driven Health Tools project will be releasing a version which includes the CDA Consolidation rules. Those two model driven tools will provide engineers (including me) with a lot more information than we’ve ever had previously to make the transition to the new format easier.

-- Keith

Microdata Shot Down but still flying for CDA

2012-01-19T00:46:00.001-05:00

Graham Grieve shot down my HTML5 + Microdata proposal Tuesday with a well-placed comment on the ease of writing micro-data [or actually the lack there-of]. I’m borrowing from Calvin Beebe’s suggestion (he’s an HL7 Structured Document Workgroup Chair) that there be a way to transform back and forth between formats to support some of the capabilities provided by HTML5 + Microdata, and still maintain the ease of writing (and validating) CDA documents in XML.

While, I’m still convinced that we need to use HTML5 for the text portion of the document, and still really like what Microdata does for you with the document in the browser. But now I acknowledge that we will probably need to allow HTML5 and some RIM (or perhaps FHIR [pronounced Fire]) based XML representation of content. Whether it be RIM-based or FHIR-based, call it HL7 XML and lets move on.

In order to resolve Graham’s issue though, I’ll need a way to translate back and forth between HTML5 + HL7 XML and HTML5 + Microdata. The only thing I can count on being in common between FHIR and another HL7 XML format is that they are XML, so I’m just going to work on Microdata to XML and back transformation.

Here is some of my initial thinking on the transformation:

The transformation may be guided by an XML schema, but this is not a requirement.
Transformation to Microdata and back should be possible.
The itemprop attribute represents the name of the element or attribute. When the value of itemprop begins with an @ character, it will be represented as an attribute in the XML. When it begins with any other character it will be represented as an element. Since @ isn’t a legal name start in XML, this seems like it should work.
The itemtype attribute must represent the Schema type of the element or attribute in the form URL#typename, where URL is the namespace URL associated with element or attribute in the schema, and the typename is the name of the complex or simple type in the schema.
When there is no namespace URL associated with the Schema, the URL shall be TBD.
Properties which are represented in the XML as attributes are given names of the form: @name where name is the attribute name.
An attribute can be assigned more than one property value if its schema simple type is defined using .
Properties which are represented in the XML as elements are given names of the form: name where name is the element name.

What is cool about this transformation is that I also get (for free), a JSON and RDF interpretation along with the Microdata representation of the machine readable metadata.

Associating an XML Document with an HTML 5 element as microdata without an Schema is pretty easy. You traverse the DOM of the XML Document an:

Start with the HTML 5 element to which the XML document is to be associated as Microdata.
Add itemscope to the HTML 5 element.
Add itemprop to the HTML 5 element using the name of the element.
If there is an xsi:type attribute associated with the element, set the itemtype to be the namespace URL for the type, followed by # followed by the type name.
For each attribute of the element, add a new item to the item associated with the HTML 5 element. That item will have an itemprop value of @ plus the attribute name. Set itemValue to be the value of the attribute.
For each child element, add a new item to the item associated with the HTML 5 element. Recurse at step 1 above.

There are some details still to be worked out, like the tricky bits of Schemas without a namespace (because the itemtype would become #typename), but not to hard even for a freshman programming project. Reversing this transformation is just little bit harder, but not impossible. I’ll be working out the details a bit later this year, and leave it as an exercise for the reader until then. If you figure it out, do let me know.

NwHIN open to Non-Federal Partners

2012-01-18T23:47:00.001-05:00

This showed up in my inbox today... it is a long overdue and welcome change. As I read it, it means that organizations that aren't contracting with the government can take advantage of the NwHIN in the US.

A key goal of the HITECH Act is to enable the secure exchange of health information to improve health and care. ONC, its Federal partners, and other stakeholders have been working through many programs to achieve this goal, including work on the nationwide health information network (NwHIN), the NwHIN Exchange, and the Direct Project. Until now, participation in the Exchange has been limited to Federal agencies and outside organizations that have contracts, grants, or cooperative agreements with them. However, with the evolution of both the NwHIN and the Exchange, ONC has determined that this limitation is no longer needed. Participants who currently participate under contracts, grants, or cooperative agreements can continue in that capacity, and when those formal relationships expire, their signature on the Data Use and Reciprocal Support Agreement (DURSA) is sufficient (along with other specified requirements). New entities wishing to join need only sign the DURSA and fulfill other requirements. This is effective immediately, and the number of new participants is expected to grow steadily over the course of 2012. This is an important step in supporting wider health information exchange for Meaningful Use and broader national goals for better health and health care.

Mary Jo Deering, Ph.D.

Senior Policy Advisor

Office of the National Coordinator for Health Information Technology

U.S. Department of Health and Human Services

300 C Street, S.W., #1103

Washington, DC 20201

A National Standards Maturity Model

2012-01-17T09:52:00.000-05:00

Rene Spronk had a great post on the HL7 Affiliate Life Cycle a few weeks back. Yesterday Catherine Chronaki displayed a simple slide based on that model at the HL7 Working Group meeting. While Rene talks about it from an HL7 Perspective, I think about it from a national perspective. There are essentially five levels in Rene's model:

Raising Awareness
Creating Consensus Based Localization
Paid Development
Official Endorsement
Standards Collaborative

So far, only Canada is at level 5. The US through Meaningful Use is sort of at level 4 for endorsement of HL7 standards, and the ONC S&I Framework is certainly a level 2 activity, if not officially acting as an HL7 Affiliate.

The S&I Framework contracts (there are at least 10) will eventually end. There are a lot of activities which have produced outputs that still need maintenance (e.g., the Clinical Element Data Dictionary). One of the tasks for the S&I Framework is to establish a long term, public-private mechanism to sustain these activities, which could push the US to level 5.

When I think about all the national standards activities impacting the US:

S&I Framework (US Localization)
IHE USA (US Deployment and Testing)
SCO (National Coordination)
US TAG to ISO TC215 (International Coordination)
HIMSS Interoperability Workgroup
NCPDP (eRX)
X12N (Insurance and Payment)
NeHC (Education)

And several of the International ones:

It becomes pretty clear that we need a US Standards Collaborative. Here are some of my thoughts on it from two years ago.

Blacking out for SOPA Script

2012-01-15T23:57:00.001-05:00

Tonight I thought I would write a little script to black out this site on January 18th in protest against proposed US SOPA legislation. After about 5 minutes of research, I found the work that someone else had done and freely shared on the Internet. This is all it takes:

<script type="text/javascript" src="http://js.sopablackout.org/sopablackout.js"></script>

If you are running Blogger (as this site is), you can simply insert this code inside an HTML Widget that appears on your blog page on January 18th, and take it down later.

Feel free to pirate this page for your own use.

Give it to ME

2012-01-13T17:03:00.001-05:00

I've been reading quite a bit about all of the consumer oriented mobile health apps that have shown up lately. There's been a lot of buzz around this especially given the recent Consumer Electronics Show that just concluded (thankfully). There's also been quite a bit of discussion about a recent mobile health app that works with Health Vault.

All these apps are simply creating new mobile silos of information, or worse yet, requiring us to go through some third party cloud storage in order to manage and view it. I want my damn data and I want you to give it to ME so that I can analyze it. It's my health. Let me do with the data what I want easily, without having to hack my tablet, or use your website. At the very least, give me the ability to export the data to a spreadsheet.

Patients (and consumers) want to use a variety of different applications. We want to be able to collect that data and do stuff with it. Right now, I've got two separate apps, one to track my weight, and the other to track my blood pressure. In order to see the impact of one on the other, I've got to go through quite a bit of gyration just to put it together in one place.

Blue Button

2012-01-12T16:01:00.000-05:00

Chris W. brings up Blue Button on the Ask me a Question page, and a few weeks ago it popped up again into my radar screen. In case you've been in hiding for the past year, Blue Button is the name of a VA initiative to enable vets to download their clinical information in an ASCII text format from the VA patient portal MyHealtheVet. It's based on a Markle Foundation specification which has gotten quite a bit of attention.

Recently the Office of Personnel Management sent a letter to health plans participating in the Federal Employee Health Benefit Program (FEHBP). I found an interesting quote in the letter (I underlined the interesting part):

Supplying your members with the simple, low-cost and readily available Blue Button function will strengthen your contractual HIT obligations under FEHBP, align with the Meaningful Use standards laid out by Health and Human Services (HHS), and most importantly, empower your members to know their health information and make informed choices based on that information.

According to the letter, you would assume that you could download the records in the electronic standard formats suggested by HHS under Meaningful Use. But wait, the Blue Button specification is just ASCII text. It doesn't follow that standard at all, and many provider and payer organizations have already implemented according the HITSP C32 Version 2.5 (one of the two allowed standards under Meaningful Use Stage 1). Sometimes I wish the left hand and the right hand would communicate a little bit better.

Chris's main point is this (and I quote):

... it occurs to me that the effort is promising (for the intended use cases) precisely because of the standardization that HL7 has been driving behind the scenes. That is, the tag sets and value formats (and vocabularies) will have a fairly high level of consistency across organizations right out of the box because of their prior work on adopting a variety of standards internally, and especially HL7 standards

In fact, there's an HL7 project which is working its way through channels to create an XSL Stylesheet that will translate the semantically interoperable, Meaningful Use conforming HITSP C32 into the Blue Button format. Structured Documents approved it today, and it goes next to the steering division and then the TSC for final approval.

The scope of the project is to:

... produce a sample XSLT schema and background text on usage that will transform a CDA R2 CCD file into a U.S. Department of Veteran Affairs (VA) Blue Button ASCII text file.

It's likely going to have to make some sacrifices to fit within the specifications required for Blue Button, because there's more that you can say and do in CDA and CCD that Blue Button accounts for.

From my perspective, Blue Button is beneficial to patients, but not as big a step forward as it could be. (my S4PM friends may want to disown me for saying so, but hey, that's the way I feel). I'd much rather spend my energy on CDA Release 3 and HTML 5.

Given the importance of this project, I will be paying attention to it, and Chris is so right. Because of all the work that has already been done in CCD, this will be pretty easy. I just wish I could get some focused time on what will really move things forward.

Logistic Growth of EHR users under MeaningfulUse

2012-01-10T15:34:00.001-05:00

Logistic Growth Curve (courtesy of Wikipedia)

Students of economics will likely be familiar with the logistic growth curve. The curve has been used to model population growth, in modeling of stochastic processes and adoption of new technology. The early part of the curve is nearly exponential in the early stages, then moves to linear, and finally into exponential decay.

Recently, HHS released data on Meaningful Use attestations (through November of last year) on Data.gov. Brian Ahier posted a couple of extractions from this data earlier today. The data includes the following elements:

Variable Name	Definition
Vendor Name	Name of EHR vendor
EHR Product Name	Name of EHR product
EHR Product Version	Version of EHR product
Product Classification	Whether product meets all Meaningful Use requirements (Complete) or meets only part of the Meaningful Use requirements (Modular)
Product Setting	Practice setting for which product is designed for (Ambulatory or Inpatient)
Attestation month	Month that the provider successfully attested to MU
Business State/Territory	Business location of provider who successfully attested to MU (state/territory)
Provider Type	Whether attestor was an eligible professional (EP) or eligible hospital (Hospital)
Specialty	Specialty or provider type
Program Year	Year of EHR Incentive Program
Payment Year	Payment year of EHR Incentive Program
Program Type	Whether the attestor registered under Medicare or Medicare/Medicaid
ID	Unique ID for each Attestor

I put together a quick pivot chart report which showed the number of attestations by month for Meaningful Use, and looked at the growth trend. Here is how it looked:

And here is the raw data for this chart:

Month	Attestations
4	506
5	812
6	1045
7	1461
8	2268
9	3774
10	5754
11	7341

What this chart clearly shows is that we are still in the exponential growth stage for attestations. I found some information on logistic curve fitting data. It required an estimation of the saturation point for the population, so I looked up the number of physician practices from Wikipedia and applied it to the model. Given the the disparity between EP attestations (21,461) and Hospital attestations (1,500), I figured that an estimate of 250,000 was sufficient.

What I wanted to find out by this was when MU would be "done" (i.e., CMS would be "saturated" with attestations), and my results were rather surprising. So I went back and checked it again with two other estimates (125K and 500K). Then I took the 95% confidence interval on my low and high estimates. I plotted it out so that you could see the range of possible answers here:

What this shows me is that by mid-year of 2012, we'll be halfway to saturation, and by the end of 2013, we'll have reached saturation. And if I'm too high on my estimate of providers, it will be by October of 2012, and if I'm to low it will be by October of 2013.

Now, my 95% bands were on the transformed linear equation, so I don't know how that impacts things with respect to confidence bands (I could figure it out, but I'm not that deeply interested). What this tells me is that Meaningful Use, rather than being "off schedule" appears to be ahead of schedule. I still don't know if I believe that.

One thing this model doesn't account for is how many providers attesting were already EHR users, and so were ready to attest, vs. those that have yet to adopt. I suspect that the market is just a bit more complex than a simple logistic curve can account for, but even if it is, there's still another whole year before "Meaningful Use" is over using the figures I went with. I'd stick with the "ahead of schedule" estimate at this point.

So, 2012 should see EHR adoption rates at several multiples of the current rate. We'll look at the numbers again when they've released new data to see how things are going.

The Characters in a HealthIT Standards Meeting

2012-01-10T09:56:00.001-05:00

I'm headed off to the HL7 Working Group meeting next week. Shortly after that I'll be headed to an IHE meeting to discuss several profiles. While I won't be there this week, a lot of my standards buddies are in blustery downtown Chicago at the IHE Connectathon. For fun, I drew up a short cast of characters, aggregating characteristics of people I know in the Health IT standards space. When you start participating in standards meetings, you'll meet several of these characters too.

Venerated Ancient: This one has been around since dirt. They started the organization, has led it one or more times as chair of the board or some other exalted title. They've chaired the same committee for umpteen years. When they speak, everyone listens and makes noises of agreement. The venerated ancient can be a very strong asset when they are in your corner, or a challenging opponent when they are not.

Historian: This person has also been around a long time (perhaps even as long as the venerated ancient). They've often led the same committee for umpteen years. Their memory is like a steel trap. They remember every conversation, every meeting, and the rationale for every dot and twiddle in the specification. A very important thing about the historian is that they remember not only the reasons why, but also what the alternatives were, and what the problems were with them. The historian is your go to person to understand why something was done a certain way some number of years ago.

Quiet One: Also known as The Listener. This person attends most meetings, but is rarely heard from. They listen deeply, and their comprehension is astounding, but rarely will you find evidence of it, because they rarely speak. When they do, you better listen, because it will likely be profound.

Speed Talker: This member's mouth can barely keep up with their brain. You listen to them and it's like listening to an auctioneer. It is very clear that they have a significant idea to contribute, but neither you, nor anyone else can quite get to it. The best thing to do is listen, wait until they get to the end (and be careful that it wasn't just a breath) and then ask them questions. You don't want to derail the train of words (but more like a pogo-stick of thoughts). Give them a change to go back and explain how they got from A to Z, and you'll often discover some really interesting connections in between.

Reconciler: Consensus is extremely important to this person. When a contention arises, they need everyone to be happy, even when there are people who are so diametrically opposed to on solutions that it is clear their won't be general agreement. Some days, you just need to reconcile the reconciler to the fact that this problem doesn't have a solution that will make everyone happy, but other days, they can perform a great service by ensuring that all parties remain engaged.

Perfectionist: "That's not right!" they'll tell you, and then tell you exactly what's wrong with what you've just proposed. When you examine their logic, you will see that they are correct, but when you examine the number of times that this particular situation comes up, you will discover that it is so far into the weeds that you need a machete to find it. The perfectionist can find often obscure reasons why what you propose will fail. Ignore them at your peril, but do not follow them slavishly, as that has perils of its own.

Methodologist: The methodologist wrote the book (or perhaps the standard) on how you should do it. If you don't follow their process, you clearly don't get it. The methodologist and the perfectionist are often confused for each other. The true test of the methodologist is that they'll insist that there is only one true way, even when the perfectionist gives them evidence otherwise. When you want to know how to do something, the methodologist can tell you, often in excruciating detail. Methodologists are great sources of information about how to do it, but unlike historians, they are unlikely to remember what the alternatives were.

Academic: This one is a recognized expert on X, has more initials after their name than you can count, and insists that you use them. In discussions, they'll bring up obscure papers you've never heard of written by people you don't know in journals you don't have access to in support of their arguments. Or even worse, papers they've written themselves. The academic brings in a wealth of information that you wouldn't normally consider, some of it is even relevant.

The Lost Soul: This person either didn't read the agenda, doesn't know what the workgroup is about, or what the effort currently being discussed is intended to accomplish. They'll talk for a few minutes using some of the right words, but clearly not understanding the definitions in the same way as others in the work group. Lost souls can become great contributors once they've been given the right information, but they can also send discussions down into rat holes. A lost soul can often encourage work groups into greater clarity.

Axe Grinder: This person is clearly focused on one topic (their axe). No matter what the discussion, the solution is always related to that topic, and they are an expert on it, so you better listen to them. If you disagree, clearly you don't understand axes well enough. Occasionally, the Axe Grinder is right, but like the "boy who cried wolf", it's very hard to tell, and very few will want to encourage the Axe Grinder by agreeing with them.

Rebel: This member seems to have shown up at the wrong meeting. They are often deeply involved in a competing effort elsewhere, reject the basic methodology of the organization, and are trying to get the organization to adopt and/or recognize the methodology of their choosing. Rebels are important voices to listen to because they bring in an outside voice, but their basic rejection of the values of the organization in which they are participating can often make their voices very hard to hear.

Legalist: This person has studied the organizational governance processes to the last detail, and know how to use them. They have memorized Robert's Rules, and have a copy of it just to be able show it to others to prove their point. The legalist often ensures that a fair process is followed, but can use process for their own advantage.

Excited Newbie(via @jacobr)

This is the young, smart, engaged newcomer. Eager to engage deeply, SUPER excited to have been given permission to escape the salt mines by his/her manager - and wants to join all workgroups, volunteer for all of the subcommittees, and fix all of the problems. Today! Despite the temptation to pat them on the head and suggest they calm down, the energy and enthusiasm of the Newbie is contagious, and it breathes new life into the process.

Be wary of putting every person you meet into one of these buckets. First of all, you run into the danger of "flipping the bozo bit". As you may have noted, each of these characters has something to contribute along with any other baggage they bring. Secondly, these are roles that people can play, not fixed identities that are inseparable from the individual. I've been several of these characters at different times, and maybe someday, I'll become a venerate ancient.

-- Keith

Good Luck at Connectathon

2012-01-09T19:30:00.000-05:00

I'm not going to be at Connectathon this year for the first time in nine years. Something came up last week, and I need to be here working on other interoperability problems. I won't be onsite helping people figure out how to record allergies to peanut butter, looking for people in orange shirts (or whatever the color is this year for monitors), or trying to figure out how why my X-ray image isn't displaying in my XDS-I implementation (it was an AE-Title mapping to WADO Server URL problem that time).

I'm going to miss being there. There are a lot of people there that I only see at IHE events. I won't get to see the Connectathon Conference (but if you can, you should go!)

I won't be able to take pictures of normally competing vendors working all night long to make sure their systems interoperate.

While I'm certain to get a call or two from the Connectathon floor, I'm actually quite comfortable here. It's a shame though, because for the first time in 9 years, the weather in Chicago appears as if it's going to be rather mild.

EHNAC Forum on HIE - January 25

2012-01-06T10:34:00.001-05:00

www.nationalehealth.org

A Message on Behalf of the
Electronic Healthcare Network Accreditation Commission (EHNAC)

NeHC CEO Kate Berry to Participate in Industry Forum Webinar on Health Information Exchange

The Electronic Healthcare Network Accreditation Commission (EHNAC), a non-profit standards development organization and accrediting body, will host a free webinar that will discuss the current state of the HIE model. "Dispelling the Myth that All Health Information Exchanges (HIEs) Are Created Equal" will take place from 1:30 to 3:00 p.m. EST on Wednesday, January 25, 2012.
Through a panel discussion, the webinar will examine how the HIE model has evolved, the major players involved and the factors all stakeholders should consider. Additionally, panelists will discuss potential impacts of the Direct Project and the Nationwide Health Information Network (NwHIN) and offer attendees real-world solutions for assuring stakeholders' trust in the clinical exchange.
An open forum will follow the panel discussion to enable attendees to submit questions specific to their own organizations. Hosted by Lee Barrett, executive director of EHNAC, the panel of healthcare professionals with extensive expertise in health information exchange, privacy and security and PHI, will include:

· Kate Berry, CEO, National eHealth Collaborative (NeHC)

· Laura Kolkman, president, Mosaica Partners

· Jan Root, president and CEO, Utah Health Information Network (UHIN)

· William O'Byrne, executive director, NJ-HITEC

· Jennifer Covich Bordenick, CEO, eHealth Initiative (eHI)

Those interested in attending may register for the HIE webinar here or visit www.ehnac.org for more information.

Participating in HealthIT Standards Development

2012-01-06T10:23:00.001-05:00

So, you've decided that you want to invest time and effort in developing Health IT Standards, and you've convinced your manager that it's worthwhile. What next?

Presumably, you have a specific effort that you want to participate in mind. It could be a standard being developed in HL7, a profile in IHE, or an S&I Framework project. The first step is to join the requisite work group. There are good times and bad times to join a project. The best time to join is in the early stages when it is first being discussed. The worst time is when it is nearing a major deadline, and the pace to complete things has reached its peak. It's difficult to catch up at these times, the best way is to do your reading. Sometimes timing isn't up to you (I've had people tell me I need to get involved in X when X is nearing completion), but if you have some control, its nice to be able to make use of it.

Joining the Organization
Joining any of the previously mentioned organizations can be as easy or as complicated as your organization wants it to be. That's where having management support to navigate purchasing, legal review and organizational commitment issues is important.

Time wise, it can take as little as week (or even a few days if timed right) or as much as a month or two to "become an official member". Don't worry, even if your membership is still being processed, most of the organizations will let you participate in non-voting development activities.

HL7 has a membership fee based on organization type and Health IT revenue or budget, IHE and S&I Framework don't. IHE does have a simple online form and legal agreement (see the last page) that your organization needs to commit to. For S&I Framework, signing up is as simple as editing a wiki page, but you must sign up for each project you want to participate in.

Finding a Project
If you are looking for an HL7 project, there is an RSS Feed for HL7 projects, or there is a searchable project database (you'll need an HL7 login to access that, which is free even if you aren't a member). IHE PCC, IT Infrastructure and Quality, Public Health and Research accept project proposals in Q3 of each year, and approve them in Q4. Anyone can submit a proposal (even non-members). They meet twice for two days, once in October and in November to review the proposals. S&I Framework projects are mostly initiated by ONC, but there are community initiated projects as well. To get one of those started, it helps if you know of some federal agency that has a need. You can find a list of their active projects on the S&I Framework wiki.

Participation
Most of the time, participation in these projects is via teleconference and screen sharing applications (Webex, GotoMeeting, or LiveMeeting depending on who is hosting the service). You often bear the cost of the call, and should have decent network access. Skype is often used by members who need to access the call from remote locations, but it's not always reliable. Work group calls are usually weekly or every other week, and last anywhere from 45 - 90 minutes. They sometimes occur more frequently or take longer, especially during crucial periods.

Most work groups have mailing lists, but S&I Framework uses a Wiki as the principal means of off-line communication. Non-members can access many HL7 mailing lists. Most IHE lists on Google groups are members only, but some devoted to implementation are open to all. The S&I Framework wiki is open to anyone.

Face to Face Meetings
Big chunks of work happen at face to face meetings. HL7 has working group meetings three times a year (January, May and September) that last 5 days each. Larger work groups use all that time, smaller ones may meet one or two days during that week. One of them is typically internationally located. In IHE, there are meetings three times annually for profile development, lasting from 4-5 days each. Each domain (working group) has its own schedule, driven typically by the domains largest industry conference (which is where their work gets demonstrated). PCC, QRPH, and ITI have these meetings February, May and June. There are two 2-day meetings at the beginning of the development cycle for approving new work items (October and November for the domains above). IHE meetings are often internationally located, but the three domains I just mentioned typically meet in the Chicago area 3 - 4 times a year.

S&I Framework doesn't have regularly scheduled face to face meetings, but you can expect about 2-3 a year, lasting 2-3 days each, usually in the DC area.

This is enough to get you started, my next post will talk about how the work gets done, and how you can contribute.

An interesting distraction

2012-01-05T16:05:00.002-05:00

It's interesting how one good blog post or story can become a media trend. I wish it had been one of mine, but I noted this article with commentary by John Halamka, which he also mentioned on his blog a few weeks ago.

It follows with these two:

American Medical News: Doctors have to manage smartphone distractions
iMedicalApps: Healthcare professionals becoming increasingly distracted by mobile devices

A bit of Googling gives:

Fox News: Are Smartphones distracting doctors?
Mobiledia: Mobile Devices Drive Doctors to Distraction
Examiner.com: Doctors must deal with smartphone distractions
KevinMD: Solving distracted doctoring from smartphones and tablets

It appears to have started with this New York Times article: As Doctors Use More Devices, Potential for Distraction Grows

Most, but not all of the reporting cites either the NY Times article, or the AHRQ report that many of these stories seem to be built around. Tracking this story through the web and social media has provided an interesting lesson in creating useful content, and an interesting distraction.

I use a cell-phone myself, but when I'm in a meeting, I let it go to voice-mail more often than not, and I don't have e-mail sent to my phone. E-mail after all, was never designed to be instant messaging.

From a patient perspective, if a doctor ever answers or looks at a phone in my presence, I'll ask them to turn it off. After all, it is still my healthcare.

Six days until IHE N.A. Connectathon Conference- Jan. 11, 2012. Register in advance!

2012-01-05T13:32:00.000-05:00

IHE N.A. Connectathon Conference offers unique “one day adventure” with Industry Leaders!

Register in advance for the January 11, 2012 Conference!

The IHE N.A. Connectathon Conference 2012 is next week, Wed. January 11, 2012 in downtown Chicago at the Hyatt Regency. Join us for a full day of valuable educational sessions and venture out to the IHE N.A. Connectathon testing floor where interoperability happens through the collaborative efforts of 600+ database architects and engineers.

Visit IHE USA’s website for the full agenda and details around the educational sessions, speakers, and the cocktail reception following the conference. Registration will be available online until Tuesday, January 10, 2012 and on-site the date of the event.

Conference Dates & Logistics

The IHE N.A. Connectathon Conference is open to the public. We encourage IHE members to invite interested organizations and individuals that want to learn more about IHE and interoperability. Please review the second page for more details.

Conference Date: Wednesday, January 11, 2012

Educational Sessions: 8:30 – 4:30pm CT

Cocktail Reception: 4:30 – 6:00pm CT

Registration fee: $195.00

Meeting Location & Hotel Accommodations:
Hyatt Regency - Chicago, IL.
151 East Wacker Drive
Chicago, IL 60601

Hotel Reservations: Click here.

If you have additional questions, please contact Connectathon@ihe.net or visit IHE USA’s website for more information.

The ROI for supporting HealthIT Standards

2012-01-05T10:34:00.000-05:00

Yesterday I wrote a brief post on investing in Health IT Standards. One obvious question is "What's in it for me (or my organization)?" The generalized benefits I described in that post really don't give you enough when you have to get support from your manager to participate. So what are some more tangible returns?

Time to market - When you've been involved in the development of a standard, you will often have a significant advantage in understanding how it works. That can be translated (with appropriate execution) into a market advantage in deployment of the standard. If it's a good (or better yet great) standard, your participation in its development can provide you with important knowledge ahead of others who haven't even heard of the standard yet. That knowledge can also be transferred to other staff, often at a much lower cost than fee-based courses.

Informing the standard - Knowing what you need and participating gives you an opportunity to ensure that the standard meets your needs before it is released for comment. Getting in early in the development cycle means that you can be part of the requirements setting process. That means that the standard will be less likely to have "impedance mismatches" with your applications, avoiding costly rework. At the very least, you'll be more likely to learn what they are much earlier than you would otherwise, enabling you to get a head-start on any necessary product improvements.

Both of the above can be extremely valuable when your product and/or customers have a need for what the standard provides. This is often a much better than "break-even" investment.

Increased skills - You will be exposed to other experts, with different backgrounds and experiences. You can learn quite a lot in the standards setting environment that you wouldn't get from other places, simply because of exposure to industry experts. This is about break-even. Participating in development of standards, and the education you and your organization get from that effort will be slightly more cost-effective than paying for training for your staff on it later in many cases.

Influencing thought leaders - In many standard setting environments, you will be introduced to, and work alongside industry thought leaders. The information flow goes both ways. Not only will you increase your own skills (see above), but you can also influence these thought leaders with your own experience. That influence can certainly be better than break-even, but it's also extremely hard to measure.

Recognition - Being involved in a standards effort can be rewarding in other ways. You and your organization will often be recognized by others for your contributions. That can be valuable in many ways. If you are a contractor, it can lead to more work. As a vendor, it can lead to customer contacts. As a healthcare provider, it can lead to staff. This effects are probably break-even by themselves, but there is more.

Recognition can lead to invitations of another sort as well. From a personal career standpoint, you will make more contacts in your industry, which can lead to all sorts of other possibilities. I'm in my current position as a result of that sort of exposure.

There are also other possibilities that can benefit your organization, including collaborations with other organizations.

As I look at the people involved in HIT Standards, and the HIT Standards committee, I see a number of members of that select group who come from an HIT Standards background.

Putting all of these together means that you can often have an ROI that far exceeds what it costs an organization to participate, and that includes your time, travel and membership or meeting fees.

The last benefit isn't ROI for your boss or for your career, but is worth pointing out:

Happiness - My work is extraordinarily satisfying because the standards I'm developing are used both in my neighborhood and all over the world. These things save lives. I can think of nowhere else where I could have such a substantial effect. You can to, and that can be very satisfying. It certainly makes me very happy.

IHE Europe 2012 Connectathon Registration

2012-01-04T13:05:00.000-05:00

Just when you thought you were ready for the January Connectathon, there's another one right around the corner...

IHE European Connectathon Registration Closes in 11 days !!!!

IHE Europe is pleased to inform you that the Registration to the IHE European 2012 connectathon is still open. The connectathon will take place May 21-25 in Bern, Switzerland. The IHE Connectathon is the healthcare IT industry's largest face-to-face interoperability testing event. IHE profiles enable effective interoperability in a wide range of clinical settings, including health information exchanges.

This year profiles from 8 IHE Domains will be tested at the Connectathon:

Anatomic Pathology
Cardiology
IT Infrastructure
Laboratory
Patient Care Coordination
Patient Care Device
Pharmacy
QRPH
Radiology

Registration closes January 15th, 2012.

More information :

The Bern connectathon is also an opportunity to test :

XDW : Cross Enterprise Document Workflow
LAW : Laboratory Analytical Workflow with the support of IICC
Pharmacy profiles
RFD and CRD In the context of the EHR4CR project.

CDISC and IHE encourage testing of the RFD profile (ITI domain) and the CRD profile (QRPH domain) at the Bern connectathon. For more information about cdisc : http://ww.cdisc.org and about ehr4cr : http://www.ehr4cr.eu

Why invest in HealthIT Standards

2012-01-04T12:29:00.000-05:00

Karen Bartelson is one of my favorite writers on the topic of standards development. She recently wrote a four part post on her blog on "Standards: Why we do it."

I occasional teach a class on the value of standards, here are a few quips from it:

Standards enable competition and grow the market
Standards enable specialization (innovation)
Standards reduce design cost and quality of interfaces is typically better, design review is better

Great minds think alike. Karen also wrote a great book about standards development called the 10 Commandments for Effective Standards which I reviewed a couple of years ago. It's on the reading list for my class, and I'll be adding those recent posts to that list when I next update it.

There are four different stakeholders in the development of standards (I distinguish purchasers from end-users because the purchaser of a product is often not the end user, especially in business settings.)

Manufacturers of products that must adhere to standards.
Purchasers of products that adhere to standards.
End-Users of products that adhere to standards.
Consumers of products and services that benefit from standardization.

Each one of them gains by participation in the development of standards. Manufacturers gain because the standards grow the market, lower development costs, and enable innovation. Purchasers gain because they can obtain easily measurable products of high quality and good cost. End users gain because they can obtain a wider variety (innovation again) of high quality products. And the real benefit is to the consumers of products and services because of the reduced cost and greater quality and variety of goods and services that standards enable.

A Duct Tape Week

2012-01-03T18:01:00.002-05:00

It's my first official day back on the job in the new year. Some days, I feel like the glue that keeps things together, and other days, like duct tape keeping things from falling apart.

Glue days are when I manage to connect up this person with that fact or other person, or that product with this other team, or that project with this other detail. Duct tape days are when I manage to keep things from falling apart by making sure this person talks to that one, or reassure that person that because of this detail, they need not worry, and so on.

The difference between glue and duct tape is in how fast it works, and how permanent the solution is. Glue takes a bit of time to set, but usually creates a pretty permanent solution that doesn't need to be addressed later. Duct tape is very quick, and can keep things from falling apart, but it is by no means a permanent solution. Glue is mostly used for building, and is sometimes used for (permanent) repairs. Duct tape is mostly used for repairing things, but can occasionally be used to hold things together while glue sets.

Today, getting back, catching up, and getting ready for the next two weeks, I'm barely managing to tread water. Thus, it is a duct tape day. I'm ripping and sticking as fast as I can to hold things together until I get real time to figure out a more permanent solution.

A good week is when I spend less than 10% of my time dealing with duct tape. A really bad week could be covered in it, but I haven't had a really bad week in a long time. Mostly that has to do with preparation. If you are prepared, you might need to break out the duct tape from time to time, but most of the time, you'll be using glue. There are times though, when duct tape is perfectly acceptable, and duct tape days are the norm.

Connectathon is next week. A great deal of duct tape will be used there. This is not a bad thing. The whole point of Connectathon is not to discover what works, but rather, to figure out what doesn't and get it working. Teams that succeed at connectathon wind up with improved products, and even those that fail often learn a great deal. The point is, once you've learned what is broken, you can go back, and figure out how to really fix it (in the weeks after connectathon).

Here's wishing you all a great duct tape week.