US Core Implementation Guide
5.0.0 - STU5 Release US

This page is part of the US Core (v5.0.0: STU5) based on FHIR R4. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

Resource Profile: US Core DocumentReference Profile

Official URL: http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference Version: 5.0.0
Active as of 2022-04-20 Computable Name: USCoreDocumentReferenceProfile

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

To promote interoperability and adoption through common implementation, this profile sets minimum expectations for searching and fetching patient documents including Clinical Notes using the DocumentReference resource. It identifies the mandatory core elements, extensions, vocabularies and value sets which SHALL be present in the DocumentReference resource when using this profile. It provides the floor for standards development for specific uses cases. Prior to reviewing this profile, implementers are encouraged to read the Clinical Notes Guidance to understand the overlap of US Core DocumentReference Profile and US Core DiagnosticReport Profile for Report and Note exchange.

Example Usage Scenarios:

The following are example usage scenarios for the US Core DocumentReference profile. See the Clinical Notes section for additional detail on using this profile for Clinical Notes:

  • Query for all documents belonging to a Patient
  • Query for a specific Clinical Note type (e.g. Discharge Summary or Continuity of Care Document (CCD))
  • Query for all Clinical Notes belonging to a Patient
  • Write a new Note to a Patient’s Chart

Mandatory and Must Support Data Elements

The following data-elements must always be present (Mandatory definition) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Profile Definition below provides the formal summary, definitions, and terminology requirements.

Each DocumentReference must have:

  1. a status
  2. a code describing the type of document
  3. a document category
  4. a patient
  5. document referenced (content)
  6. the MIME type (i.e. contentType) of the document

Each DocumentReference must support:

  1. a business identifier for the DocumentReference (possibly generated by the transcription system or EHR)
  2. date and time the reference was created
  3. an author
  4. a code identifying the specific details about the format of the document — over and above the content’s MIME type
  5. the patient encounter that is being referenced
  6. clinically relevant date

Profile specific implementation guidance:

  • See Clinical Notes
  • The DocumentReference.type binding must support at a minimum the 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set
  • For a C-CDA Clinical Summary of Care (CCD):
    • The document type code is the LOINC code 34133-9 Summary of episode note.
    • The format code is urn:hl7-org:sdwg:ccda-structuredBody:2.1
  • The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.attachment.data.
    • Although both are marked as must support, the server system is not required to support both an address and inline base64 encoded data, but SHALL support at least one of these elements.
    • The client application SHALL support both elements.
    • The content.url may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or other endpoint.
      • If the endpoint is outside of the FHIR base URL, it SHOULD NOT require additional authorization to access.
  • The organization responsible for the DocumentReference SHALL be present either in DocumentReference.custodian or accessible in the Provenance resource targeting the DocumentReference using Provenance.agent.who or Provenance.agent.onBehalfOf.
    • Some system may also expose the same organization in referenced Encounter in Encounter.serviceProvider.

Usage:

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from DocumentReference

NameFlagsCard.TypeDescription & Constraintsdoco
.. DocumentReference 0..*DocumentReferenceA reference to a document
... identifier S0..*IdentifierOther identifiers for the document
... status S1..1codecurrent | superseded | entered-in-error
Binding: DocumentReferenceStatus (required)
... type S1..1CodeableConceptKind of document (LOINC if possible)
Binding: US Core DocumentReference Type (required): All LOINC values whose SCALE is DOC in the LOINC database and the HL7 v3 Code System NullFlavor concept 'unknown'

... Slices for category S1..*CodeableConceptCategorization of document
Slice: Unordered, Open by pattern:$this
.... category:us-core S0..*CodeableConceptCategorization of document
Binding: US Core DocumentReference Category (required): The US Core DocumentReferences Type Value Set is a 'starter set' of categories supported for fetching and storing clinical notes.

