This showed up in my Inbox this morning via Grahame Grieve and was sent to the HL7 FHIR Mailing list. Given that there's a lot of interest in what Project Argonaut is, and few details, I thought others might benefit from this as well. I reproduce it here with Grahame's permission (and since that list is available for anyone to join, there's no issues there either).
Project Argonaut was announced last week. You can see the announcement here. That press release was intended for an external community, and didn't address lots of important questions for the HL7 community itself. So here's an outline of what project Argonaut means in practice for HL7
FHIR Ballot on May timeline
Project Argonaut arose in response to our concern that we may not be able to deliver the FHIR DSTU2 for the May ballot next year. Lots of implementers - a much wider community than the identified Argonauts - have a strong interest in that outcome. The Argonauts decided to step up and ask us what they could do to help us meet the May deadline.
We really appreciate that, and we're glad of the help. But like everything, it comes at a price. We haven't committed that we will absolutely hit the May deadline - we can't - but we've committed to giving it a really good shot. That does mean that there's going to more pressure than there already was, and the FHIR/HL7 leadership (including EC,TSC, FGB, FMG) will need to manage the impact of this on our community. Another price is that the Argonauts have specific goals related to the JASON task force report; Project Argonaut covers more than merely "publish the FHIR DSTU 2 in May"
Specifically, Project Argonaut will have 3 main sub-projects:
The first project is to review the way Smart-On-FHIR uses OAuth and OpenID Connect. Specifically, Dixie Baker will drive this, and consult with the Project Argonaut community and beyond to ensure that the arrangements meet their requirements and also are consistent with wider industry best practices in these regards.
This work is actually outside HL7. Once it's complete, and the specifications have been tested in real systems and proven satisfactory, it is our plan to work with the Security WG to bring the resulting spec into the HL7 community as a full standard, probably part of the FHIR specification (though not dependent on FHIR - this would have use in a wider context)
2/ CCDA --> FHIR mapping
Our biggest issue with the May ballot is mapping between CCDA and FHIR. It's our intent to publish a full detailed CCDA profile for FHIR, that will describe how to represent the same content in FHIR that is in CCDA, and provided detailed conversion support. Publishing this as a full profile is not part of the May ballot (and hasn't been for a while); instead, we plan to provide this as an implementation guide subsequently. But this will only work if we're confident that there's basic alignment between CCDA and FHIR, and we can only be sure of this once we've done detailed mapping between the two. So this detailed mapping is a pre-condition of DSTU 2; accelerating this is the principal outcome from Project Argonaut for the FHIR specification itself.
How this will work is that a small group of people - mainly the ones already doing the work on a volunteer basis - will be paid to focus a significant amount of their time on performing detailed mapping between CCDA and FHIR. This will be done openly, using normal HL7 channels (a mix of email, skype, wiki, and google documents). The mapping documents that this group prepares will probably be similar to the CDA -> FHIR mapping document (https://docs.google.com/spreadsheets/d/1KctdexG3oB2QBiBQNH1Rbt2uJ6DxQFROyIFKo5q95WU/edit#gid=1223244219) and everyone is welcome to observe/review/comment on the outcomes. Any issues in FHIR resources that this group identifies will be forwarded to the relevant owning committee for resolution using the normal committee processes (the small project Argonaut team has no authority in an HL7 sense).
3/ FHIR implementation testing
Although the Argonauts are supporting us to produce the FHIR DSTU 2, they have a specific interest in it - the parts that relate to the JASON task force recommendation around API based access to healthcare data. Based on this, the current draft for comment includes a brief Argonaut implementation guide (http://hl7-fhir.github.io/argonauts.html) that briefly describes Meaningful Use based access to EHR data and documents.
As part of the Argonaut project, we'll be performing several implementation based activities that have the aim of verifying that the DSTU and this profile actually are suitable for their purpose. Those of you who have already been involved in the FHIR project will know that this is basically business as usual for us, it's just expanding our existing approach to a new community. So one of the streams at the San Antonio Connectathon in January will be focused on the Argonaut interest of MU based access to data, which is using the "Fetch Patient Record" to fetch the patient record in MU compliant resources (note that the Argonaut interest is in granular access APIs, but we're just testing this most coarse access for this connectathon). There'll be other engagement activities as well, which will be announced as we get on top of them.
Plenty of people have asked "How do I get involved with project Argonaut?". There are two answers to this.
- In terms of supporting the HL7 project work directly (suitable for the existing HL7 community), reviewing the CCDA mappings and participating in connectathons as well as reviewing the draft DAF work and participating in the ballot cycles and related committee work are all excellent ways of being involved
- At a corporate level, lots of external organizations have expressed interest in becoming involved. We're working on scaling up the FHIR community to support this, in association with the Argonauts. There will be more news on this soon.
One final note: Lots of people have asked about the relationship between project Argonaut and the ONC DAF project. Well, it's simple: The Project Argonaut work is accelerating the first phase of the DAF project