Hello Siri, How Are You?

I know I'm late, but with the impending announcement of the next insanely great thing, I thought I'd go through my old Siri conversations to share. This was my first, when I got the phone and introduced myself to Siri.

Before I go further, let's get the silly stuff out of the way...

Yes, yes. It's only the most obvious Monty Python and Douglas Adams references in the Universe.

What happens if I simply say, "The Beatles?"

Cool.

Now let's settle into the groove of everyday life. Good morning, Siri.

Okay, so you can't read me the weather. So much for leaving you in my pocket as I walk out the door.

At least you understand me, even when I, uh... don't quite enunciate clearly.

...most of the time, anyway.

Okay, sometimes.

Er, I may need to work on my pronunciation.

Sometimes, I press the Siri button by accident, or forget what I wanted.

Back to everyday life, I'm hoping Siri can guide me to my meeting... 

...or not. I thought Siri stored a conversational context to help answer questions. Does Siri not remember my most recent questions? How do you get from this meeting to my own address? Or does she think I should skip out on my meeting and just go home?

Now where's that to-do list? 

ARGLE BARGLE!!!

I can already tell, this is going to be way more fun than autocorrect.

EMRs, iPods, and Saddlebags

I've heard that the size and shape of the modern hard-cover book was determined by the carrying capacity of 15th century saddle bags because after the invention of the printing press people had to carry those books far and wide on horseback, and the size and shape of the iPod was determined by the size and shape of your average front shirt pocket. This makes me wonder: what is the size and shape of the ideal electronic medical record?

What is a C32/CCD?

HealthUnity has a pretty good explanation of HIE technology including their HIE Use Cases. Documents on transmitted through HIE systems today typically conform to the HL7v3 Clinical Document Architecture (CDA). The Continuity of Care Document (CCD) is the most common of these, meant to be what your doctor needs to know at a glance. It looks something like this:

It's a clinical document with basic information about you and your doctors (any health care providers, really), information about the document itself (author, time of creation, purpose, etc), and a structured body which contains some number of sections - one for each category of health information being shown. For example, allergies, vaccinations, and current medications may be of immediate use, with the latest results, vital signs, and diagnoses. Much more can be documented depending on the purpose of the document.

To summarize: You (the patient) are the record "target." Every provider involved in the events documented is conveniently listed up front with contact information, followed by one or more sections. A section has a human-readable title and text followed by any number of coded entries. Each section is identified by its templateId (and so is the document itself, with its own templateId on the ClinicalDocument level).

Which sections are included depends on the document's purpose. A summary document has a bit of everything, while a lab or radiology report may have only the results section. There are many of these specified by HITSP (composite documents start with a "C" for example C32 is CCD and C84 is History & Physical).

Getting Started with HL7v3

Someone asked me how to get started learning HL7v3 and I thought, hmmm...

I went looking for a simple definition, and the best I could find was from PC Magazine:

(Health Level 7) ANSI-accredited standards for electronically defining clinical and administrative data in the healthcare industry from Health Level Seven International (www.hl7.org). HL7 provides standards for messaging, electronic records, decision support queries, medicine labels and the visual integration of data from different applications.

The "7" in the name comes from application layer 7 in the OSI model, which is the highest level where programs talk to each other. HL7 does not deal with the lower levels of the OSI model, which are the transport and network protocols.

Okay, so where to start.


RIM
Reference Information Model. You can represent anything with this, all the basic building blocks organized by structure but not use case. It is typically implemented in XML, and can therefore be represented by an XML schema, or by a set of interfaces in an OO programming language.

The RIM can be thought of as the data and workflow model. The HL7 Standards Blog did a good brief description of this, and I would recommend reading their blog post, HL7 V3 RIM: Is it Really That Intimidating?

The RIM consists of actors, actions, relationships, roles, and entities. Everything happening in the course of care is an Act, and each Act may have any number of Participations, Roles, and Relationships between Entities. For another overview, see the HL7 Australia page on HL7 V3 Resources. Obviously this is as generalizable as possible, so to do useful things it is necessary to constrain the model in different ways, which leads us to the Clinical Document Architecture (CDA).

CDA
The standard for representing clinical documents using the all-purpose RIM. The Clinical Document Architecture ... the actual data structures we use in representing health information. Where the RIM represents structures, CDA organizes those structures into use cases. CDA R1 is finalized. R2 is not done yet. At least, the standard isn't finalized and is subject to change.

There are many standards documents within the CDA model, but they can be divided in two categories. There are the building blocks which define document components, and there are the documents themselves, which aggregate the components into complete clinical documents.

Two commonly used building blocks are C83 sections, and C80 code sets. Most clinical documents can be thought of as collections of C83 sections, with data encoded as prescribed by the corresponding C80 specification.


At the 2009 Connect Seminar, a simple diagram of the CDA standard relationships was given as part of a presentation. The full presentation may be downloaded from www.connectopensource.org (PowerPoint):

You can see the different types of documents

• C28 - Emergency Care Summary
• C32 - Summary Documents using HL7 Continuity of Care Document (CCD)
• C38 - Patient Level Quality Data Document
• C48 - Encounter Document
• C78 - Immunization Document
• C84 - Consult and History & Physical Note

These documents are all defined in terms of which C83 components they contain.

There are many more types of documents, covering a wide range of use cases. A full list of the CDA document standards can be found on the HITSP Site. You can also see my earlier blog post about how CCDs are built.

Really, that's all you need to get started. Learn the RIM, choose the HITSP CDA documents applicable to your use case, and study the C83 sections and C80 codes needed. Then you're ready to get to work. Happy coding!

Java 7 Launch Event

Java 7 is scheduled to be GA this summer. A video of the official announcement can be found here:

http://www.oracle.com/us/corporate/events/java7/index.html

