Argonaut Clinical Notes Implementation Guide (Release 1.0.0 )

This page is part of the Argonaut Clinical Notes Implementation Guide (v1.0.0: Release) based on FHIR R3. This is the current published version. For a full list of available versions, see the Directory of published versions

Argonaut Clinical Notes CapabilityStatement

This profile defines the expected capabilities of an Argonaut Data Query server when conforming to the Argonaut Data Query Clinical Notes IG. The CapabilityStatement resource includes the complete list of actual Clinical Notes profiles, RESTful operations, and search parameters supported by Argonaut Data Query Servers. Servers have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

  • FHIR Version: 3.0.1
  • Supported formats: xml, json
  • Published: 2019-03-04
  • Published by: The Argonaut Project

FHIR RESTful Capabilities

The Argonaut Clinical Notes Data Query Server SHALL:

  1. Implement the RESTful behavior according to the FHIR specification including returning the appropriate response classes as described in the FHIR specification for FHIR RESTful API.
  2. Support json resource formats for all Argonaut Clinical Notes interactions.
  3. Declare a CapabilityStatement identifying the list of profiles, operations, search parameter supported.
  4. Support xml resource formats for all Argonaut questionnaire interactions.

Security:

For general security consideration refer to the Security and Privacy Considerations.

RESTful Capabilities by Resource/Profile:

Summary of Operations

  • SHOULD support the $expand operation.

    • Summary of Search Criteria

    Resource TypeSupported ProfilesSupported SearchesSupported Includes
    DocumentReference

    Argonaut Clinical Notes Profile 

    		 _id, class, created, patient, type, class+created+patient, class+patient, created+patient, created+patient+type, patient+type
    DiagnosticReport

    Argonaut Diagnostic Report Profile for Report and Note exchange 

    		 _id, category, code, patient, date, category+date+patient, category+patient, code+date+patient, code+patient, date+patient
    Binary _id

    DocumentReference

    Supported Profiles:

    Argonaut Clinical Notes Profile 

    • The search parameters created, class, and type MAY NOT be available as a single search parameter but SHALL be available in the combinations listed below.

    Reference Policy: resolves

    Versioning Policy: versioned

    Profile Interaction Summary:

    • SHALL support create, read, delete.

    Fetch and Search Criteria:

    • A Server SHALL be capable of returning a DocumentReference resource using:
      GET [base]/DocumentReference/[id]

    Search Parameter Summary:

    ConformanceParameterTypeExample
    SHALL_id token GET [base]/DocumentReference?_id=[id]
    SHALLclass token GET [base]/DocumentReference?class=[system]|[code]
    SHALLcreated date GET [base]/DocumentReference?created=[created]
    SHALLsubject reference GET [base]/DocumentReference?patient=[patient]
    SHALLtype token GET [base]/DocumentReference?type=[system]|[code]

    Search Parameter Combination Summary:

    ConformanceParameter CombinationExample
    SHALLclass+created+patient GET [base]/DocumentReference?class=[system]|[code]&created=[created]&patient=[patient]
    SHALLclass+patient GET [base]/DocumentReference?class=[system]|[code]&patient=[patient]
    SHALLcreated+patient GET [base]/DocumentReference?created=[created]&patient=[patient]
    SHALLcreated+patient+type GET [base]/DocumentReference?created=[created]&patient=[patient]&type=[system]|[code]
    SHALLpatient+type GET [base]/DocumentReference?patient=[patient]&type=[system]|[code]

    DiagnosticReport

    Supported Profiles:

    Argonaut Diagnostic Report Profile for Report and Note exchange 

    • The search parameters date, category, and code MAY NOT be available as a single search parameter but SHALL be available in the combinations listed below.

    Reference Policy: resolves

    Versioning Policy: versioned

    Profile Interaction Summary:

    • SHALL support create, read, delete.

    Fetch and Search Criteria:

    • A Server SHALL be capable of returning a DiagnosticReport resource using:
      GET [base]/DiagnosticReport/[id]

    Search Parameter Summary:

    ConformanceParameterTypeExample
    SHALL_id token GET [base]/DiagnosticReport?_id=[id]
    SHOULDcategory token GET [base]/DiagnosticReport?category=[system]|[code]
    SHALLcode token GET [base]/DiagnosticReport?code=[system]|[code]
    SHALLpatient reference GET [base]/DiagnosticReport?patient=[patient]
    SHOULDdate date GET [base]/DiagnosticReport?date=[date]

    Search Parameter Combination Summary:

    ConformanceParameter CombinationExample
    SHOULDcategory+date+patient GET [base]/DiagnosticReport?category=[system]|[code]&date=[date]&patient=[patient]
    SHALLcategory+patient GET [base]/DiagnosticReport?category=[system]|[code]&patient=[patient]
    SHOULDcode+date+patient GET [base]/DiagnosticReport?code=[system]|[code]&date=[date]&patient=[patient]
    SHALLcode+patient GET [base]/DiagnosticReport?code=[system]|[code]&patient=[patient]
    SHOULDdate+patient GET [base]/DiagnosticReport?date=[date]&patient=[patient]

    Binary

    Reference Policy: resolves

    Versioning Policy: versioned

    Profile Interaction Summary:

    • SHALL support read.

    Fetch and Search Criteria:

    • A Server SHALL be capable of returning a Binary resource using:
      GET [base]/Binary/[id]

    Search Parameter Summary:

    ConformanceParameterTypeExample
    SHALL_id token GET [base]/Binary?_id=[id]