Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Wednesday, August 31, 2011

Cool non-Technology of the Week

This is really just a ramble on something I've appreciated for years.  Fresh, home delivered milk in glass bottles.  When I first moved into this house just before my daughter was born, my local dairy left a flyer on our doorstep.  My wife likes low-fat milk.  I could never abide it.  It just didn't taste right.  There were about two suppliers that made something we could both drink.  For the two of us, it never made sense to buy more than one bottle of milk.  When we tasted the local dairy's milk we were hooked.  The convenience of home delivery and the quality of the product have kept us a customer for 14 years.  I've switched doctors at least three times since then.

My dairy recently added another product:  Home delivered farm-fresh produce from a local farm that we've often frequented.  It's not terribly close, (about a half-hour away).  But now I can get a box of fresh vegetables each week from a local farm.  I can get farm fresh vegetables and fresh milk locally.  And I will pay a premium for it, but it will be worth it.

When I was growing up I used to be able to ride my bike to the doctor's office and dentist's office in my neighborhood.  While I might still be able to do so, I've seen few if any physician offices in neighborhoods anymore.  They are still close by, but no longer really part of the community.  My children don't go to school with my doctor's kids.  Sometimes I do wish that life were simpler.

Oh well, at least I still get my milk from glass bottles.

Display Names in CDA

The CDA standard supports recording names in a variety of different ways using the Person Name data type.

The name element is used to contain the name of a person, be they provider, patient, emergency contact et cetera.   There are several difficulties with names when they are exchanged.  The first of these has to do with cultural variations in how names are "displayed".  Related are differences in how a name is parsed into different parts by various cultures.  Finally, there is the fact that the name element itself uses mixed content in the CDA Release 2.0 XML.

One of the "requests" of the Metadata ANPRM is a "display name" representation.  This is already supported in CDA.  If you take the name parts in the order presented, you have them in the correct display order.  In Asian cultures, the family name is often given first, followed by the given name.  CDA doesn't specify the order in which the name parts are provided, but the PN data type does have a virtual property which delivers the name formatted appropriately. The method by which the formatted name is extracted is given in the HL7 Data types specification.  Actually a much easier way to get at is uses the XPath or XSLT string function.  If $name is a variable containing the name element, normalize-space(string($name)) is an XPath or XSLT expression that will return the formatted name according to the HL7 rules for the PN data type.  If you encode the name as shown in the examples this works just fine.

With regard to cultural differences in parsing, in the western world we often think of first, middle and last name. But the common features are that names are either given (first and middle), or are family names (maiden and last).  Crossing between these two is sometimes a challenge.  Women often use their maiden name as a middle name after marriage.  So for them, the first given name is the first name, the first family name would be the maiden name, and the last family name would be the last name.  But men usually don't change their name, so the first given name is the first name, the second given name is the middle name, and the first family name is the last name.  Of course there are plenty of other variations.  In order to be interoperable with systems that still think in this western-centric way, I tell people to simply place the middle name as the second given name.  It makes it much easier, even if it isn't exactly correct.

The mixed model provides another challenge, because white space is significant.  I need to examine the CDA Consolidation guide for how to represent names, because I think we recommended it not be present.  That defeats the simple XPath/XSLT extraction of the formatted name.  There are still ways to get at it by inserting the implicit white space through a very simple transform, but it isn't quite as clean.

Another request of the Metadata ANPRM is to provide a display name for searching purposes.  The Entity Name data type (from which Person Name is derived) has a use attribute that can identify the name used for search purposes.  The way to represent that is to add use='SRCH' to the name element.

Tuesday, August 30, 2011

The Difference between a Skim and a Scan (of the Metadata ANPRM)

Skimming is quickly reading the surface.  Scanning is deeply reading and understanding the content.  These two words are commonly misused for each other in writing.

In My SKIM of the Metadata ANPRM, I made the mistake of assuming it applied to Metadata used for Health Information Exchange.  After all, the title is:  Metadata Standards to Support Nationwide Electronic Health Information Exchange.  In my SCAN of that document, I found this on Page 13:
As a feasible first step, the HIT Policy Committee suggested that ONC focus on facilitating the development and adoption of a minimal set of standards for metadata that could be “wrapped around” or attached to a summary care record when a patient seeks to download their health information from, for example, a health care provider’s patient portal or when a patient directs his or her health care provider to transmit his or her health information to a personal health record (PHR).  Generally speaking, the term “metadata” is often used to mean “data about data” or, in other words, “data that provides more information or detail about a piece of data.”
In the ANPRM, the standard identified for the purpose of downloading PATIENT SUMMARY data is CDA Release 2.0, and I can wholeheartedly support it for that purpose.  In fact, the S&I Framework CDA Consolidation Project and Transfers of Care project both use the same standard to convey summary information.  So no "wrapping" is even necessary.