... subject S1..1Reference(US Core Patient Profile)Who/what is the subject of the document
... date S0..1instantWhen this document reference was created
... author S0..*Reference(US Core Practitioner Profile S | US Core Organization Profile | US Core Patient Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile | Device)Who and/or what authored the document
... content S1..*BackboneElementDocument referenced
.... attachment SI1..1AttachmentWhere to access the document
us-core-6: DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.
..... contentType S0..1codeMime type of the content, with charset etc.
..... data SI0..1base64BinaryData inline, base64ed
..... url SI0..1urlUri where the data can be found
.... format S0..1CodingFormat/content rules for the document
Binding: DocumentReferenceFormatCodeSet (extensible)
... context S0..1BackboneElementClinical context of document
.... encounter S0..1Reference(US Core Encounter Profile)Context of the document content
.... period S0..1PeriodTime of service that is being documented

doco Documentation for this format
NameFlagsCard.TypeDescription & Constraintsdoco
.. DocumentReference 0..*DocumentReferenceA reference to a document
... id Σ0..1stringLogical id of this artifact
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred): A human language.

Additional BindingsPurpose
AllLanguagesMax Binding
... text 0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... masterIdentifier Σ0..1IdentifierMaster Version Specific Identifier
... identifier SΣ0..*IdentifierOther identifiers for the document
... status ?!SΣ1..1codecurrent | superseded | entered-in-error
Binding: DocumentReferenceStatus (required)
... docStatus Σ0..1codepreliminary | final | amended | entered-in-error
Binding: CompositionStatus (required): Status of the underlying document.

... type SΣ1..1CodeableConceptKind of document (LOINC if possible)
Binding: US Core DocumentReference Type (required): All LOINC values whose SCALE is DOC in the LOINC database and the HL7 v3 Code System NullFlavor concept 'unknown'

Additional BindingsPurpose
US Core Clinical Note TypeMin Binding
... Slices for category SΣ1..*CodeableConceptCategorization of document
Slice: Unordered, Open by pattern:$this
Binding: DocumentClassValueSet (example): High-level kind of a clinical document at a macro level.


.... category:us-core SΣ0..*CodeableConceptCategorization of document
Binding: US Core DocumentReference Category (required): The US Core DocumentReferences Type Value Set is a 'starter set' of categories supported for fetching and storing clinical notes.


... subject SΣ1..1Reference(US Core Patient Profile)Who/what is the subject of the document
... date SΣ0..1instantWhen this document reference was created
... author SΣ0..*Reference(US Core Practitioner Profile S | US Core Organization Profile | US Core Patient Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile | Device)Who and/or what authored the document
... authenticator 0..1Reference(Practitioner | PractitionerRole | Organization)Who/what authenticated the document
... custodian 0..1Reference(Organization)Organization which maintains the document
... relatesTo Σ0..*BackboneElementRelationships to other documents
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... code Σ1..1codereplaces | transforms | signs | appends
Binding: DocumentRelationshipType (required): The type of relationship between documents.

.... target Σ1..1Reference(DocumentReference)Target of the relationship
... description Σ0..1stringHuman-readable description
... securityLabel Σ0..*CodeableConceptDocument security-tags
Binding: All Security Labels (extensible): Security Labels from the Healthcare Privacy and Security Classification System.


... content SΣ1..*BackboneElementDocument referenced
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... attachment SΣI1..1AttachmentWhere to access the document
us-core-6: DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.
..... id 0..1stringUnique id for inter-element referencing
..... extension 0..*ExtensionAdditional content defined by implementations
Slice: Unordered, Open by value:url
..... contentType SΣ0..1codeMime type of the content, with charset etc.
Binding: Mime Types (required): The mime type of an attachment. Any valid mime type is allowed.


Example General: text/plain; charset=UTF-8, image/png
..... language Σ0..1codeHuman language of the content (BCP-47)
Binding: CommonLanguages (preferred): A human language.

Additional BindingsPurpose
AllLanguagesMax Binding

