Project Argonaut for the HL7 community

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

-- Keith

---

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:

1/ Security

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

Grahame

IHE PCC Profiles for 2015

Several IHE Domains met last week to discuss work items for the coming season of interoperability. IHE IT Infrastructure's 2015 Plan is described by John Moehrke on his blog.  IHE PCC started with eight work items, which we reduced to six and moved forward with.

RECON on FHIR takes the IHE Reconciliation work and adapts it for use with FHIR.  The basic challenge addressed by this profile is how to represent the reconciliation act.  Fortunately, FHIR has the List resource, and that actually covers everything we probably need for this profile, and was designed in part for this kind of use.

Clinical Decision Support for Radiology is one we'll be developing on behalf of IHE Radiology, but will likely remain a PCC profile.  The idea behind this one is that ordering physicians and radiologists here in the US will soon be required to verify that certain kinds of imaging orders are appropriate in order to get paid.  Other countries, while not so draconic in policies, are starting to have an interest in this sort of order review as well.  So, we want to have some sort of CDS verify the order as it is created, and as it is received, and to gather additional information if necessary.  For this, we'll likely use something like RFD if additional information needs to be gathered, but otherwise, simply return a token of some sort from the CDS system indicating that the order is deemed appropriate according to some guideline.  Then the receiver can simply verify the token if so desired, or test the order against its own set of appropriateness guidelines.

Device Observation Semantic Bridge will probably get renamed.  The point of this one is that some EHR systems would like to have a simplified summary of device observations created to make it easier for them to store the information, in CDA rather than HL7 V2 format.  So, we'll have a content profile that explains how to convert V2 device observations to CDA, create a summary and link it to the device observation.  We'll also have another integration profile that explains how to get vocabulary mappings from one system to another.  We will likely using CTS 2 to support that, although there may be some interaction also with FHIR.  One supplement, two profiles.

Remote Patient Monitoring takes what Continua and IHE have been doing and demonstrating for the last half decade and make it into a profile.  This one should really be very simple. The main point is to have a profile that enables Continua specifications to be tested at connectathon.  This one may go back to PCD once we have finished it, and we expect this one to come out early because it is so well understood.

Remote Read is a Workflow profile that will likely be owned by IHE Radiology when it is complete, but which will be supported by PCC during development.  I also expect to work on an appendix for IHE PCC which shows how to define a Workflow Profile using BPMN 2.0.

Data Access Framework will be an interesting animal.  One part of it will be a framework for supporting document queries in health information exchange, which will become a PCC Profile. Another part of it will be developing US National extensions, mostly on IHE ITI profiles for how they are to be used (which options and vocabulary are required, for example), and a last part of it will be an implementation guide which pulls it all together, that to be developed in IHE USA.

One profile didn't make it through because the author wasn't there to defend it at all. Other work includes cleaning up some long-standing problems with a missing transaction for "Share Content" in Content profiles, and doing further outreach in Nursing.

IHE Patient Care Coordination White Paper Published

IHE Patient Care Coordination White Paper Published for Public Comment

The IHE Patient Care Coordination Technical Committee has published the following white paper for public comment in the period from March 28 through April 27, 2014:

* A Data Access Framework Using IHE Profiles

The document is available for download at http://www.ihe.net/Public_Comment/#pcc. Comments submitted by April 27, 2014 will be considered by the IHE Patient Care Coordination Technical Committee in developing the final version of the white paper. Comments can be submitted at http://www.ihe.net/PCC_Public_Comments/

DAF Transport

Some initial thoughts on DAF "transport" layers:

• For syntax, we have ER7, XML and JSON.
• For Transport, we have SMTP, REST, SOAP/HTTP, and MLLP that are existing choices in various IHE profiles.  
• For Node authentication and encryption we have just TLS, but we really don't need to be able to replace that component.  
• For authentication/authorization we have IUA, EUA, and XUA.  

This is 4 * 1 * 3 * 3 = 36 different combinations.  We don't need to address all combinations.  Some make sense and others do not.

If you are working in a REST framework, your syntax will be JSON or XML.  Few other choices make sense.  For that, EUA or IUA would be where I'd go for authentication/authorization.  XUA is really designed for the SOAP stack.

If you are working in a SOAP framework, your syntax will most likely be XML.  I can't imagine someone using SOAP trying to parse ER7 or JSON.  You have a couple of choices for your XML.  Could it be FHIR, HL7 V3, HL7 V2, or ebXML.  This is an area where we have to apply some critical.  All of these are reasonable choices, but, why would you want to use FHIR with SOAP?  And while there are deployments of V2 messages using XML in SOAP, this is again, not really a platform combination that I'd see being terribly viable.

If you are working in SMTP, your syntax is really going to be about MIME, and inside that, well, you could have an XML attachment or a collection of things (e.g., an XDM ZIP file).  You will secure the content using S/MIME.  The query/response pattern is not a very common one with SMTP, but it has been done by many mailing list management packages, where a simple query can be submitted to the list server in the subject line, and the e-mail you get back is the response.

If you are working in MLLP, your syntax will most likely be ER7 or XML, and semantics would come from HL7 V2.  EUA is really the only choice for authentication as far as I can tell, but I'll have to check.  There may be some ways in which XUA could be supported here.  It might be amusing to translate ER7 notation into JSON via a more direct route, but that's already been done much better by FHIR.  There are a few cases where V3 has been communicated using MLLP, but this is a rare bird hardly ever seen in the wild.  A few known instances exist in captivity.

Transport	Syntax	Semantics	Authentication/ Authorization	Encryption
MLLP	ER7	HL7 V2	EUA	TLS
MLLP	XML	HL7 V2	EUA	TLS
SOAP	XML	HL7 V3/ebXML	EUA	TLS
SOAP	XML	HL7 V3/ebXML	XUA	TLS
REST	XML	HL7 FHIR	EUA	TLS
REST	XML	HL7 FHIR	IUA	TLS
REST	JSON	HL7 FHIR	EUA	TLS
REST	JSON	HL7 FHIR	IUA	TLS
SMTP	XML	MIME	S/MIME	TLS and S/MIME

This isn't quite as bad at the previous set of choices.  The only choice not presently supported somewhere by IHE is V2 Semantics with XML Syntax.  There's a lot more nuance and detail to cover.