Provider Directories at Direct Boot Camp 2.0

The ONC State HIE Program hosted a two-day workshop on NHIN Direct, the health information exchange protocol built on secure email (SMTP/S-MIME). There was quite a good turnout. I'm still fairly new to Direct, so readers will have to forgive (or correct) any innacuracies or misinterpretations on my part, as this is based on notes and conversations I had over the two days. The main areas of focus were scalable trust, security and interoperability, and provider directories. So without further ado, here's a brain dump of my two day dive into Direct.

The Big Question

The workshop opened with a question and crowdsourcing exercise. Everyone was given index cards upon which to write an answer. The cards were distributed and voted on, and the top five read aloud. The top answers were centered on education, outreach, and provider directories.

Provider Directories

This was the hot topic. There's a lot of interest in healthcare provider directories (HPD), trust, and bridging trust authorities. How does a HISP know which HPD to query for authoritative information, and whether the information returned is accurate, up to date, and trustworthy? Since the HPD is used primarily within Direct to look up addresses and certificates, this is a big issue.

At the HPD roundtable discussion a number of different views were brought together. A Federal Bridge was discussed, which using x.500 and x.509 to certify Certificate Authorities (CAs) and provide trust bundle functionality. This would be a distributed system of authoritative directories with the "source of truth" being at the edge of the directory tree, as close to the provider as possible, being that an organization with a direct relationship with the provider would be more trusted. However, how would x.500 deal with system which only use organization-level certificates, and not person-level certificates? What engagement model will motivate physicians to keep their information up to date?

A question was raised about the need for a standard response model supported across the country. It would be nice if states and the DEA supported certificates to verify doctor identities. Provider directories have strong verification and credentialing use cases. For example, in a federated model of authoritative sources, is there a potential for fraud or gaming the system? If a provider license is revoked in one state, what happens when the provider moves to a different state?

Another concern expressed was what information should be exposed publicly. There is a widespread perception that publicly available provider directories might open the door to spam, but the Direct protocol is very difficult to spam. HPD maintainers have a more legitimate concern: if they expose everything via web services, what's to stop a competitor from downloading the entire directory? This is the motivation for mutual authentication, to control who can access what. There needs to be agreement on what information to divulge and what to withhold. Western States Consortium has been studying this problem and is in the process of documenting their findings.

Mod Spec HPD

Direct20: Modular Specifications - Provider Directories from Brian Ahier

Mod Spec (MSPD) is trying to "future proof" the HPD specification and make it more modular. MSPD extended HPD for error handling, federation, and extensibility. The LDAP model is the same, but the WSDL and error handling have been updated. They are looking for pilot projects (contact Farrah Darbouze or Matthew Rahn for details).

ModularSpecs Home Page

AngularJS

"AngularJS is the future" said the guy with a full time job, startup, and weekly speaking engagements who seems to be at every major tech happening and apparently only sleeps between 2AM and 5AM.

"I need the future today," I replied.

So here it is, OmniBinder, an experimental Angular module to bind arrays of objects to a protocol, and RestAngular, a module which automates fetching data from REST APIs.


RestAngular Presentation and the source code used.

RESTful Health and the Internet of Things

In the Internet of Things everything has a URI, and everything that does something has a URI with RESTful services to invoke its functionality. It really is that simple. So what if we apply the same principle to health data? The Internet of Health? What if every element of the health record has a unique URI, standard RESTful interface and predicate ontology to make meaningful connections?

The RESTful Health Record

It isn't far off. The health record may be, and has been, implemented using a RESTful API where every patient, visit, report or event, every element of a medical history has a URI.

http://restfulhealth.com/Patient/123/Visit/456 http://restfulhealth.com/Patient/123/DiagnosticReport/789

The identifier can be any locally unique data, and often it is an internal database key for fast indexing. It may also be a contextual identifier, something referenced in the clinical payload. You could even asign a random UUID or a compound ID with your system's assigning authority. These identifiers will be used in semantic expressions and therefore must be permanent. An indelible audit trail is mandatory, just another fact of life in health care.

FHIR: Health Information as Resources

HL7 is working on a RESTful standard for health records. The HL7 FHIR project aims to provide a convention of URI plus a REST to the standard data structure. It's pretty simple, every entity or event has a base URI plus an identifier. Using the same high level structures as the CCD (better yet, the mercifully simple GreenCCD), you can create a set of services to view, add and update elements of a PHR.