Example General: en-AU
..... data SI0..1base64BinaryData inline, base64ed
..... url SΣI0..1urlUri where the data can be found
Example General: http://www.acme.com/logo-small.png
..... size Σ0..1unsignedIntNumber of bytes of content (if url provided)
..... hash Σ0..1base64BinaryHash of the data (sha-1, base64ed)
..... title Σ0..1stringLabel to display in place of the data
Example General: Official Corporate Logo
..... creation Σ0..1dateTimeDate attachment was first created
.... format SΣ0..1CodingFormat/content rules for the document
Binding: DocumentReferenceFormatCodeSet (extensible)
... context SΣ0..1BackboneElementClinical context of document
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... encounter S0..1Reference(US Core Encounter Profile)Context of the document content
.... event 0..*CodeableConceptMain clinical acts documented
Binding: v3 Code System ActCode (example): This list of codes represents the main clinical acts being documented.


.... period SΣ0..1PeriodTime of service that is being documented
.... facilityType 0..1CodeableConceptKind of facility where patient was seen
Binding: FacilityTypeCodeValueSet (example): XDS Facility Type.

.... practiceSetting 0..1CodeableConceptAdditional details about where the content was created (e.g. clinical specialty)
Binding: PracticeSettingCodeValueSet (example): Additional details about where the content was created (e.g. clinical specialty).

.... sourcePatientInfo 0..1Reference(Patient)Patient demographics from source
.... related 0..*Reference(Resource)Related identifiers or resources

doco Documentation for this format
NameFlagsCard.TypeDescription & Constraintsdoco
.. DocumentReference 0..*DocumentReferenceA reference to a document
... identifier Σ0..*IdentifierOther identifiers for the document
... status ?!Σ1..1codecurrent | superseded | entered-in-error
Binding: DocumentReferenceStatus (required)
... type Σ1..1CodeableConceptKind of document (LOINC if possible)
Binding: US Core DocumentReference Type (required): All LOINC values whose SCALE is DOC in the LOINC database and the HL7 v3 Code System NullFlavor concept 'unknown'

Additional BindingsPurpose
US Core Clinical Note TypeMin Binding
... Slices for category Σ1..*CodeableConceptCategorization of document
Slice: Unordered, Open by pattern:$this
Binding: DocumentClassValueSet (example): High-level kind of a clinical document at a macro level.


.... category:us-core Σ0..*CodeableConceptCategorization of document
Binding: US Core DocumentReference Category (required): The US Core DocumentReferences Type Value Set is a 'starter set' of categories supported for fetching and storing clinical notes.


... subject Σ1..1Reference(US Core Patient Profile)Who/what is the subject of the document
... date Σ0..1instantWhen this document reference was created
... author Σ0..*Reference(US Core Practitioner Profile)Who and/or what authored the document
... content Σ1..*BackboneElementDocument referenced
.... attachment ΣI1..1AttachmentWhere to access the document
us-core-6: DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.
..... contentType Σ0..1codeMime type of the content, with charset etc.
Binding: Mime Types (required): The mime type of an attachment. Any valid mime type is allowed.

..... data I0..1base64BinaryData inline, base64ed
..... url ΣI0..1urlUri where the data can be found
.... format Σ0..1CodingFormat/content rules for the document
Binding: DocumentReferenceFormatCodeSet (extensible)
... context Σ0..1BackboneElementClinical context of document
.... encounter 0..1Reference(US Core Encounter Profile)Context of the document content
.... period Σ0..1PeriodTime of service that is being documented

doco Documentation for this format

Differential View

This structure is derived from DocumentReference

NameFlagsCard.TypeDescription & Constraintsdoco
.. DocumentReference 0..*DocumentReferenceA reference to a document
... identifier S0..*IdentifierOther identifiers for the document
... status S1..1codecurrent | superseded | entered-in-error
Binding: DocumentReferenceStatus (required)
... type S1..1CodeableConceptKind of document (LOINC if possible)
Binding: US Core DocumentReference Type (required): All LOINC values whose SCALE is DOC in the LOINC database and the HL7 v3 Code System NullFlavor concept 'unknown'