There's more needed, (e.g., requirements on what must be present, and vocabulary), but this is a good first step. I'd suggest they look at what is already being done today (using the HITSP C32 Version 2.5) to fill in those gaps (see C83 page 27 Personal Information and C80 page 26 Personal Information)

Now that I understand what David McCallie was trying to tell us, I get it.  Thanks David.

Monday, August 29, 2011


30 hours with no power (back now). Lots of scrapes and bruises feom clearing downed tree debris. I downed one intentionally before the storm. My generator failed its test run. And there was of course, no one available to fix it. But at least I don't keep it in the basement where floods could make it useless.

If you needed flashlights, gasoline powered chainsaws ( or other tools ), gas cans, you were out of luck in my neighborhood, but the nearby big-box hardware store did have generators amd some gasoline powered tools.

I know this not because I was looking, but because I ran into others for my short run for work gloves and pruning shears.

One thing it made very clear is that you need to test your emergency plans BEFORE you actually have to use them. Simulations and brainstorming are good ways to play the what if game.

Back to clearing the yard (all are safe here and there was no major damage).

My local electric company just called to tell us that some areas could be without power through the weekend! Glad that's not us.

Friday, August 26, 2011

Hurricane Preparedness

I lived in Tallahassee, Florida for ten years.  Hurricane season was simply a fact of life, and we could usually expect at least one Hurricane to pass close by a year, sometimes more.  Being prepared for a Hurricane was something that most year-round residents knew how to deal with.  This far north, a Hurricane might get close, but is usually offshore and quite weakened.  It happens about once every decade or so that a full blow hurricane makes landfall.  So folks aren't as aware of how to cope.

Here's my checklist:

  1. Water and liquids:  Have enough fluids for several days.
  2. Food:  Same deal.  Don't count on what you have in the refrigerator.
  3. Flashlights and batteries.  You could be without power for some time.  Make sure you have lighting.  I also have an oil lamp and lots of candles.
  4. Power:  I bought a backup generator a while back to deal with a local outage (car hit a transformer station).  It gets tested out again today.  I'll make sure I have fuel for it as well, because if there is no power, the local service stations won't be able to pump it.  That will get my refrigerator and freezer through short outages without spoilage.  Buying one now could be difficult, I'm glad to have one beforehand.
  5. Charge everything: Phones, rechargable tools, et cetera, and make sure you have a way to get information (a battery powered radio) if your power goes out.
  6. Fuel:  Make sure your car is filled up, and that you have spare fuel also for any gasoline powered equipment you may need.
  7. Chainsaw:  After the storm, you may need to clear downed trees or branches.  If you don't own one, trying to buy one after the storm could be difficult.
  8. Masking Tape and Plywood.  This storm won't be so bad (Category one), but its wind can still damage windows.  Taping them prevents shattering, but won't keep them from breaking.  Plywood can prevent flying debris from causing damage.
A good source of information is here.

I'm waiting this morning for someone to show up to remove a dead tree that would likely come down in this storm.  Finding someone to do that this late in the game is difficult and expensive.  Next time that happens, I won't wait.

11:27 Update:  My tree guy is on his way.

Also, if you are on Social Media, you should read about Tweak the Tweet, a way to communicate using twitter.

Thursday, August 25, 2011

A really informative consent

I started reading Safe Patients, Smart Hospitalson the plane back to Boston yesterday until my battery died.  I'm still not done, so I'll save the review to a later post.  The author, Peter Provenost quotes statistics that I found rather disturbing.

One study concluded that there were 1.7 errors per patient day in America's ICUs.  Of these errors, 29 percent could have caused significant harm or death.

He points out that the average stay is about 3 days.  That means just over 5 errors.  The chance of leaving the ICU without suffering from such an error means that you need need to succeed on five rolls on a pair of dice without rolling a 2, 3, 4 or 5.  You'll manage that less than 1 time in five (about 18% of the time).

Many of us have seen informed consent forms.  They list the significant risks of a surgical or diagnostic procedure.  But what they don't do is list the actual chances associated with that risk.

What if, on being asked to consent to a procedure you were told:

