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.

Friday, August 18, 2017

What's my Doctor's Direct Address

Lisa Nelson [a self-described CDA SME, Wife, Mother and designated daughter of two octogenarians] gave quite a fanciful skit and the ONC meeting last week.  In it, she pretended to be interrupted by her cell-phone, and had conversations with her youngest child [who needed a physical sent for camp], husband [who was sick while travelling], and eldest child regarding the fact that one of the grandparents fell and was in the hospital.  Throughout her response was the same.  Get their Direct address and I'll send ... and then some followup on what to do next [which was to mostly not worry because she had things under control].  That skit, she says, is her dream.

I believe in dreams.  An audience member sitting next to me said in aside: "I'm not sure many providers know or could even find out what their Direct Address was."

I decided to test this out, because I don't actually know the answer to that question for my provider. Nor does he, and NOT for lack of trying.  My secure message to him was quite simple (I've somewhat redacted his responses to preserve his privacy ... my data I feel free to share, but not his):

Do you have a direct address that could be used by other providers to send you data (e.g., a CCDA)? What would I tell them when they ask for it?

Very Same Day, 4.5 hours later.

Hello Keith, 

I have never been asked these technical questions in past and I am not sure. However, I have sent a message to our [Vendor] team to let me know how this works and I will let you know accordingly . I have not heard back from them as yet. I certainly know there are non [my hcp organization] providers who already have a link and they transfer the records directly to us electronically. [other hcp organization] hospital is one of them. 


Following Day

Hello Keith, 

I have left message with our [Vendor] team again and I have still not heard form our [Vendor] team for an answer. I am away from tomorrow for the next week. Certainly there is a electronic link for transferring records because, what I have seen is that [various] Hospitals send me some of the hospital records directly. I believe they have a link, not sure if it is CCDA. I think the [Vendor] team can establish a link if there is not already one in place with the provider you are mentioning. 

Thanks for your patience. 


I responded thanking him for his diligence and let him know my request wasn't urgent.  I then sent an e-mail off to the Medical Director for Informatics to track it down from the other end.

My point here though, it NOT to fault my healthcare provider.  When we design Direct Messaging, we included the notion that patients would be empowered by it in the addressing scheme.  Anyone could have a Direct Address, and it would be a secure way for all stakeholders in the HealthIT ecosystem to exchange information.

But it's not, and there are several different explanations I've considered for why that might be:

  1. Unintermediated electronic communication between patients and their physicians is avoided by policy due to HIPAA and ...
  2. Provider to provider communication is OK (I can get just about any provider to fax records with a phone call to another provider ... but fax them to my HOME number? God forbid, and HIPAA forfend.)
Now you and I know that the HIPAA boogeyman here SHOULDN'T exist.  But it does.  And because of it and years of prior policy, there's a challenge.

Other challenges include patient matching and trust.  When a provider gets a direct message from another provider about a patient, they implicitly trust the source, and are willing to match the patient with the data in the message.  But when patients start communicating via unintermediated electronic means, well, the information goes through a different set of filters.  The first step then is to be sure that one understands WHO the source of the communication is.  Did it come from, and was it intended to be about "my patient".

So, handing out Direct addresses for providers to patients seems culturally to be a bad idea, because you cannot actually know how they'll use it.

The answer here is to flip the addressing scheme, I think.  My Dr's Direct Address for me should be myuserid's+routing@hcpdomain.  When I give that address out, and someone uses it, the message, when received, can be securely accessed by hcpdomain, and it can route it internally as appropriate based on what I used for route.  So, if my userid was mg, and I set up my routing for my pcp to my doctor, his address would be mg's+pcp@hcpdomain.

We don't have to change the Direct Specification to support this.  That's already baked in to the specification.  Patient matching is built in when mg@hcpdomain is my identity as known to my healthcare provider.

It's not his "direct address", but rather "my direct address" for him.

Let's make it easy for patients and doctors to figure this stuff out.  The Direct Project was supposed to be the on-ramp to the health exchange super-highway.  What good is an on-ramp if patient's cannot find it.

    -- Keith

P.S. I had another post planned for the day, but the communication from my provider led me to rethinking Direct addressing, and I thought it relevant to the topics already discussed this week.

P.P.S and an update for the win: I asked someone who would know at my HCP's organization when I wrote the post, and was given w/in 12 hours. Unencrypted e-mail is SO effective (and completely legitimate for me and my HCP to use as I have given permission for that form of communication).