... Slices for category S1..*CodeableConceptCategorization of document
Slice: Unordered, Open by pattern:$this
.... category:us-core S0..*CodeableConceptCategorization of document
Binding: US Core DocumentReference Category (required): The US Core DocumentReferences Type Value Set is a 'starter set' of categories supported for fetching and storing clinical notes.

... subject S1..1Reference(US Core Patient Profile)Who/what is the subject of the document
... date S0..1instantWhen this document reference was created
... author S0..*Reference(US Core Practitioner Profile S | US Core Organization Profile | US Core Patient Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile | Device)Who and/or what authored the document
... content S1..*BackboneElementDocument referenced
.... attachment SI1..1AttachmentWhere to access the document
us-core-6: DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.
..... contentType S0..1codeMime type of the content, with charset etc.
..... data SI0..1base64BinaryData inline, base64ed
..... url SI0..1urlUri where the data can be found
.... format S0..1CodingFormat/content rules for the document
Binding: DocumentReferenceFormatCodeSet (extensible)
... context S0..1BackboneElementClinical context of document
.... encounter S0..1Reference(US Core Encounter Profile)Context of the document content
.... period S0..1PeriodTime of service that is being documented

doco Documentation for this format

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. DocumentReference 0..*DocumentReferenceA reference to a document
... id Σ0..1stringLogical id of this artifact
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred): A human language.

Additional BindingsPurpose
AllLanguagesMax Binding
... text 0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... masterIdentifier Σ0..1IdentifierMaster Version Specific Identifier
... identifier SΣ0..*IdentifierOther identifiers for the document
... status ?!SΣ1..1codecurrent | superseded | entered-in-error
Binding: DocumentReferenceStatus (required)
... docStatus Σ0..1codepreliminary | final | amended | entered-in-error
Binding: CompositionStatus (required): Status of the underlying document.

... type SΣ1..1CodeableConceptKind of document (LOINC if possible)
Binding: US Core DocumentReference Type (required): All LOINC values whose SCALE is DOC in the LOINC database and the HL7 v3 Code System NullFlavor concept 'unknown'

Additional BindingsPurpose
US Core Clinical Note TypeMin Binding
... Slices for category SΣ1..*CodeableConceptCategorization of document
Slice: Unordered, Open by pattern:$this
Binding: DocumentClassValueSet (example): High-level kind of a clinical document at a macro level.


.... category:us-core SΣ0..*CodeableConceptCategorization of document
Binding: US Core DocumentReference Category (required): The US Core DocumentReferences Type Value Set is a 'starter set' of categories supported for fetching and storing clinical notes.


... subject SΣ1..1Reference(US Core Patient Profile)Who/what is the subject of the document
... date SΣ0..1instantWhen this document reference was created
... author SΣ0..*Reference(US Core Practitioner Profile S | US Core Organization Profile | US Core Patient Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile | Device)Who and/or what authored the document
... authenticator 0..1Reference(Practitioner | PractitionerRole | Organization)Who/what authenticated the document
... custodian 0..1Reference(Organization)Organization which maintains the document
... relatesTo Σ0..*BackboneElementRelationships to other documents
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... code Σ1..1codereplaces | transforms | signs | appends
Binding: DocumentRelationshipType (required): The type of relationship between documents.

.... target Σ1..1Reference(DocumentReference)Target of the relationship
... description Σ0..1stringHuman-readable description
... securityLabel Σ0..*CodeableConceptDocument security-tags
Binding: All Security Labels (extensible): Security Labels from the Healthcare Privacy and Security Classification System.


... content SΣ1..*BackboneElementDocument referenced
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... attachment SΣI1..1AttachmentWhere to access the document
us-core-6: DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.
..... id 0..1stringUnique id for inter-element referencing
..... extension 0..*ExtensionAdditional content defined by implementations
Slice: Unordered, Open by value:url
..... contentType SΣ0..1codeMime type of the content, with charset etc.
Binding: Mime Types (required): The mime type of an attachment. Any valid mime type is allowed.


Example General: text/plain; charset=UTF-8, image/png
..... language Σ0..1codeHuman language of the content (BCP-47)
Binding: CommonLanguages (preferred): A human language.

