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.
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 ConnectathonTo 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