There is a significant risk of ____.  In similar procedures performed (by your surgeon/at this institition), patients were X% likely to incur this risk.  This is [significantly][above|below] the national average of Y% in similar institutions and procedures.

Even better yet, it could use one of those pictures like Energy Star uses.

Wouldn't that actually say something relevant to patients and incent institutions and providers to do better?

Wednesday, August 24, 2011

Priming the Pump for Tonight's HITstd Tweetchat (5:00pm ET)

Tonight's HIT Standards Q&A Tweetchat (5:00PM ET) will be on IHE Profiles from IT Infrastructure dealing with patient identity management.

Originally, it was going to cover ITI, Patient Care Coordination, and Quality, Public Health and Research domains.  But, last week there were a number of questions about Patient Identification, and I hope we focus on what IHE has to offer in this space.  IHE IT Infrastructure profiles support the following.

First, there is Patient Identity Cross Referencing (PIX).  This profile is designed to allow an EHR or other Health IT system to integrate with a Master Patient Index using HL7 Version 2.3.1 and 2.5.1 messaging.  If you know the ID of the patient in one domain, this profile allows you to find the ID of the patient in another domain.

Next there is Patient Demographics Query (PDQ).  This profile allows you to search for patient identities based on patient demographics.  You can locate all of the matching identities, or just those from a specific identity domain. This also uses HL7 Version 2, but this time, just 2.5.1 to support the queries.  PIX/PDQ are rarely found implemented separately, but they are written as separate profiles.

A few other countries require the use of HL7 Version 3 messaging to access this information, so IHE created a HL7 Version 3 edition that has the same capabilities, called PIX/PDQ Version 3 (PIXV3 and PDQV3).

Identifying patients from one HIE who might have records in another is a more significant challenge.  The Cross Community Patient Discovery (XCPD) profile builds off of the PIX/PDQ V3 work.  It needs to use web services to perform the exchange for various reasons.

Finally, there is Patient Administration Management (PAM) which uses HL7 Version 2 to address general patient administration (ADT) messaging, which is where a patient identity usually enters the system.

One reason for the focus on Patient Identity is the ONC Advance Notice of Proposed Rulemaking on Metadata for Health Information Exchange.  You can find my thoughts on that rule here, and an initial post and a more detailed on with answers from John Moehrke as well.

I look forward to your questions.

Tuesday, August 23, 2011

Can we get a little bit more coordination please?

There is both too much and too little going with the SI Framework Query Health that I'm tempted to submit an IHE Profile proposal that overlaps with the use case and an HL7 Project Scope Statement on the same topic just to ensure that some coordination happens. It would be so simple for ONC to use these mechanisms to encourage engagement, but I don't think that would ever occur to them.
I will probably bring the topic up for the HL7 Coordination with Other SDO's panel session in September to see if there is something that could be done to improve the situation.

Several people this week were frustrated over ONC's scheduling of the Summer Concert Series, especially as it overlaps with the Public Health Informatics Conference in Atlanta, where most of the people that Query Health is supposed to serve are. There are no sessions here on what Query Health is. And the Finale of the Query Health summer concert series is being held when an important member of the desired audience is out of town for most of the week.

OK, now that I have that off my chest, I did have an interesting discussion about Query Health over a fantastic Omikase style dinner at MF Sushibar.

There are a couple of challenges with "sending the query to the data" which Query Health will need to address. The first challenge is scalability. The second is coordination. The third is overlap with reporting.

With regard to scalability, I can imagine the number of queries getting quite large. I don't think that it will be feasible to process a large number of queries if they aren't designed to be very efficient. There are some techniques that can be used to enable the system to operate linearly in the size of the records being queried, rather than on the number of queries being performed. But that means that the queries need to be aggregable, so that multiple queries can be run at the same time, sort of the way that the Unix egrep tool can very efficiently search for a number of strings. But that does mean that the queries need to be pretty simple to support the aggregation of them.

The second piece that needs to be addressed is coordinating results in a timely way. I don't see query health being used effectively for a national outbreak of H1N1. But I do see it being used in other ways. Even so, unless the query is truly computed the same way, there could be some challenges in interpreting the results. I'll give an example. In one case, HEDIS measures for one region in a state were way off. It appeared that Women weren't getting routine laboratory tests done that should have been. The problem was traced back to the fact that when test A was ordered, test B and C were done reflexively (automatically). But the measures were computed based on what was ordered, not on what was reported on. That variance in interpretation caused the results for one region to be so badly off that it was readily identified. But I suspect more subtle implementation decisions could wind up introducing other variances that are not so easily detectable. It needs to be looked out for. The key here is to ensure that the queries are simple enough that there can be no real differences in the results introduced by differences in implementation. Aggregation is one of those spaces where it could be challenging to produce results that don't exhibit that problem.