Additional BindingsPurpose
AllLanguagesMax Binding

Example General: en-AU
..... data SI0..1base64BinaryData inline, base64ed
..... url SΣI0..1urlUri where the data can be found
Example General: http://www.acme.com/logo-small.png
..... size Σ0..1unsignedIntNumber of bytes of content (if url provided)
..... hash Σ0..1base64BinaryHash of the data (sha-1, base64ed)
..... title Σ0..1stringLabel to display in place of the data
Example General: Official Corporate Logo
..... creation Σ0..1dateTimeDate attachment was first created
.... format SΣ0..1CodingFormat/content rules for the document
Binding: DocumentReferenceFormatCodeSet (extensible)
... context SΣ0..1BackboneElementClinical context of document
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... encounter S0..1Reference(US Core Encounter Profile)Context of the document content
.... event 0..*CodeableConceptMain clinical acts documented
Binding: v3 Code System ActCode (example): This list of codes represents the main clinical acts being documented.


.... period SΣ0..1PeriodTime of service that is being documented
.... facilityType 0..1CodeableConceptKind of facility where patient was seen
Binding: FacilityTypeCodeValueSet (example): XDS Facility Type.

.... practiceSetting 0..1CodeableConceptAdditional details about where the content was created (e.g. clinical specialty)
Binding: PracticeSettingCodeValueSet (example): Additional details about where the content was created (e.g. clinical specialty).

.... sourcePatientInfo 0..1Reference(Patient)Patient demographics from source
.... related 0..*Reference(Resource)Related identifiers or resources

doco Documentation for this format

 

Other representations of profile: CSV, Excel, Schematron

Terminology Bindings

PathConformanceValueSet
DocumentReference.languagepreferredCommonLanguages
Max Binding: AllLanguages
DocumentReference.statusrequiredDocumentReferenceStatus
DocumentReference.docStatusrequiredCompositionStatus
DocumentReference.typerequiredUSCoreDocumentReferenceType
Min Binding: US Core Clinical Note Type
DocumentReference.categoryexampleDocumentClassValueSet
DocumentReference.category:us-corerequiredUSCoreDocumentReferenceCategory
DocumentReference.relatesTo.coderequiredDocumentRelationshipType
DocumentReference.securityLabelextensibleAll Security Labels
DocumentReference.content.attachment.contentTyperequiredMime Types
DocumentReference.content.attachment.languagepreferredCommonLanguages
Max Binding: AllLanguages
DocumentReference.content.formatextensibleDocumentReferenceFormatCodeSet
DocumentReference.context.eventexampleActCode
DocumentReference.context.facilityTypeexampleFacilityTypeCodeValueSet
DocumentReference.context.practiceSettingexamplePracticeSettingCodeValueSet

Constraints

IdGradePathDetailsRequirements
us-core-6errorDocumentReference.content.attachmentDocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.
: url.exists() or data.exists()

Notes:

Quick Start

Below is an overview of the required Server RESTful FHIR interactions for this profile - for example, search and read operations - when supporting the US Core interactions to access this profile’s information (Profile Support + Interaction Support). Note that systems that support only US Core Profiles (Profile Only Support) are not required to support these interactions. See the US Core Server CapabilityStatement for a complete list of supported RESTful interactions for this IG.

  • The syntax used to describe the interactions is described here.
  • See the General Requirements section for additional rules and expectations when a server requires status parameters.
  • See the General Guidance section for additional guidance on searching for multiple patients.

Mandatory Search Parameters:

The following search parameters and search parameter combinations SHALL be supported:

  1. SHALL support fetching a DocumentReference using the _id search parameter:

    GET [base]/DocumentReference[id]

    Example:

    1. GET [base]/DocumentReference/2169591
    2. GET [base]/DocumentReference?_id=2169591

    Implementation Notes: Fetches a single DocumentReference. The document itself is represented as a base64 encoded binary data element or retrieved using the link provided by the resource. If the document is a relative link to a [Binary] resource like a resource reference, it can be subsequently retrieved using: GET [base]/Binary/[id]. (how to search by the logical id of the resource)

  2. SHALL support searching for all documentreferences for a patient using the patient search parameter:

    GET [base]/DocumentReference?patient={Type/}[id]

    Example:

    1. GET [base]/DocumentReference?patient=1137192

    Implementation Notes: Fetches a bundle of all DocumentReference resources for the specified patient. See the implementation notes above for how to access the actual document. (how to search by reference)

  3. SHALL support searching using the combination of the patient and category search parameters:

    GET [base]/DocumentReference?patient={Type/}[id]&category=http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category|clinical-note

    Example:

    1. GET [base]/DocumentReference?patient=1235541&category=http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category|clinical-note

    Implementation Notes: Fetches a bundle of all DocumentReference resources for the specified patient and category = clinical-note. See the implementation notes above for how to access the actual document. (how to search by reference and how to search by token)

  4. SHALL support searching using the combination of the patient and category and date search parameters:
    • including support for these date comparators: gt,lt,ge,le
    • including optional support for AND search on date (e.g.date=[date]&date=[date]]&...)

    GET [base]/DocumentReference?patient={Type/}[id]&category=http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category|clinical-note&date={gt|lt|ge|le}[date]{&date={gt|lt|ge|le}[date]&...}

    Example:

    1. GET [base]/DocumentReference?patient=1235541&category=http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category|clinical-note&date=ge2020-01-01T00:00:00Z

    Implementation Notes: Fetches a bundle of all DocumentReference resources for the specified patient and category = clinical=note and date. See the implementation notes above for how to access the actual document. (how to search by reference and how to search by token and how to search by date)

  5. SHALL support searching using the combination of the patient and type search parameters:

    GET [base]/DocumentReference?patient={Type/}[id]&type={system|}[code]

    Example:

    1. GET [base]/DocumentReference?patient=1316024&type=http://loinc.org|18842-5

    Implementation Notes: Fetches a bundle of all DocumentReference resources for the specified patient and type. See the implementation notes above for how to access the actual document. (how to search by reference and how to search by token)

Optional Search Parameters:

The following search parameter combinations SHOULD be supported:

  1. SHOULD support searching using the combination of the patient and status search parameters:
    • including support for OR search on status (e.g.status={system|}[code],{system|}[code],...)

    GET [base]/DocumentReference?patient={Type/}[id]&status={system|}[code]{,{system|}[code],...}

    Example:

    1. GET [base]/DocumentReference?patient=1235541

    Implementation Notes: Fetches a bundle of all DocumentReference resources for the specified patient and status. See the implementation notes above for how to access the actual document. (how to search by reference and how to search by token)

  2. SHOULD support searching using the combination of the patient and type and period search parameters:
    • including support for these period comparators: gt,lt,ge,le
    • including optional support for AND search on period (e.g.period=[date]&period=[date]]&...)

    GET [base]/DocumentReference?patient={Type/}[id]&type={system|}[code]&period={gt|lt|ge|le}[date]{&period={gt|lt|ge|le}[date]&...}

    Example:

    1. GET [base]/DocumentReference?patient=2169591&type=http://loinc.org |34133-9&period=ge2020-01-01T00:00:00Z

    Implementation Notes: Fetches a bundle of all DocumentReference resources for the specified patient and type and period. See the implementation notes above for how to access the actual document. (how to search by reference and how to search by token and how to search by date)

Mandatory Write Capability:

  1. SHALL support writing a new note to a Patient’s Chart:

    POST [base]/DocumentReference

An example to demonstrate writing a note to the server.

Clinical Note


POST [base]/DocumentReference
Request Headers:
 content-type: "application/json"
 prefer: "return=REPRESENTATION"
 accept: "application/fhir+json"