Thursday, August 17, 2017

When All Developers are Not Above Average ...

Ortona FL Lake Wobegon sign01
The reality of the world is that we don't all develop out of an office in Lake Wobegon.  Not all developers are above average.  Healthcare is challenging, we already know that.  By passing that challenge onto developers, we are simply transferring risk to the developer.  Making the hard stuff easy mitigates the risk, and makes it less likely for developers to do it wrong.

I talked about this earlier this week at ONC's Beyond Boundaries meeting, in the context of "Fit for Purpose" Standards.  The human mind has a remarkable capacity to find and take the easiest path. We need to design our standards with that in mind, and use those human factors IN the standard itself.

Good standards tell developers what to do to do the right thing.
Better standards tell developers how to tell if they are doing the right thing.
Great standards make it easy for developers to do the right thing.

Good standards are testable.
Better standards have tests readily available.
Great standards are computably testable*.

Good healthcare standards make health information exchange possible.
Better healthcare standards make health information exchange reliable and accountable.
Great healthcare standards make health information exchange easy.

I'll talk about measuring easy in a future post.

   -- Keith

* All the data necessary to validate conformance to the standard is readily available, from data models to value sets and everything in between.

You really don't understand the CCDA standard when ...

I often hear the complaint (about CDA documents) that: I just want to see ...

At the ONC meeting on Tuesday a provider remarked that in order to understand what was happening for a patient a provider read through 18 hundred pages of CCDA documents.  This was accompanied by the statement that they understood the standard.

I do (and did) protest.  If providers are reading that many pages, then the only thing understood about the standard is the word "Document", and understanding of the application of standards to interoperability in general is also lacking.  Just as in medicine where there is no singular magic pill to make a patient healthy, there isn't just one standard to apply to the various problems associated with interoperability.

CDA documents are snapshots in time of the data associated with a patient care event.  All the data elements found in the the dozen and a half elements defined by the Common Clinical Data Set. The CCD is supposed to contain the relevant and pertinent data, but we know that what is relevant and pertinent to one provider isn't necessarily to another. Even so, it's how the data that is presented to the end user (the provider) that is the problem, not the standard that gets the data from that data set from one provider to another.

Consider multiple ways to address this issue that have all been worked in other standards efforts:
  1. Consolidate data from multiple documents into a reasonable longitudinal view that reconciles information from across multiple sources of data.  There are OTHER standards that explain how to do this (e.g., the IHE Reconciliation Profile).  CCDA is about moving the data, and just like the web, you have to apply other standards to solve other problems.
  2. Use an XSL Stylesheet to make the data easier to read and arrange according to provider preferences.  HL7 and ONC ran a CDA Rendering challenge that produced a number of freely available open source solutions.  CDA is about communication of data.  It is up to applications to make it usable.  CDA isn't a standard for display, or a standard for application function.  It's a standard for communication.  
  3. Allow providers to incorporate the data as it becomes available.  If you implement workflows that support a 360 Closed Loop referral / consultation processes, and enable incorporation of the data into the EHR when it becomes available, you avoid trying to manage and consume multiple documents in "one swell FUPE*".
FHIR isn't going to magically change the challenge of viewing "all the data", but it is going to change the approach used by folks (and that will be the subject of a future post).

   -- Keith

* That's not a mispelling, but rather an acronym standing for Fowled-Up Process Execution

Tuesday, August 15, 2017

Beyond Boundaries Day 1 Takeaways

Information Blocking: The glass is either half empty or half full with regard to interop progress, depending upon where you stand to benefit.  Best data is two + years old, hard to understand if it is even relevant.  Progress is happening, best presentation showed the upward trends.  We need more/better data with real-time measures.  John Everson has the best presentation and backup for his assertions about progress.

Vocabulary (Semantics): If it isn't critical to care provided it is not as important.  Most of our discusssion was around SNOMED CT, LOINC and RxNorm (aka SOLOR).  ICD? CPT? Not necessarily relevant to clinical care.  VSAC is good.

Interoperability Networks and Infrastructure: I find it telling that among 6 of the 8 "nationwide networks" participating in the discussion, half of them are making progress on connecting to each other (Carequality, Commonwell and Surescripts) and are working towards the one network/multiple carriers model and the others are not quite there yet.