Finally, there is the overlap with Public Health Reporting. Ideally, I'd like to the same specification used to describe computable representation of the data needed for a report as for a query. In the first case, that representation describes the data outputs of a system. In the second case, it describes the inputs to a computation. I can use the gozouta of one as the gozinta to the other. That will be extremely powerful for not just "public health query", but as a way to define interfaces in general.

That would enable interfaces for all kinds of <a href=''>public health reports</a> to be generated automatically in software. That might put a lot of interface engineers out of a job, but I'm certain that in the current environment, there will still be plenty of call on their skills for other projects.  Because as soon as you turn around, there'll be another initiative.  I'm having trouble keeping up, and unlike many other standards geeks, that IS my day job.

IHE Profile Proposal for expanding upon the Retrieval of Clinical Knowledge

HITSP started it with T81 Retrieval of Medical Knowledge. IHE continued it in QRPH TF-2 (see page 99) with QRPH-29 Retrieval of Medical Knowledge. I'm demonstrating its use for Public Health Alerting this week, but there is so much more that could be done.

The specification is very simple. You request a resource using a URL. The query parameters to use are specified in the HL7 Infobutton specification.

But the specifications as they stand in either IHE or HITSP are incomplete.

  • How do you retrieve medical knowledge on a specific disease? A medication? What are the query parameters to set? What if you want a response suitable for a healthcare provider? A patient?
  • What happens when there is nothing to show?
  • How do you authenticate the provider using the request?
  • What are the error cases?
  • What is the format of the response?
  • What additional metadata should be returned in the response?
  • How can we make responses cachable? Should they be?
  • How do we retrieve multiple results?
  • Should the request be made using GET or POST?

These are all questions I had to address in the implementation I'm demonstrating at the Public Health Informatics conference this week in Atlanta. Some of the answers can be generalized to any use of InfoButton. Others are more specific to the kind of request being made.

There needs to be a general specification that addresses the common issues. These should be written as Change proposals to QRPH-29.

I have three or four other use cases for which I'd like to see a more detailed specification put together.

  1. Accessing Patient oriented education information on a laboratory result, condition or diagnosis, or medication. This is a capability already supported in MedLine Plus as I understand it. I'll be following up with a few people from NLM for more details on that. Note: Access to Patient-specific education information is one of the menu-set objectives in Meaningful Use.
  2. Accessing information about clinical trials relevant to a particular disease. Many patients with serious life-threatening or chronic illness would love to find out about clinical trials they might fit into. A suitable InfoButton query could be crafted to support access to an Atom or RSS Feed of clinical trials. That could go a long way towards encouraging enrollment in clinical trials.
  3. Taking the next step in creating actionable public health alerts. In my current implementation we are getting a HTML page back. But, the content would be easier to handle if it were actually an Atom or RSS Feed in response to the query. This addresses multiple issues:
    1. It supports multiple responses to the query.
    2. It allows just the key metadata to be returned as a response, with subsequent retrieval of the detailed data when needed.
    3. It allows each alert seen to be given a unique resource ID that DOESN'T change even when the alert changes. This is critical, as it allows providers to keep track of what they saw, when they saw it, without having to keep a separate copy. When the alert changes, the link in the feed changes, rather than the content of the page. This is an important issue for medical records professionals.
    4. When a feed is used, the URL found is to the appropriate alert. That makes the detailed alert result cache-able. This is another important issue that can help address network latency issues. A simpler response can be returned that points to the potentially cached resource.
  4. The Problem

    Providers and patients need a simple way to search for web resources that can answer specific questions. The HL7 InfoButton standard provides one such mechanism by which this can be done. However, there are a number of different ways that InfoButton can be used, and there are a number of options in how a system can respond. We need a consistent set of rules for using InfoButton to query for information that is either patient or provider-oriented. We need a consistent way to address and report on errors in the responses. We need a consistent way to return results so that EHRs and PHRs can make these queries, process the results, and display them in a normalized form.

    Key Use Cases

    A provider using an EHR wants to locate patient oriented education materials on a given condition. How should the query be structured to obtain a selection of available materials? A patient wants to keep track of clinical trials for a specific condition. How should the query be structured to obtain a selection of appropriate clinical trials?

    Standards and Systems

    InfoButton, HTTP, XHTML, HTML, HTML 5, Atom, RSS EHR, PHR, HIE


    This should be a joint work item between Patient Care Coordination, and Quality Research and Public Health. IHE would be a good venue to solve this problem because it involves developing a profile across several existing standards. It has the necessary expertise in PCC and QRPH to address content issues, and in IT Infrastrucure to address common infrastructure questions. There may also be cases where a query could actually return a URL to a form that could be used with the IHE Request Form for Data Capture profile. We should examine what the glide path is from QRPH-29 to ITI-34.

