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.
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
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 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
Post a Comment