Maturing FHIR Connectathon without confusing the marketplace

Grahame, being the fantastic Product Manager for FHIR that he is, is asking the FHIR community for input on how FHIR Connectathon should evolve. I started to write a few lines but realized that I had more to say than a few lines. (yeah, I know... blah blah blah)

IHE has been doing Connectathons for almost 20 years (First was in 1999 with Radiology). IHE did NOT invent the concept of Connectathon. I was involved in TCP, IP, UDP, NFS, TELNET, and FTP connectathons back in the late 1980s. They were almost exactly the same kind of events.   I have a detailed article on what a Connectathon is, and is not... please review it - What is Connectathon?  I have also written about how nice it is to see FHIR Connectathon changing.

I think IHE and FHIR need to be as distinct as possible, But clearly there will be overlap. Each holds a unique position today that those of us that are involved in both see clearly. However the outside world finds it hard to differentiate already. This perspective to the outside world should be seen as a very important factor. If the consumers of our standards and connectathons don't understand the value, or are confused by it; then it is not valuable or clarifying.  

This does not mean that the overlap should be avoided, it should just be deliberate and clearly communicated.  So far, FHIR Connectathon has been more of a 'hackathon', and that has been exactly what FHIR community needed. The value today: very quick (agile) testing of the specification, proving ground for app development ideas, safe place to share ideas and push oneself. A critical part of this success is that it is short (1.5-2 days), very inexpensive (compared to IHE Connectathon), very informal (compared to IHE Connectathon).  These are strengths of FHIR Connectathon today that we should not forget.

The mature part of that FHIR community is ready to move to a new step. I don't think that new step is all the way to what IHE Connectathon does, and certainly far away from certification (which is also what IHE Connectathon does for certain tracks).  The less mature parts of FHIR community do need a less formal place to play, however things like FHIR Dev Days are possibly filling this need?

So, where possible, cooperate with IHE Connectathon. Leverage the same tooling where possible. Leverage the same process and event space where possible.

IHE should focus on multi-standard use-cases, and domain specific use-cases. IHE should focus on end-to-end flows that are documented in a Profile or Implementation Guide. 

FHIR should focus on building block use-cases that use FHIR alone, and generally re-usable use-cases. FHIR Connectathon would be more the place to prototype, to investigate, to develop a concept, to build a consensus.

FHIR Connectathon should continue to advance the complexity of the scenarios, the Integration of small scenarios into larger ones.  Mature the testing of building block scenarios such that they can be held up as complete, something that can be used to do BDD or TDD. A 'standard' modularity beyond what we see today as a 'standard', that is not just the 'encoding', but also testing and block building.

This does not mean FHIR Connectathon doesn't do full end-to-end workflows. Just like it doesn't mean IHE would never do hackathon like things. The overlap will exist, it should just be clear.

Keep our eyes on the Purpose of a Connectathon

To a standards organization, a Connectathon is a way to mature the standard. Both IHE and FHIR have connecathon as a required part of their governance of maturity.

The purpose of a connectathon to a participant is to gain experience interoperating with your potential future partner in a real-world exchange. By focusing on testing in a safe place like a connectathon, one can push the limits of ones own software. The take-away is a confidence that when a customer needs your software to talk to that specific peer, you have high confidence that it will work right away, and if it doesn't then you have experience that guides your reaction including possibly calling on that personal relationship you created at connectathon. 

Formal checkmarks, or certification, are far less valuable than this. Mostly because reality will happen, and that checkmark or certification means nothing when reality isn't working.

Other articles of mine 

Apple should have a HEART

Apple has re-entered the Healthcare space with their new announcement about support for a person to maintain their health data on their iPhone. There is really nothing technically new, but new or not is not the important bit. What is important is that any visibility given to the Health Data portability problem is good for making changes.

My understanding of what has happened is that Apple has moved from their own proprietary API support, to support for Argonaut defined APIs. These Argonaut defined APIs would qualify as a 'standard', they are based on #FHIR at an older version - DSTU2. So their adoption of a standard API is big. It is not hard, many have done exactly this. But it is big because it is Apple; and with Apple we get marketing of the usefulness of the concept, and we get a motivation for Providers to support the Argonaut API.

The bad news is that this is DSTU2, and that brings a risk that these APIs will be frozen at a non-Normative version of FHIR. I hope this doesn't actually happen. I hope that they evolve as FHIR evolves to Normative. The fact they started with DSTU2, and are ignoring the current STU3, is not good news for this hope of future normative FHIR.

Consumer empowerment aspect