APIs: Perhaps the most boring and exciting panel yet, in that everyone is agreed that SMART on FHIR is the way to go.  Focus beyond that is in part where some would focus attention differently.  Essential the battle about the standard is over, the contest seems to be about who might pick up the implementation guide honorary mention, and the front runner (Argonaut Project) wasn't even on the panel... (Though Micky was the moderator of the next one).  FWIW, SMART is out for ballot on the standards track in HL7 this cycle

Third Party Uses: Standards we know (IHE, HL7 V2, V3, FHIR) = Cool, FHIR = Very Cool.  We R doing kewl stuff.  Noted complete absence of X12N from the discussion, even in payer channels where that might be natural to consider.

Some final notes: Tomorrow I am on the starting panel: Fit for purpose, and then we will hear from dietarty/nutritional, LTC, and Behavioral Health providors in a session titled "Across the Continuum", with wrap up from a panel moderated by John Halamka, and including Clem McDonald, Walter Sujansky and Aneesh Chopra.  I didn't see either John or Aneesh today, but both Clem and Walter made their presence known today.  

Monday, August 14, 2017

More Thoughts on OAuth2 Dynamic Client Registration in SMART on FHIR

Avinash Shanbhag writes:

Hi Keith

We had a question for you,  on your blog on “Dynamic Registration”, which I tried to post on the blog, but, somehow I don’t see it posted (Not sure, if you have ONC/HHS email filter on the commentsJ).

==== Excerpt from Blog ==

Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.
==== Upto here ===

From the above excerpt, it seems to indicate that each instance of App would get a separate Client ID/Secret. Is that really true? Our understanding is that the client ID/Secret is generated at the “App” level, same as any manual or self-service registration process would do;  and once done, the same ID (and secret if Confidential App) will be used by each instance of the App. So, in a sense, dynamic registration is no different than manual registration other than the obvious fact that this is done via API.

Here’s link to the SMART team’s web page that describes both the manual and dynamic approach

Could you clarify if we misunderstood your point, or if our understanding of the dynamic registration spec is wrong? If my post gets published, feel free to comment publicly.

Thanks in advance and looking forward to seeing you at the Interop Forum tomorrow!


