To put this more into context, let's look at recent discussions around HL7's FHIR specification, and the ongoing work and activities around that. There are at least four tracks here:
- FHIR DSTU Release 2 is presently being developed.
- The Intersection of CCDA and FHIR is being explored.
- As part of the IHE DAF Whitepaper, one of the gaps was on granular access in a RESTful fasion, and so there may be a profile proposal in IHE to address this, if so, it will likely involve FHIR.
- The DAF Workgroup has determined that their next activity will be a FHIR profile for data access.
The challenge is that each of these tracks is already packed with stakeholders, and they greatly overlap in several different areas. This is a case where more is not necessarily better. You all should know by now that throwing more people at a problem doesn't necessarily produce results faster, or better.
I encourage folks to sync up, and to engage in existing projects and initiatives rather than starting a new one. Waiting may be hard, and not being in control may feel a bit disenfranchising. However, standards development at this scale usually is a do-ocracy and a meritocracy. I've been in the unenviable position of having to track the same project across multiple organizations back in the days of ANSI/HITSP. Let's not repeat those mistakes. Let's keep it together, because if we don't, what we'll find is that we don't have one standard, but rather multiples, and that won't make anyone happy.
Keith
P.S. As the person who was considering taking the lead in IHE to develop the proposal for a RESTful (FHIR-based) version of the IHE QED profile, taking that aforementioned advice into consideration, I may well NOT develop that proposal. It's more important to me that it be done right than it be developed by any single organization. This is something that could be better institutionalized in ONC's S&I Framework.
0 comments:
Post a Comment