A summary of Java 7 features (my rough notes from the talk):

JSR 292 - invokedynamic - the davinci machine

more languages on jvm, new bytecode, dynamic languages

Project Coin JSR 334

small changes, syntactic sugar, String in switch, constructor generic inference, multi-catch, try with resources to properly close all resources

Concurrency and collections updates JSR 166y

lightweight fork/join framework

network and file system JSR 203

zip and jar archives

enhanced JMX agent and mbeans from jrockit

security: elliptic curve cryptography, TLS 1.2, DEP

unicode 6.0

Windows Server 2008 support

JDK7 to be released July 28

JDK8 to include jigsaw, closures late 2012 - possible JSON serialization

Yet Another Google Health Memorial Blog

Me Too! Me Too!

I wanted to wait at least a few days to let everyone else pile on Google Health before I threw in my two cents from the peanut gallery. Of course there has been plenty of I told you so, should have listened, and here's where we went wrong, all rightfully so. If you want to hear that, buy me a drink sometime. Right now I don't want to repeat what's already been said, except for what deserves to be repeated: I will trust my doctor and primary care facility to store my medical records, and no one else. That is the only way it will work.

Now, let me add this: Google Health was too generic.

Specialization is Your Friend

The comparison has been made between "tethered" and "untethered" PHRs. It would seem logical that providers want to keep patients - more treatment means more revenue - and that makes people tend to build patient portals which drive patients into their own institutions (and profit centers) and not to their competitors. I don't look at it this way. I think each provider facility is so specialized that they look at a general-purpose PHR and think, "This isn't exactly what my patients need." If it's not exactly what the patient needs, it's useless, possibly harmful. Even among the few large makers of traditional EHR systems, every single installation is different and highly customized. Why wouldn't patient systems be just as specialized?

Every hospital has its specialties, its centers of excellence, and a patient population more or less centered around what it does well. Let's say, for example, a referral hospital specializes in transplants. They are in the best position to design a PHR-type system with the features that transplant patients need, and transplant patients will flock there for treatment with or without a PHR.

Say another hospital treats a lot of cystic fibrosis patients. They, too, have an idea of a different set of features that will serve their patient population best, and if they are very good, it is entirely possible that nearly every cystic fibrosis patient in the country will have an account on their patient portal. One only needs to look at primary care facilities such as Kaiser, the VA, and Palo Alto Medical Foundation to see the first hints of how this can work.

If you start out by defining your patient population as "everyone," how are you going to even think about what features are needed most? Most common denominator? Most efficacious numerator? It's a recipe for stasis and mediocrity.

Precisely what problem were they trying to solve? It's easier from an engineering standpoint to define the problem in terms of data. After all, Google's stock and trade as a company is moving and analyzing data in large amounts, so naturally they tackled the health record head-on by building a nearly exact replica of a standard patient summary document and not much else.

What we have here is not a health record problem, it's a health visualization problem.

Physician, Heal Thy Computer

It's going to be up to the clinicians to figure out what patients need, and can use, from web technology. If you are a physician and have a great idea, you will have no trouble finding talented engineers to build it for you. Even if you have a lousy idea - like Google Health proved to be - you can see there's no shortage of talent, dedication, and know-how to make it happen.

What we need is something that lets clinicians with good ideas implement them, on their own EHR systems, in small pieces. Up to this point, if you wanted something as simple as a glucose monitoring chart for your diabetes patients, it took a lot of work just to build infrastructure around getting the data from its various sources and loading it into a web application. What if you could devote 90% of development time to data visualization, instead of data plumbing? Then we can let a thousand flowers bloom.

What if, eventually, patient records could aggregate from diverse sources into your system, making your patient portal a place to store, view, and analyze a personal health record for as long as you have patient consent to keep it within your facility? What if the PHR was an entity of pure data, and followed the patient from system to system? As long as you have a primary care facility, would you even need a Google Health?

Engineering is a marvelous and noble profession, but clinicians are coming from the more important - and complicated - side of the equation. I've been programming since I was 12 years old and the most difficult, complicated, incomprehensible system I've ever come across is health care, only to hear a respected, practicing physician look at computer diagrams and say, "I don't know that technical stuff." Yes you do. Healthcare is all technical stuff. Anyone who can understand medicine enough to practice it, can go on to say, "I know what these particular patients need from a medical record." That's who will be driving the technology forward.

Google Health is dead. The PHR is just getting started.

Hey @fitbit ur doin it rong

That new fitbit device looks pretty nifty. It even has "social." You can connect with your friends, and it keeps a leader board for you all to watch. The past week, the past month, that's the game. I don't see a lot of action there. I'd rather have some good casual games, small enough to fit in a game with friends one afternoon.

For example, take the famous 24 Hours of LeMans race, where drivers race on a track for exactly 24 hours, at which point whoever completed the most laps wins. You can do the same thing with a pedometer, and you can use any time period: a day, an afternoon, a week - as long as somebody gets to say, "Ready, set... Go!" When the time is up, whoever has been most active wins. After all, being active is what fitbit measures.

Can everyone play? Even couch potatoes?

Yes, if you do a good job handicapping the races, like you would in the game of golf. For example, I walk a lot -- 45 minutes to and from work every day, plus to the store and everywhere else. I drive maybe once a week. My friend leads a rather more sedentary lifestyle, to put it mildly. How can we compete against each other? The game could analyze our past fitbit records and use that level to assign a handicap for each player. I don't play golf but I think that's how it works.

This will make real competitions possible, regardless of lifestyle or current fitness level. How would you feel knowing you could beat your marathon-running buddy in a fitbit race?

That's it, casual competition with friends, each of us playing to our own level of health. If fitbit can do that, I'll buy one just because my friends are doing it.