The Argonaut Project addresses the recommendations of the JASON Task Force, a joint task force of the HIT Standards and Policy Committees and is a joint project between HL7 and the following organizations:
The purpose of the Argonaut Project is to develop a first-generation API and Core Data Services specification to enable expanded information sharing for electronic health records, documents, and other health information based on the FHIR specification.
This is the first draft; the scope of this draft is to present a simple API that provides patient access to Meaningful Use based data sets. This simple API is the basis for consultation and testing through the FHIR connectathon process with the intent of developing a solid basis for Meaningful Use based access to data in the forthcoming DSTU2 ballot of FHIR.
For the purpose of the HL7 connectathon, server (patient portal) implementations should implement the Fetch Patient Record operation, and return the following Meaningful Use based Data:
The connectathon will be open for both client and server (e.g. patient portal and patient data access tools). For further information about the connectathon, including event details, security arrangements, and test/development tools support, see FHIR Connectathon 8.
The Meaningful Use profiles for the connectathon are mostly those defined for the DAF Implementation Guide. Specifically, this is the map between the MU data list above, and their corresponding FHIR resources and DAF profiles:
|MU Data Item||FHIR Resource||DAF Profile|
+ Encounter in support
|Smoking status||Observation||C-CDA Smoking Status Observation|
|Problems||Condition||DAF Condition (a.k.a. Problem)|
|Medications||A combination of||DAF:|
|Medication allergies||AllergyIntolerance||DAF AllergyIntolerance|
|Laboratory test(s)||DiagnosticOrder||DAF DiagnosticOrder|
|Laboratory value(s)/result(s)||DiagnosticReport & Observation||DAF Diagnostic Report / DAF Results|
|Vital signs||Observation||DAF Vital Signs|
|Care Plan||CarePlan or CarePlan2||Not done yet (HL7 is considering two different approaches here)|
|Care team||Practitioner||Not done yet|
|Patient Documents||DocumentReference||Not done yet (will be consistent with IHE use in the MHD profile)|
Note that the DAF profiles identify specific conformance requirements around search parameters. For the purposes of the connectathon, implementers are not required to implement search for the individual resource types - only the "Fetch Patient Record" operation is required. As a result, the DAF rules about search do not apply.
However implementers should note that the DAF and JASON taskforce work in this space is closely related and the DAF rules should be understood as candidates for the JASON taskforce deliberations in this space. For this reason, implementers are encouraged to implement these for the connectathon and/or to comment on them in depth.
Where no particular profile is nominated (not done yet), implementers are free to experiment and make recommendations for the next phase of development, which is expected to refine this list and the details of the profiles based on implementation experience.
In the FHIR specification, a patient's problem list, etc. consists of 0 or more instances of the Condition resource. These are found in the Bundle that is returned from the "Fetch Patient Record" operation.
FHIR also includes a List resource that represents a logical list of items, such as a problem list. As well as providing list status tracking information, the list carries an important data element. If the list is empty, it can indicate a reason why. For consistency in the returned data, all responses to the Fetch Patient Operation SHALL return the following lists:
If these lists are empty, they SHALL contain a reason why (which may be "not supported in this source" or equivalent). If they are not empty, all the relevant resources for the list SHALL be explicitly referenced in the list items.
Clients that request a patient record should only treat problems, medication-type and allergy/intolerance resources that appear in the patient record as part of the history if they are listed in the relevant list resources. Otherwise, they may have been provided as supporting data for other resources, but are not included in the patient summary.
The "Fetch Patient Record" SHALL always return a patient record that conforms to the profile identified above, and SHALL include a list for Problems, Medications, and Medication Allergies. The allergies list may include non-medication allergies.