If this is the dynamic registration call (extracted from the link above):

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json

   "client_name": "Cool SMART App",
   "redirect_uris": [
   "token_endpoint_auth_method": "none",
   "grant_types": ["authorization_code"],
   "initiate_login_uri": "",
   "logo_uri": "",
   "scope": "launch launch/patient launch/encounter patient/*.read user/*.* openid profile"
Here are some of the problems I see in it:

  1. There's nothing in the above that allows me to trust the application registration content in any way.

    Anyone can use this same data to register an application.  The application itself runs on the patient's device.  If giving the same data gives back the same client_id and client_secret, then these items really aren't secret.  Anyone get the redirect_uri, the initiate_login_uri, and the logo_uri and the client_name.  How does one get these?  Build a FHIR Endpoint and ask the application to register itself against your endpoint.  It will gleefully tell you what it uses to register itself.
  2. Knowing what an application uses to register itself, one can easily determine what client_id and client_secret is assigned to that application.

    This can be done by building an application that follows the dynamic registration protocol using the values extracted via the exploit I explain in #1 above.
  3. There's nothing linking this registration back to a responsible party EXCEPT for an https: URL or three.

    I have 30 or 40 HTTPS urls I control, and all I needed was an email address to create one.  I think that providers need to take some precautions to safeguard healthcare data, and that means that there needs to be some way to trace it back to a responsible entity. That's a little bit more than what is required to create an https URL.  Also, not all redirect or login URIs would be to the Interwebs.
  4. Use of token_endpoint_auth_method assumes public apps are supported (applications that cannot manage a client_secret), and that client_secret won't be used.

    I'd prefer to put a "somebody else's problem field" around application identity management if I could.  Otherwise, I have to deal with a lot more infrastructure that I want, but some identity providers barf at this today (you know who you are).  Either I have to use an identity provider that supports public apps, or I can restrict support to private apps.  The latter seems to be preferable given the infrastructure needed to manage application identities.

    In the example given, there's no reason why this application needs to be public, given that it's redirect and login URIs are "on the web".

Clark Kent cosplayerSo, client_id and client_secret, if created and maintained on a per-registration basis, needs something extra to ensure that you can safely consolidate multiple registrations to a singular client_id and client_secret for any application registering with the same information.  Otherwise, to have these values actually be an id and a secret that MEAN anything, you have to do more work.  What good is a secret if everyone can know it.

That's where I get into the "too much infrastructure" problem, because now we start introducing stuff like PKI to be able to verify publishers of software statements, or external trust bundles (a la DirectTrust or NATE or ...) and ...

Dynamic registration might be the way forward, but it doesn't appear to be ready yet for prime time.


Friday, August 11, 2017

Thoughts on OAuth2 Dynamic Client Registration in SMART on FHIR

Some weeks I'm just slow.  I probably spent a week trying to figure out how to deal with Client registration for SMART on FHIR applications.  One of the things I discovered in the process after I did the math:

Think about the number of different applications that patients could use.  Oh, maybe a 100 if we are lucky.  Most of us will use one or two. I know from previous experience the average number will be around 1.1 (at least at first).

Think about the number of patients a provider sees in a year.  Say they have a panel of 2-3 thousand patients, they probably see somewhere between 1/4 to 1/2 of these annually.  Call it an even 1000.

Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.

Now, look at a 100 provider practice, and understand that some of the providers in that practice see the same patients that other providers do.  So 100 * 1000 * 50% (for overlap) 50,000 patients seen in that practice (NOTE: These are rough numbers, what is important is the magnitude).

Now, just think about the fact that if every 50% of the patients each use an application, and each one

requires its own client_id and client_secret, you now have 25,000 client_id and client_secret values for what, maybe 100 applications.  And if any of those applications are busted (meaning they register more often than they need to because someone missed something in the spec), you could have some applications registering daily or hourly or whatever the expiration time is on the authorization token, and now that number could really balloon.

Is this realistic?  Is it valuable?  Is it worth having to manage? Would it not be better to have 100 client secrets and client ids which you could then manage if necessary?

I know ONC is promoting use of Dynamic Client Registration, but I look at the cost of doing that, and I am quite certain that there really is a better way.  It's interesting that Twitter, Facebook, Google and many other API publishers outside of healthcare haven't been using OAuth 2.0 Dynamic Application Registration.

I'm wondering, is Dynamic Application Registration really Smart?


Thursday, August 10, 2017

Measuring Interoperability

One of the challenges facing ONC for more than the past decade has been measuring interoperability (yes, ONC has been around for  that long).  One of the responsibilities of the National Coordinator in the original order creating the office back in 2004 and continuing on to this day is to "include measurable outcome goals".

These are some things that one might consider measuring with regard to Interoperability:

  • Reductions in costs of care attributable to presence of absence of Interoperability
  • Application support for Interoperability Standards and APIs
  • Transmissions of Interoperable Information
  • Speed of Uptake of Interoperable Solutions
However, not all of these are "Outcomes".  They represent three different kinds of measures, and then something special.  Cost reduction is clearly an outcome. Application support is a capability measurement. Transmissions of information is a process measurement.  Speed of uptake I'll talk more about at the end of the post.

There really is no definitive or easy way to put a $ figure on the ROI of interoperability in healthcare without spending a great deal of time.  It takes a well designed study which can show before and after effects of an interoperability based intervention.  And it isn't clear how much of the $ saving could be attributed to technology, vs. other process changes involved that use that technology.  Yet, among the above, that's in fact the only outcome measure listed.

Application support for standards and APIs is a capability measure.  We can definitively show that applications have more interoperability capabilities than they have.  But we don't have good evidence linking that capability to outcomes.

Transmissions of interoperable information is something where we are actually measuring a process. For example, in ePrescribing, we are measuring the number of prescriptions sent electronically.  We also have some good studies linking that process to improved outcomes, but it's not a direct measure of outcomes.

Finally, the speed of uptake.  This is an interesting measure.  It shows something about capability, in that it demonstrates availability of a particular capability.  But is also demonstrates an outcome, one related to ease of use.  If we look at the ease of uptake and flexibility of HL7 Version 2, HL7 CDA, HL7 Version 3, IHE XD*, and HL7 FHIR, we can get a pretty good understanding of the complexity of the various standards.  

As we embark next week in discussions about fitness for purpose, this is what I would consider to be an "outcome measure" for success in standards selection.  Ease of uptake directly relates to products with interoperable capabilities in products, interoperable processes that can be delivered upon, and real cost reductions in implementation of Health IT solutions.

As we look at "Fitness for Purpose", I think we need to consider "adoptability" as one of the key metrics to consider.  That means that the standard needs to be readily available, easily understood and implemented.  It's a tall order for a standard to meet, and hard to tell how to get there, but I can say this: You'll know it when you see it, and it doesn't happen by accident or intention alone, but more like a bit of both.