http://restfulhealth.com/Patient/xx-xxx
http://restfulhealth.com/CarePlan/xx-xxx 
http://restfulhealth.com/Observation/xx-xxx
http://restfulhealth.com/DiagnosticReport/xx-xxx

The elements of a patient's health record are not nested inside the patient. Everything is done with references. For example, a care plan will contain references to the patient, all members of the care team, and relevant clinical data and events.

Ontology: Semantic Relationships and Queries

An ontology may be created to describe these connections. You're not bound by the standard data structure of CarePlan/Procedure/DiagnosticReport/Result. You can express your own grouping rules if you define the necessary relationships.

CarePlan hasMember Procedure
Procedure hasReport DiagnosticReport
DiagnosticReport hasResult Observation
hasReport isa hasMember
hasResult isa hasMember
hasMember is Transient

FHIR also includes the concept of resource bundles, so the care plan can include any number of events and they can be grouped in any way the care giver deems useful. The doctor may send you home with a monitoring device (or connect your existing device), and group your device's observations such that a diagnostic report can be run on the aggregate.

CarePlan hasMember Group
Group hasMember DeviceObservation




To help facilitate care coordination, you will need an ontology to describe the relationships between the  care provided and the health data elements with a corresponding set of semantic queries. What queries would be most useful? How would the data be linked? FHIR already has both internal document links and external resource links (attachments), which are essentially simple semantic connections. There's no reason why a more sophisticated model of care coordination can't be expressed in an OWL ontology.

I am now officially a big fan of FHIR.

A Jug of Wine, Facebook Graph Search--and Thou

We all know this Facebook graph search works. It's stalky creepy, but it works.
 


OK fine, so that search works, but this one doesn't? It's only one more parameter!
 
And, unlike searching for single females I went to high school with (which does work, but really who cares), yeah anyway, unlike that, this involves the real world. I'm... ummmm... asking for a friend.

All I'm saying is that some things are better in analog.

Ticking away the moments that make up the health record

For the purposes of illustrating precision in HL7v3 Time elements (TS), no time zone information is represented. As a nice bonus, this format is easily sortable as Strings or char arrays.

HL7 TS	Meaning
20121031235959001	October 31, 2012, 999 milliseconds before midnight
20121031235959	October 31, 2012, one second before midnight
201210312359	...and again one minute before midnight
20121031	Any time on the day of October 31, 2012
201210	October 1-31, 2012
20121	October 1 - December 31, 2012 (technically valid, but never used this way)
2012	January 1 - December 31, 2012
20	Sometime in the 21st century

Get it? It's a regular expression with assumed wildcard at the end.

Sketches of mHealth Standards

A June blog post by Keith Boone (aka @motorcycleguy), Convergence: CEDD, CIMI, IHE, FHIR, hData, HL7, mHealth and ONC got me thinking and sketching this simple diagram of how some of those pieces can fit together. 

It's more stream of consciousness than companion diagram, but there it is. A REST client/server wrapped in consent rules wrapped in security protocols (only client side shown), treating health information as RESTful resources. A URI for each patient, document, and fragment. 

The other thing that stuck out to me is the fact that we need data structures which can be use by both simple clients and highly complex ones. Where a mobile app may be reading and writing a half dozen data poings per entry, an industrial strength medical information system may be processing hundreds, and yet they operate on the same record. That's the essence of the CDA XML to hData JSON downshift, to allow interoperability between devices of vastly different capability.

Conversational Context in Smart Phones

Every time I use Siri I feel better if I say hi first. I don't know if it's polite or just makes conversing with a computer seem less weird. In this example, it's 8:26pm and I want to know what time the sun is going to be up tomorrow.

Close, but not exactly what I wanted. I happen to know sunrise tomorrow is a few minutes earlier than sunrise today (as summer progresses). So I clarify, and in the process I can see Siri's context engine at work. The next single word I say is interpreted relative to facts within the larger conversation.

Aha. She understands I'm talking about a sunrise. She gets the concept of tomorrow. She just doesn't know the answer. This is standard almanac data, something Wolfram Alpha should handle easily, but that's another story.

When Siri doesn't understand me, I usually find I'm asking for something that she's not programmed to recognize as a task. How do I know? I simply ask her.