Monday, August 22, 2011

IHE IT Infrastructure Technical Framework volumes and supplements published


IHE Community,


IHE IT Infrastructure Technical Framework volumes and supplements published


The IHE IT Infrastructure Technical Committee has published the following Technical Framework volumes as of August 19, 2011:

·       Volume 1 (ITI TF-1): Integration Profiles

·       Volume 2 (ITI TF-2): Transactions (volume 2 is divided into three separate sub-volumes)

o   Volume 2a (ITI TF-2a): Transactions ITI-1 through ITI-28

o   Volume 2b (ITI TF-2b): Transactions (cont.) ITI-29 through ITI-64

o   Volume 2x (ITI TF-2x): Appendices A through W and Glossary

·       Volume 3 (ITI TF-3): Section 4–Cross-Transaction Specifications and Section 5–IHE Content Specifications



The documents are available for download at



The Committee has also published the following supplements to the IHE IT Infrastructure Technical Framework as of August 19, 2011:

·       Cross-Community Fetch (XCF) - Published 2011-08-19

·       Cross-Community Patient Discovery (XCPD) - Revised 2011-08-19

·       Cross-Enterprise User Assertion - Attribute Extension (XUA++) - Revised 2011-08-19

·       Document Encryption (DEN) - Published 2011-08-19

·       Healthcare Provider Directory (HPD) - Revised 2011-08-19 

·       On-Demand Documents - Revised 2011-08-19

·       Retrieve Form for Data Capture (RFD) - Revised 2011-08-19

·       Support for Metadata - Limited Document Sources - Published 2011-08-19

·       XAD-PID Change Management (XPID) - Published 2011-08-19

·       XDS Metadata Update - Revised 2011-08-19


These profiles will be available for testing at subsequent IHE Connectathons.  The documents are available for download at


Comments on all documents can be submitted at

The Collaborative Health Record

John Moore over at Chillmark Research had a great guest post from Dr. Louis Siegel.

In this post, he talks about the Collaborative Health Record. This is a record of a patient's health that both the physician and the patient have access to.

He makes that point that a PHR is really only a small lens into the entire realm of health information available.

Outside the US, the term "Electronic Health Record" has a slightly different meaning. It is the longitudinal record of care for a patient which both can access. Many countries are creating systems to access this information. In Australia, they call it the "Personally Controlled Health Record". In HITSP, we defined PHR based on the definition of EHR. Instead of saying that it was an IT system designed for Physician use, the PHR was a system designed for Patient use.

The reality is that EHR and PHR are simply two sides of the same coin, and that we need to think about them together. Innovation that applies to one also applies to the other. For example, with respect to the Public Health Alerting scenario I'm demonstrating today at #2011PHI, the same interface could also be used from a PHR to show patients what public health alerts are related to their symptoms.

We need more of this kind of thinking in Healthcare. I applaud John and Dr. Siegel for their insight.

I cannot wait (although I must) until my healthcare provider installs their patient portal. That system is connected to the EHR and will be a great tool to assist me in collaboration with my doctor.

Now if we could just update our secondary (and primary) education systems to teach people how to work with their physicians. Then we could enable collaboration around health, instead of disease.

-- Keith

Friday, August 19, 2011

Open for Public Comments: Proposal to ONC on S&I PH Reporting Initiative


Proposal for the
ONC S&I Framework
Public Health Reporting Initiative

        Comment Period: August 19, 2011 - September 6, 2011

Dear Members of Public Health, Clinical and Health IT Vendor Communities!

We are requesting your participation in the Public Review of the Proposal to the Office of National Coordinator for Health IT (ONC) to establish the Public Health Reporting Initiative under the ONC Standards & Interoperability (S&I) Framework.

The goal of the proposed S&I Public Health Reporting Initiative is to harmonize the use of HIT standards and create reference implementation guides to support interoperable bi-directional communication between clinical care and public health agencies for selected information exchanges (use cases).  