My understanding of what Apple has done is adopt the SMART-on-FHIR security method, and the Sync for Science privacy method. They expect the Patient (their user and iPhone owner) will navigate to each of their supported Healthcare Providers, interact with their portal to give authority to release the records to that iPhone application. This is a model defined as "Sync for Science", a really unfortunate name as the name came from the original scope but the solution is generally useful. 

The benefit for Healthcare Providers is that they manage everything about the identity linkage, they own the username (password) the patient uses at their portal, and they own the linkage from that username to their Patient ID, and they manage the Consent holding the patient authorization to release to a specified and future authenticatable application on the iPhone..

The Healthcare Providers usually mange the Identifiers by sending their known patients a postal mail letter with a username and a one-time-secret. The person logs into their portal, gives the secret, and then proceeds to create the password they want. Once this is done, the Healthcare Provider has confidence they can manage the username/password, and that they know strongly which patient that represents.

The Healthcare Provider manage consents using whatever system they have internally. The consent never needs to be in a standard form, or any specific form or availability beyond what their organization needs. It just needs to utilize OAuth mechanism to bind the instance of the application the patient is using with the patient authorization (consent).

Lastly, because it is a relationship with the Patient themselves, when the Healthcare Provider release the data, they are logically releasing the data to the patient themselves. So no Business Associate concerns.

Apple in this case is just hosting an application, they are also the author of that application. They never need to know the Patient Identity, but they will be given highly sensitive patient data.

Why Apple changes everything?

So why is the fact that Apple is just doing what many applications have done before a big thing?

Apple has a huge number of people in the Apple ecosystem. Therefor the effort that existing Healthcare Providers need to do to support Apple is a better return on investment. Even if one only considers the 'bang for the buck' in terms of the number of that Healthcare Providers patients (bang) for the level of effort to do the work (even if high).  Note this is a motivation for Apple previous architecture that used proprietary API, but use of standards add to scalability.

Apple people trust Apple will keep their information and information about what they do on Apple private. This is unlike other big identity providers like Google, or YAHOO. The Apple people are special in this way, but so is the Apple organization. They have a proven track record (unlike YAHOO) of keeping their data secure, and they have a proven record of not letting their data get mined for advertising opportunities (unlike google).  Therefore the people are less worried that Apple will know what healthcare providers they are seeing. 

HEART

So the current solution is absolutely fine. The problem it has is the ability to scale. This is where HEART comes in. HEART is a standard specification, for which I have participated in the standard development, and have blogged about it.

The basic explanation is that HEART leverages OAuth, specifically a configuration called User Managed Access (UMA), to enable an "Authorization Server" that is selected by the Patient to represent Privacy access control decisions according to rules the Patient chooses. Essentially moving the Privacy authorization decision out of the Healthcare Provider. 

This is done by giving high assurance to the Healthcare Provider that the patient has chosen a specific HEART server as their authorization decision service. Thus the Healthcare Provider can trust any PERMIT or DENY decision that authorization decision service (the HEART service) makes for that patient in that circumstance. This enables the Patient to establish rules ONCE, where in the Sync for Science model the Patient must set the rules as many times as there are Healthcare Providers holding data on that Patient. Some patients have a small number of Healthcare Providers, others have many.

Apple should have a HEART!

This is an elegant solution, but it needs some major new player to make it come to life. Enter Apple. The two factors I mention above are critical. Patients trust Apple, and Healthcare Providers like Apple. These two are unique, as I mention above, but that is not enough.

The third factor is critical. Apple knows high quality identity information about their customers. Thus it is more likely that as an Identity provider, they will be able to more accurately, and more authoritatively, build the binding between their Identity (apple ID) and the various Patient Identifiers at the various Healthcare Providers. This patient identity problem is the biggest 'technical' problem in ALL of the Health Information Exchange (HIE) solutions. Binding a realworld identifier with a Patient Identifier in a way that has few false-positives (hopefully zero), few false-negatives (hopefully zero), and can't be abused by malicious actors (authenticatable and traceable).

Further, the Apple ecosystem is a place where some trust can be placed. If there are malicious misuse of the healthcare data exchange, the Apple ecosystem can be used to find the malicious actor. This is to say that there is trust that Apple knows what the Apple user is doing, and can find Bad-Apples. (sorry, had to).

Conclusion

Is it critical that Apple start to build out their HEART solution? No, but it is exciting that there is finally someone that I think could pull it off.

See my articles on Healthcare #FHIR, Access Control, Consent, and Audit Logging. also Blockchain for no other reason than search optimization.