DSTU2 Ballot Source

This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

2.15.1 The Argonaut Project

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.

2.15.1.1 First Draft

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:

  1. Patient name / Sex / Date of birth / Race / Ethnicity / Preferred language
  2. Smoking status
  3. Problems
  4. Medications
  5. Medication allergies
  6. Laboratory test(s)
  7. Laboratory value(s)/result(s)
  8. Vital signs – height, weight, blood pressure, BMI
  9. Care plan field(s), including goals and instructions
  10. Procedures
  11. Care team member(s)
  12. Documents relating to a patient

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
Patient Details Patient
+ Encounter in support		 DAF Patient
DAF Encounter
Smoking status Observation DAF Smoking Status
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 For Care plan, there is no DAF profile. Argonaut participants have agreed to use just a narrative with no structured data
Procedures Procedure DAF Procedure
Care team Practitioner DAF Practitioner
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.

2.15.1.2 Lists, and "No Known [X]"

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:

  • Problems - a list with the LOINC code "11450-4"
  • Medication Allergies - a list with the LOINC code "48765-2"
  • Medications - a list with the LOINC code "10160-0"

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.

2.15.1.3 Conformance Rules

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.