The proposed timeline for this Initiative is October 2011 through December 2013, and will strive to produce deliverables for timely consideration of the HIT standards Committee during FY 2013.

The S&I Public Health Reporting Initiative will:

v  focus on individual-patient reporting from EHR systems and patients/consumers to public health agencies (local, state and federal)

v  examine several reporting use cases that share similar business processes, data and information exchange requirements.  The Initiative will then select candidate use cases that can benefit from the harmonization of HIT standards and implementation guide(s).  The harmonized use cases will be forwarded as reference implementations (testing methods, tools, certification criteria and processes) for consideration for Stage 3 of Meaningful Use adoption

v  identify demonstration pilot partners to help test artifacts from this Initiative, including the deployment of certified HIT products to enable information exchange and interoperability between EHRs and public health information systems

v  develop a Roadmap for Public Health Reporting HIT Standardization  that  extends and supports the long term harmonization and alignment of public health information exchanges and systems  with the recommendations and deliverables produced under this Initiative

We are also soliciting your feedback and suggestions for possible USE CASES that can be harmonized and delivered as candidate reference implementations under this Initiative.

Please provide your comments on the Initiativs Charter (attached),

Please also join the Initiatis Sprint Team to finalize the Proposal in September 2011 by attending conference calls on September 7 and 14 from 4-5pm ET.

Please contact Wendy Scharber at to join the Initiatives Sprint Team.

Participate in Building HIT Interoperability for Public Health!

The focus is changing in HealthIT

Why do EMR systems come with ICD-9-CM codes installed instead of SNOMED CT?  It may very well be that it's because that's what providers get paid for.  It used to be common wisdom that biggest reason for installing an EHR was to improve upon payment.  With meaningful use, the focus is shifting from that to exchange of clinical data.

If you look at the ACO rules, the shift is also towards exchanging clinical data.

If you look at some of the work happening in Health Information Exchanges that payers are setting up, there also is a move towards clinical data exchange.

If you look at the recent work of the HIT Standards committee, you see the focus on quality measures has shifted to clinical vocabularies.

I welcome this shift, and see it as the start of a Healthcare Revolution.

This sort of revolution won't be without its challenges.  We definitely need established mappings from ICD-9-CM and ICD-10-CM to SNOMED CT to support them.  As HIMSS mentions in their post, it could take some time to implement.

Thursday, August 18, 2011

PublicHealth Informatics Conference

This weekend, I'll be headed off to the Public Health Informatics Conference, affectionately known in some circles as the Conference formally known as PHIN.

It will be the first Healthcare Conference that I wear my jacket too. It's been to other events, but this will be its first conference.

If you are looking for me, you can find me in my usual place: The Interoperability Showcase where I and many other IHE supporters will be demonstrating use of Healthcare standards for interoperability.

I'll be participating in the Public Health Alerting demonstration, just like I have in prior years. To learn more about what is happening there, you can also check out this session and this one.

I'm looking forward to it.

What we will be demonstrating is actually a very powerful mechanism to deliver public health clinical decision support as a service that can be used by any electronic health record system, health information exchange, or even a personal health record. The work is based on the HITSP T81 specification.

If this seems like old news, it's probably because you've read some of the press I talked about here. We are taking it to the next step. It may have taken time, but I'm hoping it will have been worth the wait.

There will be plenty of other things going on, including use of HL7 CDA to support disease monitoring and surveillance, electronic laboratory reporting, and implementation of several IHE profiles developed by the Quality, Research and Public Health domains. If you are going to the conference, stop by the showcase and say hi. I'll be pretty easy to spot.

IHE Cardiology Technical Framework Volumes, Technical Framework Supplement and White Papers published

IHE Community,

IHE Cardiology Technical Framework Volumes, Technical Framework supplement and White Papers published

The IHE Cardiology Technical Committee has published the following Technical Framework Volumes as of August 5, 2011:
  • Volume 1 (CARD TF-1):  Integration Profiles
  • Volume 2 (CARD TF-2): Transactions
The documents are available for download at  Comments can be submitted at

The IHE Cardiology Technical Committee has also published the following supplement to the IHE Cardiology Technical Framework as of August 5, 2011:
  • Resting ECG Workflow (REWF)
This profile will be available for testing at subsequent IHE Connectathons.  The document is available for download at  Comments can be submitted at