Request Body:
 {
   "resourceType": "DocumentReference",
   "type": {
       "coding": [
           {
               "system": "http://loinc.org",
               "code": "18842-5",
               "display": "Discharge Summary"
           }
       ],
       "text": "Discharge Summary"
   },
   "subject": {
       "reference": "[base]/Patient/eso2MXsmcJloTEUEls5DzbA3"
   },
   "content": [{"attachment": {
       "contentType": "text/plain",
       "data": "Tm8gYWN0aXZpdHkgcmVzdHJpY3Rpb24sIHJlZ3VsYXIgZGlldCwgZm9sbG93IHVwIGluIHR3byB0byB0aHJlZSB3ZWVrcyB3aXRoIHByaW1hcnkgY2FyZSBwcm92aWRlci4="
   } }],
   "context": {"encounter": {"reference": "[base]/Encounter/eIOY6XJQw0hvmvCqTtkg6vQ3"} }
 }

Note Content

The content is Base64 encoded and states: “No activity restriction, regular diet, follow up in two to three weeks with primary care provider.”


Mandatory Operation:

  1. SHALL support fetching documents using the $docref operation.

    This $docref operation is used to request a server generate a document based on the specified parameters. If no parameters are specified, the server SHALL return a DocumentReference to the patient’s most current CCD. See the $docref operation definition for details on how this operation differs from a FHIR RESTful search. This operation returns a DocumentReference resources. The document itself is retrieved using the link provided in the DocumentReference.content.attachment.url element.

    GET [base]/DocumentReference/$docref?patient=[id]

The operation can be invoked using the GET Syntax if the complex type parameter is omitted:

GET [base]/DocumentReference/$docref?{parameters}

Otherwise the POST transaction is used as follows:

POST [base]/DocumentReference/$docref}

Example

Request the latest CCD for a patient using GET syntax

GET [base]/DocumentReference/$docref?patient=123

Request the latest CCD for a patient using POST syntax

POST [base]/DocumentReference/$docref}

POST request body:

    {
      "resourceType": "Parameters",
      "id": "get-ccd123",
      "parameter": [
        {
          "name": "patient",
          "valueId" : "123"
        }
      ]
    }

Response

HTTP/1.1 200 OK
[other headers]

Response body

    {
      "resourceType": "Bundle",
      "id": "get-ccd123-response",
      "type": "searchset",
      "total": 1,
      "entry": [{
        "fullUrl": "http://server/path/DocumentReference/get-ccd123",
        "resource":{
        "resourceType" : "DocumentReference",
        "id" : "get-ccd123",
        "meta" : {
          "profile" : [
            "http://fhir.org/guides/argonaut/StructureDefinition/argo-documentreference"
          ]
        },
        "identifier" : [
          {
            "system" : "urn:ietf:rfc:3986",
            "value" : "urn:oid:2.16.840.1.113883.19.5.99999.1"
          }
        ],
        "status" : "current",
        "type" : {
          "coding" : [
            {
              "system" : "http://loinc.org",
              "code" : "34133-9",
              "display" : "Summary of episode note"
            }
          ],
          "text" : "CCD Document"
        },
        "subject" : {
          "reference" : "Patient/example",
          "display" : "Amy Shaw"
        },
        "created" : "2006-09-01",
        "indexed" : "2016-03-09T15:29:46Z",
        "author" : [
          {
            "reference" : "Practitioner/practitioner-1",
            "display" : "Ronald Bone, MD"
          }
        ],
        "description" : "Pulmonology clinic acute visit",
        "content" : [
          {
            "attachment" : {
              "contentType" : "text/plain",
              "url" : "/Binary/1-note",
              "title" : "Uri where the data can be found: [base]/Binary/1-note"
            },
            "format" : {
              "system" : "urn:oid:1.3.6.1.4.1.19376.1.2.3",
              "code" : "urn:hl7-org:sdwg:ccda-structuredBody:2.1",
              "display" : "Documents following C-CDA constraints using a structured body"
            }
          }
        ],
        "context" : {
          "period" : {
            "start" : "2004-12-23T08:00:00+11:00",
            "end" : "2004-12-23T08:01:00+11:00"
          }
        }
      }
      }
      ]
    }