Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Submitting WG/Project/Implementer Group


Justification and Objectives

The Argonaut R4 Implementation Guide is a copy of the the US Core Implementation Guide STU3 which is based on FHIR R4. This guide is the basis for further testing and guidance by the Argonaut Project Team. The guide will retain the US Core artifacts and names and provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing of the servers for conformance to the profiles and be capable of responding to all of the “supported searches” specified in the Argonaut Data Query Implementation Guide Server.

Argonaut R4 Implementation Guide changes were recently merged back in US Core Implementation Guide STU3 for an STU update for comment (version  3.0.1) which highlights all the changes since version 3.0.0.  There has been a significant comment and proposed change to fetching Provenance.  Therefore for pre-connectathon prep prior to this date use the US Core Implementation Guide CI Build as the basis for this Connectathon.

This track will use version 4.0.0 of FHIR.

******BREAK OUT SESSIONS *******

Saturday 2-3 PM Room M 103 (Capacity 30 People)

Our key objective is to identify problems with existing US Core 3.0.1 profiles.

  • Brief introductions of all
  • Collect open issues, priorities
    • MIssing data when the binding is required and there is no unknown codes
      • need to add clinicalStatus for Allergies and Condition to the list  - (tracker)
      • resource is not valid to profile - no way to DAR it
      • Client wants the data
      • what would you do?
      • Next steps
        • Remove ‘CarePlan.text.status’ from missing data
        • Add operationOutcome when missing and fail the request.
    • MedicationRequest intent for self-prescribed substances?
      • clarify that is alway going to be order?
      • required binding with no "unknown"  current tracker for R5 is getting pushback and wanting use case for this.
      • Next steps
        • Make it more explicit that self-prescribed will be ‘order’
    • technical corrections:
      • comparator expectation extension bieing stripped
      • Must support link is missing from profile introductions.
  • Progress on Provenance 
  • Merge vs Unmerge ( Combine vs Uncombine
    • Background and discussion to socialize this issue
  • Handled different ways…
  • Goals: way to know why data is disappeared and still retain information you care about and maintain privacy

Sunday 2-3 PM Room International 7

  • Progress Reports:
  • Follow up discussions on Provenance and Merge vs Unmerge
  • Servers requiring Status:

    e.g. for Epic:

    • Allergy ( requires clinicalStatus )
    • Condition ( requires category )
    • MedicationRequest (requires status )
    • DocumentReference ( require category )

    client need to code for this So the patient not really a SHALL is it really a SHOULD? is it unambiguous when fail that is a "hidden status requirement" ( testing perspective )

    Documentation erroneously states to put in

    should be ...

    Mismatch of Search Conformance between Profile of Same type

    specifically DocumentReference

    Do servers distinguish Search capabilities by Type or by Profile?

    if by type then the Search Conformance should agree between profiles

    if by profile then the Search Conformance does not have to agree between profiles - but the CapabilityStatement currently does not handle. - need to document this in: - unable to document programatically for each combo ( without custom extensions ) - differentiate by meta.profile or category for DiagnosticReport?

Related tracks

2019-09 Patient Track

2019-09 Mobile Health Data Exchange

Bulk Data (2019-09 Bulk Data and Analytics Track)

(used to help guide seating arrangements and possibly drive track consolidation)

Proposed Track Lead

Eric Haas

Expected participants

Who do you expect to be present? How many do you expect to attend?

See the Sprint Tracker! spreadsheet for signup information and participant details including endpoints.



Track Orientation

A webinar will be hosted on TBD  to share further participation information about this track.

We will use the Argonaut stream in Zulip for communication before, during, and after the connectathon:

System Roles

The following actors are part of the US Core IG:

  • US Core Requestor: An application that initiates a data access request to retrieve patient data. This can be thought of as the client in a client-server interaction.
  • US Core Responder: A product that responds to the data access request providing patient data. This can be thought of as the server in a client-server interaction.


Please review the US Core Implementation Guide CI Build  for the supported ArgoR4/US Core profiles, and searches as well as the extensive guidance surrounding each set of queries and profile usage.

See the Sprint Tracker! spreadsheet for signup information and participant details and endpoint access instructions


Test the servers for conformance to the ArgoR4/US Core profiles response to all of the “supported searches” specified in the Argonaut Data Query Implementation Guide Server CapabilityStatement for these profiles:

Precondition:  Familiarity with the  US Core Implementation Guide CI Build and the FHIR R4 specification

Success Criteria:  

  1. Demonstrate Conformance to the latest US Core profiles
  2. Successfully retrieve clinical data for a single patient using the  latest US Core profiles with the  “SHALL support” searches specified in the latest US Core IG Quick Start Section.
    1. Including retrieval of clinical notes as described in the Clinical Notes Guidance Page
    2. Including retrieval of Medication List as described in the Medication List Guidance Page
  3. Successfully retrieve data provenance in addition to the clinical data for a single patient using the included  latest US Core Provenance artifacts with the  “SHALL support” searches specified in the Argo R4 IG Provenance Quick Start section.
    1. There has been a significant comment and proposed change to fetching Provenance to use the revinclude search parameter instead of the custom  us-core-includeprovenance search parameter.  Therefore for pre-connectathon follow this Provenance QuickStart guidance 
  4. Successfully retrieve a "on demand" CCD document for a single patient using the $docref operation specified in the  latest US Core IG.

Bonus point:

  1. Successfully retrieve latest US Core artifacts using the defined as  “SHOULD support” searches specified in the  latest US Core IG for a single patient.
  2. Successfully retrieve  latest US Core artifacts using the defined as  “SHALL support" or "SHOULD support” searches specified in the latest US Core IG for multiple patients.


Run in Postman

( here is the link: )

or check the Postman Published Collection on public server:

    • Every Query
    • Set up environment and patient Id and you are good to go
  • Loaded unit test data in UHN Hapi Server R4 :
  • Patient 1 ( link to bundle1, bundle2)
    •  missing {'DocumentReference', 'Location', Medication',  'CareTeam', 'PractitionerRole', 'Device'}
      • Base url:
      • Patient id: 8b42051b-e45b-4032-926a-747affe4e09d
      • Practitioner id = 0000016d-1435-7d38-0000-0000000000c8P
      • Organization id: c44f361c-2efb-3050-8f97-0354a12e2920
  • Patient 2 ( link to bundle
  • Based on Synthea Data
    • sample synthetic data that is conformant to US Core R4
      • We added Provenance
      • Synthea should have clinical notes data ready by this weekend

Security and Privacy Considerations

Refer to individual Server implementation details in the Sprint Tracker! Spreadsheet.

  • No labels