In addition, the Committee has published the following white papers for public comment in the period from August 5 to September 4, 2011:
  • 3D/4D Echocardiography Workflow
  • Cardiac Electrophysiology Key Data Elements
The white papers are available for download at  Comments should be submitted by September 4, 2011 at

Wednesday, August 17, 2011

My qualifications

I ran across this in a Bio I wrote a couple of years ago.  It made me chuckle, so I'm sharing it.

My qualifications follow in short, from most relevant to least:

1965 - Present    Patient
1998 - Present    Parent of children who need healthcare
2003 - Present    Healthcare Standards Geek
1998 - Present    Standards Geek
1984 - Present    Paid Computer Geek 
1976 - Present    Computer Geek

Tuesday, August 16, 2011

IHE Radiology: Call for Supplement Proposals

IHE Community,

Interested parties are invited to submit proposals for new Profiles in IHE Radiology. Proposals will be considered for development in the 2011-2012 development cycle of the IHE Radiology Domain and are due by Friday, September 9, 2011.

Proposals should follow the attached Brief Proposal Template. Submit completed proposals to 

(Note that the template is also available as a Wiki page at If you are comfortable editing in MediaWiki, you can create a Wiki page for your proposal following the instructions at

The critical questions the proposal should address are:
  • What is the problem and how does it affect clinical practice (use case)?
  • How should things look in practice if it were fixed?
  • What specific pieces of standards could be used to solve the problem?
It is strongly recommended that the proposal include the name of a candidate editor for the profile.  If possible, also give some indication of the business case for solving the problem.

An IHE Radiology Planning Committee meeting will be held on Wednesday, Sept. 14, 9:00-11:00 am CT to review proposals submitted. All interested parties are invited to take part in the discussion. Call-in information can be found at

Please address any questions about proposal submission process to

Chris Carr
Secretary, IHE Radiology

Monday, August 15, 2011

Shared decision making requires shared responsibilities, not knowledge

According to the Journal of the American Medical Association, 46% of adults cannot understand the Label on their prescription medications (see The average reading level of adults in this country is commonly reported to be 8th grade.

Take those facts into account and then read this tweet.

@Skepticscalpel: How can a patient, who does not know what meds she is on or why, seriously participate in "Shared Decision Making"?

"The same way a doc who doesn't know the difference between a web browser and a mail client uses his computer" I responded.

"@Skepticscalpel: @motorcycle_guy But the doc isn't putting his care & possibly life in danger by not knowing" is the quick response.

The risks are irrelevant. The notion that one must be technically proficient to participate in decision making is a misconception stongly held by technologists of all kinds. While we'd certainly like for it to be true, it often isn't (remember the stats cited above).

As a software developer, it is often my job to make a complex set of issues readily understandable to a stakeholder who doesn't have the neccessary background to infer consequences of the decisions they must make. My responsibility is to make it clear, theirs is to make their needs known. Together, we decide on a best course forward. If we do a good job, everyone feels good. It is a shared responsibility. I cannot blame the customer for my failure to explain the repurcussions of their choices.

After all, if they understood it as well a I did, they wouldn't need me in the first place.

People are much more complicated than computers or software. I expect the professionals that serve and service them to be much more skilled at this than I am. But perhaps I ask too much.

Documents vs. Data

In "The XML Consensus is breaking down" Grahame Grieve distinguishes three camps, heavy engineering crowd, the internet mob, and the data dictionary crowd.  He discusses how XML seems to be failing to bring these crowds together.

I've worked with structured documents and natural language processing for a long time, probably twice as long as I've been in healthcare.What I find interesting in healthcare is the nature of the information being used. Just for fun, I'm going to look at it from a document oriented perspective, since that's what I've spent most of my life working with.

From a document perspective, a dictionary, phone book or thesaurus is almost ALL data.  Every last dot and twiddle can be expressed as either discrete data, or relationships to other data.  In the healthcare world, this is like a drug database, or a vocabulary like RxNORM, SNOMED® CT, LOINC®, ICD or CPT.  In XML (or SGML), there's a lot of markup expressing relationships between content, as compared to text to display to the end user.

A clinical note, especially ED, Inpatient or progress notes, involve quite a bit of storytelling.  Sections like "History of Present Illness" or "Hospital Course" tell a story about what led up to a visit, or what happened afterwards.  The relationships are fuzzy and ill-defined, often hard to identify.  There is data here, but it has a great deal of subtlety.  It's hard to pin down, or to compute with (you will note that I said, hard, not impossible).  There are little pockets of low hanging fruit.  You can readily identify diseases or medications in the text, treatments or diagnostics.  The medical profession uses language precisely (some would say "like a scalpel"), which makes it a lot easier to identify this data in the narrative.  But just because it cannot be identified, doesn't mean it's not there.  It's just represented in a way that you cannot easily fit into third normal form.

Interspersed throughout the narrative are larger chunks of discrete data, results from examinations and assessments that can be finely structured, collections of measurements, like vital signs.  These notes are like entries in an almanac.  There are broad swaths of narrative, interspersed with finely structured text dense with data:  Flag, Population, GDP; Blood Pressure, Temp, O2 Saturation.  This stuff is designed to be put into tables, both on the screen and underneath it.

The electronic health record is a collection of data.  Some of it is stored in a format suitable for humans to read, and other parts of it stored in a way that makes it easier for software developers to compute with.  It's all data, the question really is what are the tools you use to access it.  The EHR is one such tool.  From the physician perspective, it ought to be digital library of data, making it easy to access information about a given patient, disease, medication, treatment, diagnostic, clinical trial, outbreak, et cetera.  Having accessed it, now display it, analyze it, and otherwise compute with it.  That's a lot to ask for from one application.  Mapping, charting, searching, keeping up with current events.  Heck, that's a lot to ask for from one standard. 

Not everything that is data is easily stored or computed.  Not every stream of data need be stored in human readable form.  Yep, XML might be the answer, but I think there are a heck of a lot more questions.

I used to work with almanacs, thesauruses, dictionaries and encyclopedias as structured text.  Each one had rich markup that worked very well inside the book.  In other words, the markup of a single publication worked well with data structures designed in that publication.  But getting them to work together across publications, that was very different, and a difficult prospect.  We still struggle with this in the "semantic web" today.  It shouldn't be a big surprise that the XML representations across these different viewpoints of healthcare might work well from that one perspective, but not from others.

Saturday, August 13, 2011

Security and Transport Specifications Available for Public Review

A message on behalf of
The Office of Standards & Interoperability
Specifications Available for Public Review
ONC seeking comments on security and transport specifications

The Office of Standards & Interoperability within ONC is pleased to announce the availability of the security and transport specifications for public review.
They are accessible at

If you have any comments please direct them to the Feedback page at
(You may have to request membership if you are not already a member on the wiki page.)
There are going to be two public calls between now and the end of September to discuss the specifications, reference implementation and the test cases. 

The first public call will be held on Wednesday, August 17th, 2011 at 11:30-12:30pm EST and the second call will take place on Wednesday, August 31st at 11:30-12:30pm EST. 

ONC will continue to take comments on the Feedback page until Friday, September 16th, 2011.  
Important Dates
  • 1st Call - Wednesday, August 17th, 2011 at 11:30-12:30pm EST
  • 2nd Call - Wednesday, August 31st, 2011 at 11:30-12:30pm EST
  • Public Comment Closes - Friday, September 16th, 2011
  • Disposition Completed - Friday, September 30th, 2011
 If you have any questions please direct them to Matthew Rahn ( or Farrah Darbouze (

IHE Patient Care Device Technical Framework volumes, supplement and User Handbook published

IHE Community,

IHE Patient Care Device Technical Framework volumes, supplement and User Handbook published

The IHE Patient Care Device Technical Committee has published the following Technical Framework volumes as of August 12, 2011:
  • Volume 1 (PCD TF-1): Integration Profiles
  • Volume 2 (PCD TF-2): Transactions
The documents are available for download at

The Committee has also published the following supplement to the IHE Patient Care Device Technical Framework as of August 12, 2011:
  • Infusion Pump Event Communication (IPEC)
This profile will be available for testing at subsequent IHE Connectathons.  The document is available for download at

In addition, the Committee has published the following User Handbook as of August 12, 2011:

  • IHE Patient Care Device User Handbook – 2011 Edition
The document is available for download at

Comments on all documents can be submitted at

Thursday, August 11, 2011


If your doctor doesn't have an EHR, print this out and hand it to him or her.

Better yet, reference this URL: as their e-Prescription.

Wednesday, August 10, 2011

Transcript from HITstd Chat on HL7 CDA

I probably won't post the transcript after every HITstd tweet chat since you can get it online, but here is the transcript from our very first. We included CDA experts from around the world, including the US, Australia and South America to answer your questions about CDA.

Thanks to the Fox Group, LLC for preserving a directory of Healthcare Hashtags, and maintaining chat transcripts.

 Content from Twitter