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.

Thursday, October 11, 2018

Challenges using SMART on FHIR for Multi-Vendor Authorization

Challenge by Nick Youngson CC BY-SA 3.0
One of the challenges for application developers in implementing SMART on FHIR is that of metadata endpoint discovery.  In order to initiate the SMART on FHIR authorization flow, the application developer needs to know the metadata or Conformance endpoint for the FHIR Server it is going to communicate with.  However, this endpoint is going to vary based on the vendor supplying the FHIR Server, the version of FHIR that is supported, and possibly even the healthcare organization deploying it.

The problem here is in the use of metadata as a way to discover the authorization endpoint, when in fact, the challenge for application vendors is configuring to support multiple endpoints with the same application.  If you use MyChart or other apps to access your health records (as I do), you can see how this plays out when you go to login as a patient.  The first step of your login process has you identify your state and healthcare practice (this shows up in other applications as well).  I'm certain that somewhere in that application and others like it, that selection process is doing something to resolve the practice specific endpoint details.

In a single vendor environment, it's pretty easy to address this, but when developing an application to support multiple environments, this can be quite challenging for the application developer.

NO, this isn't a claim that we need a global SMART on FHIR endpoint directory (although that is one way to resolve this issue).  It's more a statement that we've combined the process of conformance inspection with the problem of endpoint discovery.

Think about it: If your authorization endpoints are different, it is also likely that FHIR conformance associated with those endpoints could be different.  Why should they both use the same mechanism.

This creates a challenge for patients, because it means that App developers are likely unable to support as broad a variety of endpoints as they'd like simply due to the configuration challenges presented to them.

Smart SMART developers will obviously work around this.  One possibility is to modify the Launch sequence so that the application first asks the patient where their practice is located through some sort of internally managed directory, so that the application first selects the practice, and then the directory resolves the authorization endpoints AND the actual FHIR conformance endpoint the application can use to customize its operations based one what capabilities are available.

This would allow patient facing SMART applications to support multiple versions of FHIR from multiple provider organizations.

There are a lot of other challenges.  Like anyone else, you have to get your product into the vendor's App store, and there's a lot more vendors than one has to typically deal with for smart phone applications (two covers a lot of territory here, whereas you need 5 or 6 for EHRs to get the same coverage).  And of course, you also have to get your app into the smart phone stores too.  Those aren't problems I'm going to try to solve here.


Wednesday, October 10, 2018

But We're Different

The number of times I hear this phrase no longer astounds me. In making this statement the speaker rejects an offered solution because of a perceived difference based on a special need. I've often seen that the special need is similar to other special needs where the proposed solution is already in use elsewhere (Healthcare people sometimes act as if they are the only ones operating in a regulated industry).

Some years ago I led a diverse workgroup across three quite distinct stakeholders trying to solve (what appeared to me to be) the same problem. By "lead", I mean cajoled, bugged, spanked (verbally), herded, out-waited, out-witted, listened, learned, fumed, and eventually rejoiced. Over the course of a year I watched this group evolve three completely separate white papers and approaches into one, and after that evolve into an IHE workgroup (QRPH). That workgroup now looks more deeply into their commonalities than they do their differences.

In my most recent dive into medication management I see a similar opportunity for CDS Vendors, EDI vendors, PDMPs, eRX & CPOE developers, payers and pharmacies to come together around a singular solution for improving medication orders.

The challenge for this group is quite different though. Unlike QRPH, which faced a lack of solutions, attention and funding, medication management has a plethora of all of the above. The poverty in what we have is commonality, dare I say it "standards".

"Oh, yes we do too have those." it will be argued. And I will agree, the solutions have standards in the same way that an organization with 10 priorities has any priorities.  And the challenge we face in replacing 10 with 1 is best summarized by this (de-facto) standard response.

Uses with Permission from XKCD

HAPI FHIR BDD Testing using Serenity and RESTAssured for DSTU2

One of the challenges I've had with using Serenity and REST Assured for testing with the HAPI Server is related to the Content-Type header used with STU2 implementations.

In STU2, that content type is application/xml+fhir and application/json+fhir respectively.
In STU3 and after, these changed to application/fhir+xml and application/fhir+json.
This is discussed in more detail in HAPI FHIR Issue 445.

I finally figured out (I think) where to make the changes to address this in Serenity to handle appropriate reporting.  The key challenge is that I wasn't able to track down the content body of requests in error (or even those that were successful).  That detail can be found in Serenity-core Issue 448.

Unfortunately, what this requires is a hack around the given() method in which one intercepts the given() call, gets the response back, checks to see if it is of an appropriate type, and changes the RestResponseHelper method to appropriately format the response body (an exercise left to the reader).

I'm testing this now (because I have nothing better to do at 3 am).


Thursday, October 4, 2018

Deep, Significant and Detailed HL7 Contributions

One of the points of the Ad Hoc Harley award is to recognize unsung heroes in heath IT standards. Almost all past awardees have been people I've worked with directly in standards development. While I have met the current awardee in person we've not spent much time collaborating on anything together, even though he's a fellow New Englander. Even so, I've still benefited from his work in standards, and his open source contributions.

According to two very smart people I know (one a past awardee), he's one of the smartest people they know. In addition to being a brilliant computer scientist [an assessment I heartily agree with having read, used and tweaked his code], he is also an accomplished singer who can harmonize with anything, a person of great humility, and a devoted family man.

While he was unable to be at the HL7 Working group this week, his work was demonstrated in several committee meetings.

His contributions include:

  • CQL
  • CDS Connect
  • Maintenance of the Quality Data Model
  • Invaluable feedback on the CDC Opioid prescribing guidelines.
  • Synthea’s Generic Module Framework

Without further ado:

This certifies that
Chris Moesel of MITRE

has hereby been recognized for deep, significant and detailed contributions to HL7 standards.