FHIR

Name

Required?

Type

Description

pid

yes

URL

Patient’s logical ID. This is retrieved using the search function.

Name

Required

Type

Description

name

No

string

A portion of either the family or given name of the patient.

_id

No

string

The logical ID of the patient.

family

Yes

string

A portion of the family (last) name of the patient.

given

Yes

string

A portion of the given (first) name of the patient.

gender

Yes

string

Patient’s gender. M-Male, F-female, O-Other, U-Unknown

birthdate

Yes

date

Patient’s date of birth.

identifier

Yes

token

Patient’s identifier. For example, MRN.

Name

Type

Cardinality

Description

identifier

Identifier

0..*

Patient’s identifier. Patients are usually assigned a specific numerical identifier that is unique within the system.

active

boolean

0..1

Is the patient’s record active? The default value is true. Need to be able to mark a patient record as not to be used because it was created in error. If a record is inactive, and linked to an active record, then future patient/record updates should occur on the other patient.

name

HumanName

0..*

Name associated with the patient.

telecom

ContactPoint

0..*

Patient contact communication detail. This indicates the value in any kind of telecom details field for the patient. If capturing a phone, fax, or similar contact point, the value is a properly formatted telephone number according to ITU-T E.123. However, this is frequently not possible due to legacy data and/or clerical practices when recording contact details. For this reason, phone, fax, page, and email addresses are not handled as formal URLs.

gender

code

0..1

Patient’s gender. Returns Male, Female, Other, or Unknown. For more information on this value set, see Administrative Gender ValueSet.

birthDate

date

0..1

Patient’s date of birth. This indicates a specific calendar date or partial date (either a year or a month and year combination). Time zone is not included. Fuzzy (approximate) dates are not valid.

deceasedBoolean

boolean

0..1

Is the patient deceased? If a patient is deceased, it influences the clinical process and human communication. If this value is blank, most systems interpret the missing information as an indication that the patient is alive.

address

Address

0..*

Patient’s postal address. Postal addresses are often used to record a location that can be visited to find a patient or person.

maritalStatus

CodeableConcept

0..1

Patient marital (civil) status. For more information on this value set, see Marital Status Codes.

multipleBirthBoolean

boolean

0..1

Was the patient part of a multiple birth?

contact

0..*

Patient’s contact party. For example, Guardian, Partner, or Friend).

contact.relationship

CodeableConcept

0..*

Patient contact’s relationship with the patient. For more information on this value set, see patient-contact-relationship.

contact.name

HumanName

0..1

Patient contact’s name.

contact.telecom

ContactPoint

0..*

Patient contact’s detailed information.

contact.address

Address

0..1

Patient contact’s address.

communication.language

CodeableConcept

0..*

The language used to communicate with the patient about his or her health. For more information on this value set, see Language ValueSet.

careProvider

Reference(Practitioner)

0..*

Patient’s nominated primary care provider.

us-core-race

CodeableConcept

0..1 Patient’s race (category of humans sharing history, origin, or nationality). For more information on this value set, see DAF Race ValueSet

us-core-ethnicitye

CodeableConcept

0..1

Patient’s ethnicity (category of humans sharing heritage). For more information on this value set, see Ethnicity group.

us-core-religion

CodeableConcept

0..1

Patient’s professed religious affiliation. For more information on this value set, see v3 Code System ReligiousAffiliation.

Name

Required?

Type

Description

pid

yes

URL

Patient’s logical ID. This is retrieved using the search function.

Name

Type

Cardinality

Description

identifier

0..*

Observation’s unique ID. This applies to the instance observation.

status

code

1..1

Observation’s status. Values include Registered, Preliminary, Final, or Amended. For more information on this value set, see observation-status.

category

CodeableConcept

0..1

Observation’s type of classification. For more information on this value set, see observation-category.

code

CodeableConcept

1..1

Observation’s type or code. For more information on this value set, see observation-codes.

subject

Reference(Patient, Group, Device, Location)

0..1

Observation’s subject. The patient’s (or group of patients) location, or the device whose characteristics (direct or indirect) are described by the observation and into whose record the observation is placed.

encounter

Reference(Encounter)

0..1

Observation’s encounter. The healthcare event (a patient and healthcare provider interaction) during which the observation is made. For some observations it may be important to know the link between an observation and a particular encounter.

effectiveDateTime

dateTime

0..1

Clinically relevant time/time-period for observation.

effectivePeriod

Period

0..1

Clinically relevant time/time-period for the observation. The time or time-period the observed value is asserted as being true. For biological subjects (human patients) this is usually called the “physiologically relevant time.” This is usually either the time of the procedure or of specimen collection, but very often the source of the date/time is not known, only the date/time itself.

issued

Hl7.Fhir.Model.Instant

0..1

Date/time the observation was made available. The date and time is typically after the results have been reviewed and verified.

performer

Reference(Practitioner, Organization, Patient, RelatedPerson)

0..*

Individual responsible for the observation.

valueCodeableConcept

CodeableConcept

0..1

The smoking status. Need to track the status of individual results. Some results are finalized before the whole report is finalized. For more information on this value set, see DAF Smoking Status Value Set.

comments

string

0..1

Comments about the result.

Name

Required?

Type

Description

pid

yes

URL

The patient’s logical ID. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

Identifier

0..*

External ID for the condition. The ID is defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. For example, in CDA documents or in written or printed documentation. This may include IMO, ICD9/10, or Medcin codes.

patient

Reference(Patient)

1..1

Patient name. This indicates the patient who the condition record is associated with. This is used for querying and retrieving patient demographic information.

encounter

Reference(Encounter)

0..1

Encounter during which the condition was first asserted.

asserter

Reference(Practitioner, Patient)

0..1

Individual who asserts the condition. This is a provider reference.

dateRecorded

date)

0..1

Date when the condition was first recorded. This is not the date on which the condition was last updated.

code

CodeableConcept

1..1

ID of the condition, problem, or diagnosis. The value set includes content from SNOMED. For more information on this value set, see condition-code.

category

CodeableConcept

0..1

Condition category. Valid entries include: Complaint, Symptom, Finding, and Diagnosis. For more information on this value set, see condition-category.

clinicalStatus

code

0..1

Condition clinical status. Valid entries include: Active, Relapse, Remission, and Resolved. For more information on this value set, see condition-clinical.

verificationStatus

code

1..1

Condition verification status. Valid entries include: Provisional, Differential, Confirmed, Refuted, Entered-in-error, and Unknown. For more information on this value set, see condition-ver-status.

severity

CodeableConcept

0..1

Subjective severity of condition. Valid entries include the following SNOMED codes: 399166001 Fatal, 24484000 Severe, 6736007 Moderate, and 255604002 Mild. For more information on this value set, see condition-severity.

onsetDateTime

dateTime

0..1

Estimated or actual date, date-time, or age when the condition statement was documented. The Date Recorded indicates the date when this particular condition record was created in the EHR, not the date of the most recent update. Onset date is pulled from Problem.OnsetFuzzyWhen.

onsetQuantity

Quantity

0..1

Estimated or actual date, date-time, or age.

onsetPeriod

Period

0..1

Estimated or actual date, date-time, or age.

onsetRange

Hl7.Fhir.Model.Range

0..1

Estimated or actual date, date-time, or age.

onsetString

String

0..1

Estimated or actual date, date-time, or age.

abatementDateTime

dateTime

0..1

If/when in resolution/remission.

abatementQuantity

Quantity

0..1

If/when in resolution/remission.

abatementBoolean

Boolean

0..1

If/when in resolution/remission.

abatementPeriod

Period

0..1

If/when in resolution/remission.

abatementRange

Hl7.Fhir.Model.Range

0..1

If/when in resolution/remission.

abatementString

String

0..1

If/when in resolution/remission.

stage

0..1

Stage/grade, usually assessed formally.

stage.summary

CodeableConcept

0..1

Simple summary (disease specific). For more information on this value set, see condition-stage.

stage.assessment

Reference(ClinicalImpression, DiagnosticReport, Observation)

0..*

Formal record of assessment.

evidence

0..*

Supporting evidence.

evidence.code

CodeableConcept

0..1

Manifestation/symptom. For more information on this value set, see manifestation-or-symptom.

evidence.detail

Reference(Resource)

0..*

Supporting information found elsewhere.

bodySite

CodeableConcept

0..*

Anatomical location, if relevant. For more information on this value set, see body-site.

notes

string

0..1

Additional information about the condition.

Name

Required?

Type

Description

pid

yes

URL

Patient’s logical ID. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

External identifier. FHIR will generate its own internal identifiers (probably URLs) which do not need to be explicitly managed by the resource. The identifier is one that would be used by another non-FHIR system. For example, an automated medication pump would provide a record each time it operated; an administration while the patient was off the ward might be made with a different system and entered after the event. This is particularly important if these records have to be updated.

patient

Reference(Patient)

1..1

Patient who is or was taking the medication. Defines constraints and extensions on the patient resource for use in querying and retrieving patient demographic information.

informationSource

Reference(Patient, Practitioner, RelatedPerson)

0..1

The person who provided the information about the taking of this medication.

dateAsserted

dateTime

0..1

Date and time when the statement was asserted.

status

code

1..1

Valid entries include: Active, Completed, Entered-in-error, and Intended. For more information on this value set, see medication-statement-status.

wasNotTaken

boolean

0..1

Was the medication not taken? True if medication is/was not being taken.

reasonNotTaken

CodeableConcept

0..*

Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included. A code indicating why the medication was not taken. A set of codes indicating the reason why the MedicationAdministration is negated. For example codes, see Reason Medication Not Given Codes. This value set has an inline code system http://hl7.org/fhir/reason-medication-not-given, which defines the following codes: Code “a” – Display “None” – No reason known, Code “b” – Display “Away” – The patient was not available when the dose was scheduled, Code “c” – Display “Asleep” – The patient was asleep when the dose was scheduled, and Code “d” – Display “Vomit” – The patient was given the medication and immediately vomited it back.

reasonForUseCodeableConcept

CodeableConcept

0..1

reasonForUseReference

Reference(Condition)

0..1

effectiveDateTime

dateTime

0..1

Date and time over which the medication was consumed.

effectivePeriod

Period

0..1

The interval of time during which it is being asserted that the patient was taking the medication (or was not taking, when the wasNotGiven element is true). If the medication is still being taken at the time the statement is recorded, the “end” date will be omitted.

note

string

0..1

Further information about the statement.

supportingInformation

Reference(Resource)

0..*

Additional supporting information.

medicationCodeableConcept

CodeableConcept

1..1

The medication that was taken. Defines constraints and extensions on the Medication resource for use in querying and retrieving patient’s medication information.

medicationReference

Reference(Medication)

1..1

The medication that was taken.

dosage

0..*

Indicates how the medication is/was used by the patient.

dosage.text

string

0..1

Reported dosage information.

dosage.timing

Hl7.Fhir.Model.Timing

0..1

When/how often was medication taken. The timing schedule for giving the medication to the patient. The Schedule data type allows many different expressions. For example, “Every 8 hours,” “Three times a day,” “1/2 an hour before breakfast for 10 days from 23-Dec 2011,” or “15 Oct 2013, 17 Oct 2013 and 1 Nov 2013”.

dosage.asNeededBoolean

Boolean

0..1

Take “as needed” (for x).

dosage.asNeededCodeableConcept

CodeableConcept

0..1

Take “as needed” (for x).

dosage.siteCodeableConcept

CodeableConcept

0..1

Where (on body) medication is/was administered. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant. A coded specification of the anatomic site where the medication first enters the body. This identifies the body site at which the substance was administered. The codes SHOULD be taken from Vaccine Administered Body Site. All codes from system http://snomed.info/sct. The value set includes codes from the following code systems (actual value set has > 1000 codes included): 91723000 – Anatomical structure (body structure), 280115004 – Acquired body structure (body structure), 258331007 – Anatomical site notations for tumor staging (body structure), 118956008 – Altered from its original anatomical structure (morphologic abnormality), or 91722005 – Entire physical anatomical entity (body structure).

dosage.siteReference

Reference(BodySite)

0..1

Where (on body) medication is/was administered.

dosage.route

CodeableConcept

0..1

Route by which the medication entered the body. Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant. Route of Administration value set is based upon FDA Drug Registration and Listing Database (FDA Orange Book) which are used in FDA structured product and labelling (SPL). This value set includes codes as defined in http://ncimeta.nci.nih.gov.

dosage.method

CodeableConcept

0..1

Technique used to administer the medication.

dosage.quantityQuantity

Quantity

0..1

Amount administered in one dose.

dosage.quantityRange

Hl7.Fhir.Model.Range

0..1

Amount administered in one dose.

dosage.rateRatio

Hl7.Fhir.Model.Ratio

0..1

Identifies the speed with which the medication was or will be introduced into the patient. Typically the rate for an infusion e.g. 100 ml per 1 hour or 100 ml/hr. May also be expressed as a rate per unit of time e.g. 500 ml per 2 hours. Currently we do not specify a default of “�1” in the denominator, but this is being discussed. Other examples: 200 mcg/min or 200 mcg/1 minute; 1 liter/8 hours.

dosage.rateRange

Hl7.Fhir.Model.Range

0..1

Dose quantity per unit of time.

dosage.maxDosePerPeriod

Hl7.Fhir.Model.Ratio

0..1

The maximum total quantity of a therapeutic substance that may be administered to a subject over the period of time. For example, 1000mg in 24 hours.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

Identifier associated with the allergy/intolerance concern that are defined by the business processes and/or used to refer to it when a direct URL reference to the resource is not appropriate. For example, in CDA documents or in written/printed documentation.

onset

dateTime

0..1

Date and/or time of the onset of the allergy or intolerance.

recordedDate

dateTime

0..1

Date when the sensitivity was recorded.

recorder

Reference(Practitioner, Patient)

0..1

Individual who recorded the allergy and takes responsibility for its content. Options include either DAF-Practitioner profile or DAF-Patient profile.

patient

Reference(Patient)

1..1

Defines constraints and extensions on the patient resource for use in querying and retrieving patient demographic information.

reporter

Reference(Patient, RelatedPerson, Practitioner)

0..1

Source of the information about the allergy that is recorded.

substance

CodeableConcept

1..1

Identification of a substance or class of substances that is considered to be responsible for the adverse reaction risk. AllergyIntolerance.substance has an extensible binding to a value set consisting of: NDF-RT (codes for drug class allergies), RXNORM (codes limited to term types- TTY- such as BN or Brand Name, IN or Ingredient, MIN or multiple ingredient, and PIN or precise ingredient for drug ingredient allergies) or SNOMED CT (used when no other code from the other code systems is appropriate, such as No Known Allergies, No Known Food Allergies, No Known Drug Allergies, or No Known Environmental Allergies). For more information on this value set, see: http://hl7.org/fhir/ValueSet/allergyintolerance-substance-code.

status

code

0..1

Assertion about certainty associated with the propensity or potential risk of a reaction to the identified substance. The codes shall be taken from the AllergyIntoleranceStatus value set which includes: Active, Unconfirmed, Confirmed, Inactive, Resolved, Refuted, and Entered in Error. Decision support would typically raise alerts for Unconfirmed, Confirmed, and Resolved and ignore a Refuted reaction. In particular, Refuted may be useful for reconciliation of the Adverse Reaction List. Conformance is required and as such, some implementations may choose to make this field mandatory. For more information on this value set, see: http://hl7.org/fhir/ValueSet/allergy-intolerance-status.

criticality

code

0..1

Estimate of the potential clinical harm or seriousness of the reaction to the identified substance. The codes shall be taken from the AllergyIntoleranceCriticality value set with required conformance and include: CRITL-Low, CRITH-High, and CRITU-Unable to determine. For more information on this value set, see: http://hl7.org/fhir/ValueSet/allergy-intolerance-criticality.

type

code

0..1

Identification of the underlying physiological mechanism for a reaction risk. This value set includes two types: Allergy or Intolerance. For more information on this value set, see: http://hl7.org/fhir/ValueSet/allergy-intolerance-type.

category

code

0..1

Category of the allergy. Options include: Food, Medication, Environment, and Other. For more information on this value set, see: http://hl7.org/fhir/ValueSet/allergy-intolerance-category.

lastOccurence

dateTime

0..1

Date and time of the last known occurrence of the reaction.

note

Annotation

0..1

Additional text not captured in other fields.

reaction

Backbone element – http://www.hl7.org/fhir/daf/daf-allergyintolerance-definitions.html#daf-allergyintolerance.AllergyIntolerance.reaction

0..*

Details about each adverse reaction event linked to exposure to the identified substance.

reaction.substance

CodeableConcept

0..1

Identification of the specific substance considered to be responsible for the adverse reaction event. Note: The substance for a specific reaction may be different from the substance identified as the cause of the risk, but must be consistent with it. For instance, it may be a more specific substance such as a brand medication or a composite substance that includes the identified substance. It must be clinically safe to only process the AllergyIntolerance.substance and ignore the AllergyIntolerance.event.substance. For more information on this value set, see: http://hl7.org/fhir/ValueSet/substance-code.

reaction.manifestation

CodeableConcept

1..*

Clinical symptoms and signs associated with the event. For more information on this value set, see: http://hl7.org/fhir/ValueSet/manifestation-codes.

reaction.description

string

0..1

Description of the event as a whole.

reaction.onset

dateTime

0..1

Date and time when manifestations showed.

reaction.severity

code

0..1

Severity of the reaction or of the event as a whole. Options include: Mild, Moderate, or Severe. For more information on this value set, see: http://hl7.org/fhir/ValueSet/reaction-event-severity.

reaction.exposureRoute

CodeableConcept

0..1

How the subject was exposed to the substance. For more information on this value set, see: http://hl7.org/fhir/ValueSet/route-codes.

reaction.note

Annotation

0..1

Text about the event not captured in other fields.

Name

Required?

Type

Description

pid

yes

url

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

External IDs for this plan. This is a business identifier, not a resource identifier. This records identifiers associated with this care plan that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. For example, in CDA documents or in written/printed documentation.

subject

Reference(Patient, Group)

0..1

Who the care plan is for. This identifies the patient or group whose intended care is described by the plan.

status

code

1..1

Indicates hether the plan is currently acted upon, represents future intentions, or is now a historical record. It allows clinicians to determine whether the plan is actionable or not. Conformance is required, and the valid statuses include: Proposed, Pending, Active, Completed, and Cancelled. For more information on this value set, see: http://hl7.org/fhir/ValueSet/care-plan-status.

category

CodeableConcept

0..*

Identifies what kind of plan this is to support differentiation between multiple co-existing plans. For example, “Home health”, “psychiatric”, “asthma”, “disease management”, “wellness plan”, and so forth. There may be multiple axis of categorization, and one plan may serve multiple purposes. In some cases, this may be redundant with references to CarePlan.concern. This value set contains 21 concepts. For more information on this value set, see: http://hl7.org/fhir/ValueSet/care-plan-category.

narrative summary

string

0..1

Text or HTML description of the assessment and plan. CarePlan.text.status is either Generated or Additional. This tool uses Generated. For more information on this value set, see: http://hl7.org/fhir/narrative-status, which defines the following codes: Generated, Extensions, Additional, and Empty.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

Local ID assigned to the report by the order filler, usually by the information system of the diagnostic service provider. You must know what identifier to use when making queries about this report from the source laboratory and for linking to the report outside FHIR context. Alternate name: ReportID.

status

code

1..1

Status of the diagnostic report as a whole. Diagnostic services routinely issue provisional/incomplete reports, and sometimes withdraw previously released reports. This is labeled as “Is Modifier” because applications need to take appropriate action if a report is withdrawn. The codes shall be taken from the DiagnosticReportStatus value set, which includes the following statuses: Registered, Partial, Final, Corrected, Appended, Cancelled, and Entered-in-Error. For more information on this value set, see: http://hl7.org/fhir/ValueSet/diagnostic-report-status.

category

CodeableConcept

0..1

Code that classifies the clinical discipline, department, or diagnostic service that created the report. For example, cardiology, biochemistry, hematology, or MRI. This is used for searching, sorting, and displaying purposes. The level of granularity is defined by the category concepts in the DiagnosticServiceSectionCodes value set. More filtering is performed using the metadata and/or terminology hierarchy in DiagnosticReport.code. Alternate names: Department, Sub-department, service, discipline. Example codes include: AU- Audiology, CH- Chemistry, MB- Microbiology, and HM- Hematology. For more information on this value set, see: http://hl7.org/fhir/ValueSet/diagnostic-service-sections.

code

CodeableConcept

1..1

Test, panel, or battery that was ordered. The typical patterns for codes are: 1) a LOINC code either as a translation from a “local” code or as a primary code, 2) a local code only if no suitable LOINC exists, or 3) both the local and the LOINC translation. Systems shall be capable of sending the local code if one exists. The codes shall be taken from US Laboratory Observation Profile Observation Name Codes. Other codes may be used where these codes are not suitable. This value set has more than 1000 codes. For more information on this value set, see: http://hl7.org/fhir/ValueSet/report-codes.

subject

Reference(Patient, Group, Device, Location)

1..1

Subject of the report. Usually this is a patient. However, diagnostic services also perform analyses on specimens collected from a variety of other sources.

encounter

Reference(Encounter)

0..1

Link to the healthcare event (encounter) when the order was made.

effectiveDateTime

dateTime

1..1

Specimen Collection Datetime which is the physically relevant dateTime for laboratory tests. If the diagnostic procedure was performed on the patient, this is the time it was performed. If there are specimens, the diagnostically relevant time can be derived from the specimen collection times, but the specimen information is not always available, and the exact relationship between the specimens and the diagnostically relevant time is not always automatic.

effectivePeriod

Period

1..1

Specimen Collection Period which is the physically relevant dateTime for laboratory tests. If the diagnostic procedure was performed on the patient, this is the time it was performed. If there are specimens, the diagnostically relevant time can be derived from the specimen collection times, but the specimen information is not always available, and the exact relationship between the specimens and the diagnostically relevant time is not always automatic. If the start element is missing, the start of the period is not known. If the end element is missing, it means that the period is ongoing, or the start may be in the past, and the end date in the future, which means that period is expected/planned to end at the specified time.

issued

Hl7.Fhir.Model.Instant

1..1

Date and time that this version of the report was released from the source diagnostic service. Clinicians must be able to check the date that the report was released. This may be different from the update time of the resource itself, because that is the status of the record (potentially a secondary copy), not the actual release time of the report. Alternate names: Date Created, Date published, Date Issued.

performer

Reference(Practitioner, Organization)

1..1

Diagnostic service that is responsible for issuing the report. This is helpful to know who to contact if there are queries about the results. You may need to track the source of reports for secondary data analysis. This is not necessarily the source of the atomic data items. It is the entity that takes responsibility for the clinical report. Alternate names: Laboratory, Service, Practitioner, Department, Company.

request

Reference(DiagnosticOrder, ProcedureRequest, ReferralRequest)

1..*

Details concerning a test or procedure requested. You need to be able to track completion of requests based on reports issued and also to report what diagnostic tests were requested (not always the same as what is delivered). You need to be able to track completion of requests based on reports issued and also to report what diagnostic tests were requested (not always the same as what is delivered).

specimen

Reference(Specimen)

0..*

Details about the specimens on which this diagnostic report is based. If the specimen is sufficiently specified with a code in the test result name, then this additional data may be redundant. If there are multiple specimens, these may be represented per observation or group.

result

Reference(Observation)

0..*

Observations that are part of this diagnostic report. Observations can be simple name/value pairs (for example, “atomic” results), or they can be grouping observations that include references to other members of the group (such as “panels”). You need to support individual results, or report groups of results, where the result grouping is arbitrary, but meaningful. This structure is recursive in that observations can contain observations. Alternate names: Data, Atomic Value, Result, Atomic result, Data, Test, Analyte, Battery, or Organizer.

imagingStudy

Reference(ImagingStudy, ImagingObjectSelection)

0..*

One or more links to full details of any imaging performed during the diagnostic investigation. Typically, this is imaging performed by DICOM enabled modalities, but this is not required. A fully enabled PACS viewer can use this information to provide views of the source images. ImagingStudy and ImageObjectStudy and the image element are somewhat overlapping – typically, the list of image references in the image element will also be found in one of the imaging study resources. However each caters to different types of displays for different types of purposes. Neither, either, or both may be provided.

image

0..*

List of key images associated with this report. The images are generally created during the diagnostic process, and may be directly of the patient, or of treated specimens (for example, slides of interest).

image.comment

string

0..1

Comment about the image. Typically this is used to provide an explanation for why the image is included, or to draw the viewer’s attention to important features. The provider of the report should make a comment about each image included in the report. The comment should be displayed with the image. It would be common for the report to include additional discussion of the image contents in other sections such as the conclusion.

image.link

Reference(Media)

1..1

Reference to the image source.

conclusion

string

0..1

Concise and clinically contextualized narrative interpretation of the diagnostic report. You need to be able to provide a conclusion that is not lost among the basic result data. Typically, a report is either [all data, no narrative (e.g. Core lab)] or [a mix of data with some concluding narrative (e.g. Structured Pathology Report, Bone Density)], or [all narrative (e.g. typical imaging report, histopathology)]. In all of these cases, the narrative goes in “text”.

codedDiagnosis

CodeableConcept

0..*

Codes for the conclusion which are SNOMED CT findings codes provided as adjunct diagnosis to the report. The codes should be taken from SNOMED CT Clinical Findings. Included are codes from http://snomed.info/sct where concept is-a 404684003. For more information on this value set, see: http://hl7.org/fhir/ValueSet/clinical-findings.

presentedForm

Hl7.Fhir.Model.Attachment

0..*

Rich text representation of the entire result as issued by the diagnostic service. Multiple formats are allowed but they shall be semantically equivalent. This gives the laboratory the ability to provide its own fully formatted report for clinical fidelity. Note: “application/pdf” is recommended as the most reliable and interoperable in this context.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

A unique identifier for the simple observation instance. Allows observations to be distinguished and referenced.

status

code

1..1

The status of the vital sign result value. The status of individual results needs to be tracked. Some results are finalized before the whole report is finalized. The conformance on this value set is required. Values include: Registered, Preliminary, Final, Amended, Cancelled, Entered in Error, and Unknown. For more information on this value set, see: http://hl7.org/fhir/ValueSet/observation-status

category

CodeableConcept

0..1

Classification of type of observation. Clinical observations measure the body’s basic functions such as such as blood pressure, heart rate, respiratory rate, height, weight, body mass index, head circumference, pulse oximetry, temperature, and body surface area. For more information on this value set, see: http://hl7.org/fhir/ValueSet/observation-category

code

CodeableConcept

1..1

This identifies the vital sign result type. Coded responses are from C-CDA Vital Sign Results. 1. Shall contain exactly one [1..1] code, where the @code should be selected from ValueSet HITSP Vital Sign Result Type. This value set indicates the allowed vital sign result types. The vocabulary selected for this value set aligns with requirements in the Meaningful Use (MU) Stage 2. Note the concept Blood pressure systolic and diastolic (55284-4) is used to group the related observations Systolic blood pressure (8480-6) and Diastolic blood pressure (8462-4). It shall not be used alone, but both 8480-6 and 8462-2 shall also be valued. The codes shall be taken from C-CDA Vital Sign Result; other codes may be used where these codes are not suitable. For more information on this value set, see: http://hl7.org/fhir/ValueSet/observation-codes

subject

Reference(Patient, Group, Device, Location)

0..1

Who and/or what this vital is for. The patient, or group of patients, location, or device whose characteristics (direct or indirect) are described by the observation and into whose record the observation is placed. Indirect characteristics may be those of a specimen, fetus, donor, other observer (for example a relative or EMT), or any observation made about the subject. Observations have no value if you don’t know who or what they’re about. Note: One would expect this element to be a cardinality of 1..1. The only circumstance in which the subject can be missing is when the observation is made by a device that does not know the patient. In this case, the observation shall be matched to a patient through some context/channel matching technique, and at this point, the observation should be updated.

encounter

Reference(Encounter)

0..1

The healthcare event (for example, a patient and healthcare provider interaction) during which this vital was obtained. For some observations it may be important to know the link between the vital sign and a particular encounter.

effectiveDateTime

dateTime

0..1

Clinically relevant time/time-period for observation. Often just a dateTime for Vital Signs. Knowing when an observation was deemed true is important to its relevance as well as determining trends. At least a date should be present unless this observation is a historical report.

effectivePeriod

Period

0..1

Clinically relevant time/time-period for observation. Often a dateTime for Vital Signs is preferred but if it is a historical instance, then a time period is sufficient.

issued

Hl7.Fhir.Model.Instant

0..1

Date/Time this was made available.

performer

Reference(Practitioner, Organization, Patient, RelatedPerson)

0..*

Who is responsible for the observation or obtaining the vital sign. May give a degree of confidence in the observation and also indicates where follow-up questions should be directed.

valueQuantity

Quantity

0..1

Vital Sign Value recorded with UCUM. Common UCUM units for recording Vital Signs. The codes shall be taken from Common UCUM units as defined in http://unitsofmeasure.org Examples include % (percent), cm (centimeter), kg (kilogram), mm(Hg) (millimeter of mercury), /min (per minute) and kg/m2 (kilogram). Note: Normally, an observation will have either a value or a set of related observations. A few observations (e.g. Apgar score) may have both a value and related observations (for an Apgar score, the observations from which the measure is derived). If a value is present, the datatype for this element should be determined by Observation.code. This element has a variable name depending on the type as follows: valueQuantity, valueCodeableConcept, valueString, valueRange, valueRatio, valueSampledData, valueAttachment, valueTime, valueDateTime, or valuePeriod. (The name format is “�value” + the type name” with a capital on the first letter of the type).

valueQuantity.value

http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.valueQuantity.value

0..1

The value of the measured amount. The value includes an implicit precision in the presentation of the value. Precision is handled implicitly in almost all cases of measurement. The implicit precision in the value should always be honored. Monetary values have their own rules for handling precision (refer to standard accounting text books).

valueQuantity.unit

http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.valueQuantity.unit

0..1

A human-readable form of the unit. There are many representations for units of measure and in many contexts, particular representations are fixed and required. For example, mcg for micrograms.

valueQuantity.system

http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.valueQuantity.system

0..1

The identification of the system that provides the coded form of the unit. Need to know the system that defines the coded form of the unit. Fixed value http://unitsofmeasure.org.

valueQuantity.code

http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.valueQuantity.code

0..1

Coded responses from the common UCUM units for vital signs value set. Need a computable form of the unit that is fixed across all forms. UCUM provides this for quantities, but SNOMED CT provides many units of interest. The preferred system is UCUM, but SNOMED CT can also be used (for customary units) or ISO 4217 for currency. The context of use may additionally require a code from a particular system.

dataAbsentReason

CodeableConcept

0..1

Provides a reason why the expected value in the element Observation.value[x] is missing. Codes specifying why the result (Observation.value[x]) is missing. The codes shall be taken from Observation Value Absent Reason value set, however other codes may be used where these codes are not suitable. This value set contains 9 concepts. For more information on this value set, see http://hl7.org/fhir/ValueSet/observation-valueabsentreason.

interpretation

CodeableConcept

0..1

This value set defines the set of codes that can be used to indicate the meaning/use of a reference range. The value set is extensible and contains 33 concepts. Examples include A (Abnormal), H (High), L (Low), and N (Normal). For more information on this value set, see http://hl7.org/fhir/ValueSet/observation-interpretation.

referenceRange

BackboneElement http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.referenceRange

0..*

Guidance on how to interpret the value by comparison to a normal or recommended range. Knowing what values are considered “normal” can help evaluate the significance of a particular result. Need to be able to provide multiple reference ranges for different contexts. Most observations only have one generic reference range. Systems may choose to restrict to only supplying the relevant reference range based on knowledge about the patient (for example, specific to the patient’s age, gender, weight, and other factors), but this may not be possible or appropriate. Whenever more than one reference range is supplied, the differences between them should be provided in the reference range and/or age properties.

— referenceRange.Low

SimpleQuantity http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.referenceRange.low

0..1

Indication that the vital result is lower than the defined reference range. Binding is common UCUM units for recording Vital Signs.

— referenceRange.High

SimpleQuantity http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.referenceRange.high

0..1

Indication that the vital result is higher than the defined reference range. Binding is common UCUM units for recording Vital Signs.

Respiratory rate

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Respiratory_Rate_Example

0..1

Recorded under LOINC Code 9279-1 using UOM of (breaths)/min.

Heart rate

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Heart_Rate_Example

0..1

Recorded under LOINC Code 8867-4 using UOM of (beats)/min.

Oxygen saturation

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Oxygen_Saturation_Example

0..1

Recorded under LOINC Code 59408-5 using UOM of % Oxygen saturation in Arterial blood by Pulse oximetry.

Body temperature

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Body_Temperature_Example

0..1

Recorded under LOINC Code 8310-5 using UOM of Cel or [degF].

Body height

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Body_height_Example

0..1

Recorded under LOINC Code 8302-2 using UOM cm or [in].

Body weight

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Body_Weight_Example

0..1

Recorded under LOINC Code 29463-7 using UOM g, kg or lb.

Body mass index

http://argonautwiki.hl7.org/index.php?title=Vital_Body_Mass_Example

0..1

Recorded under LOINC Code 39156-5 using UOM kg/m2.

Blood pressure systolic and diastolic

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Blood_Pressure_Example

1..1

Recorded under LOINC Code 55284-4 using UOM mm[Hg].

Systolic blood pressure

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Blood_Pressure_Example

1..1

Recorded under LOINC Code 8480-6 using UOM mm[Hg]. When recording a blood pressure using systolic and diastolic as separate entities, both must be recorded in order for the blood pressure to be valid.

Diastolic blood pressure

http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Blood_Pressure_Example

1..1

Recorded under LOINC Code 8462-4 using UOM mm[Hg]. When recording a blood pressure using systolic and diastolic as separate entities, both must be recorded in order for the blood pressure to be valid.

related

code http://www.hl7.org/fhir/daf/daf-vitalsigns-definitions.html#daf-vitalsigns.Observation.related.type

1..1

Codes specifying how two observations are related. This is used when reporting systolic and diastolic blood pressure. The codes shall be taken from the ObservationRelationshipType value set. For more information on this value set, see http://www.hl7.org/fhir/valueset-observation-relationshiptypes.html.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

Procedure identifier. These identifiers are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate (for example, in CDA documents, or in written/printed documentation).

subject

Reference(Patient, Group)

1..1

The person, animal, or group on which the procedure was performed.

status

code

1..1

in-progress , aborted , completed , entered-in-error. For more information on this value set, see procedure-status.

category

CodeableConcept

0..1

Classification of the procedure. For more information on this value set, see procedure-category.

code

CodeableConcept

1..1

Identification code of the procedure. The value set defines a set of codes that can be used to indicate the type of procedure: a specific code indicating type of procedure performed from CPT, SNOMED CT, and ICD10-PCS. For more information on this value set, see procedure-code.

notPerformed

boolean

0..1

Was the procedure not performed as scheduled? (Yes if not scheduled.)

reasonNotPerformed

CodeableConcept

0..*

Reason procedure was not performed. For more information on this value set, see procedure-not-performed-reason.

bodySite

CodeableConcept

0..*

Target body sites. For more information on this value set, see body-site.

reasonCodeableConcept

CodeableConcept

0..1

Reason why the procedure was performed.

reasonReference

Reference(Condition)

0..1

Reason for the procedure.

performer

0..*

The individual who performed the procedure. This must be a real person, not equipment.

performer.actor

Reference(Practitioner, Organization, Patient, RelatedPerson)

0..1

Reference to the practitioner.

performer.role

CodeableConcept

0..1

The role the actor was in. Values come from performer-role.

performedDateTime

dateTime

0..1

The date/time period over which the procedure was performed. Allows a period to support complex procedures that span more than one date, and also allows for the length of the procedure to be captured.

performedPeriod

Period

0..1

Date/time period during which the procedure was performed.

encounter

Reference(Encounter)

0..1

Encounter during which the procedure was performed.

location

Reference(Location)

0..1

Location where the procedure was performed.

outcome

CodeableConcept

0..1

The result of procedure. For more information on this value set, see procedure-outcome.

report

Reference(DiagnosticReport)

0..*

Any report resulting from the procedure.

complication

CodeableConcept

0..*

Complication following the procedure. For more information on this value set, see condition-code.

followUp

CodeableConcept

0..*

Instructions for follow up. For more information on this value set, see procedure-followup.

request

Reference(CarePlan, DiagnosticOrder, ProcedureRequest, ReferralRequest)

0..1

A request for the procedure.

notes

Annotation

0..*

Additional information about the procedure.

focalDevice

0..*

Device changed during the procedure.

focalDevice.action

CodeableConcept

0..1

Kind of change to device. For more information on this value set, see device-action.

focalDevice.manipulated

Reference(Device)

1..1

Device that was changed during the procedure.

used

Reference(Device, Medication, Substance)

0..*

Items used during procedure.

Name

Required?

Type

Description

pid

yes

URL

Patient’s logical ID. This is retrieved using the search function.

Name

Type

Cardinality

Description

identifier

0..*

External IDs for this plan. This records identifiers associated with this care team that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. This is a business identifier, not a resource identifier.

subject

Reference(Patient, Group)

0..1

Who the care team is for. Identifies the patient whose intended care is handled by the team.

status

code

1..1

Indicates whether the plan is currently being acted upon, represents future intentions, or is now a historical record. It also allows clinicians to determine whether the plan is actionable or not. Statuses returned include: Proposed, Draft (Pending), Active, Completed, and Cancelled. For more information on this value set, see: http://hl7.org/fhir/ValueSet/care-plan-status.

category

CodeableConcept

0..*

Options could include Problem, Health Concern, Care Team, or Assessment and Plan of Treatment. A type of plan which utilizes “Assessment and Plan of Treatment” – the clinical conclusions and assumptions that guide the patient’s treatment and the clinical activities formulated for a patient. Where the category is just “Assessment and Plan,” only the category “Assessment and Plan” will be returned. Values come from Argonaut Extension Codes for Care Plan http://argonautwiki.hl7.org/index.php?title=Argonaut_Extension_Codes.

participant

0..*

Members of the team. Identifies all people and organizations who are expected to be involved in the care team. Allows representation of care teams, and helps scope the care plan. In some cases, this may be a determiner of access permissions.

participant.role

CodeableConcept

0..1

Indicates the specific responsibility of an individual within the care team, such as primary physician, team coordinator, or caregiver. Roles may be inferred by type of practitioner. These are relationships that hold only within the context of the care team. General relationships should be handled as properties of the patient resource directly. For more information on this value set, see http://hl7.org/fhir/ValueSet/participant-role.

participant.member

Reference(Practitioner, RelatedPerson, Patient, Organization)

0..1

The specific person or organization who is participating in or expected to participate in the care team. The patient only needs to be listed if they have a role other than subject of care. Member is optional because some participants may be known only by their role, particularly in draft plans.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

Immunization record unique identifier.

status

code

1..1 Immunization current status.

Valid entries include: In-Progress, On-Hold, Completed, Entered-In-Error, and Stopped. For more information on this value set, see medication-admin-status.

date

dateTime

0..1

Date and time when the immunization was administered. When immunizations are patient reported, a specific date might not be known. Although partial dates are allowed, an adult patient might not be able to recall the year a childhood immunization was given.

vaccineCode

CodeableConcept

1..1

Vaccine product administered. Values come from vaccine-code.

patient

Reference(Patient)

1..1

Patient who received the immunization. Defines constraints and extensions on the patient resource for use in querying and retrieving patient demographic information.

wasNotGiven

boolean

1..1

Flag for whether immunization was given.

reported

boolean

1..1

Indicates a self-reported record.

performer

Reference(Practitioner)

0..1

Who administered vaccine.

requester

Reference(Practitioner)

0..1

Who ordered vaccination.

encounter

Reference(Encounter)

0..1

Encounter administered as part of.

manufacturer

Reference(Organization)

0..1

Vaccine manufacturer.

location

Reference(Location)

0..1

Where vaccination occurred.

lotNumber

string

0..1

Vaccine lot number.

expirationDate

date)

0..1

Vaccine expiration date.

site

CodeableConcept

0..1

Body site vaccine was administered. For more information on this value set, see immunization-site.

route

CodeableConcept

0..1

How vaccine entered body. For more information on this value set, see immunization-route.

doseQuantity

Hl7.Fhir.Model.SimpleQuantity

0..1

Amount of vaccine administered.

note

Annotation

0..*

Vaccination notes.

explanation

0..1

Administration/non-administration reasons.

explanation.reason

CodeableConcept

0..*

Reason why the immunization occurred. For more information on this value set, see immunization-reason.

explanation.reasonNotGiven

CodeableConcept

0..*

Reason why the immunization did not occur. For more information on this value set, see no-immunization-reason.

reaction

0..*

Details of a reaction that follows the immunization.

reaction.date

dateTime

0..1

Date/time when the reaction started.

reaction.detail

Reference(Observation)

0..1

Additional information about the reaction.

reaction.reported

boolean

0..1

Was the reaction self-reported?

vaccinationProtocol

0..*

Protocol that was followed during the administration of the immunization.

vaccinationProtocol.doseSequence

Hl7.Fhir.Model.PositiveInt

1..1

Dose number within series.

vaccinationProtocol.description

string

0..1

Details of vaccine protocol.

vaccinationProtocol.authority

Reference(Organization)

0..1

Individual who is responsible for immunization protocol.

vaccinationProtocol.series

string

0..1

Name of vaccine series.

vaccinationProtocol.seriesDoses

Hl7.Fhir.Model.PositiveInt

0..1

Recommended number of doses for immunity.

vaccinationProtocol.targetDisease

CodeableConcept

1..*

Disease immunized against. For more information on this value set, see vaccination-protocol-dose-target.

vaccinationProtocol.doseStatus

CodeableConcept

1..1

Indicates if dose counts towards immunity. For more information on this value set, see vaccination-protocol-dose-status.

vaccinationProtocol.doseStatusReason

CodeableConcept

0..1

Why dose does (not) count. For more information on this value set, see vaccination-protocol-dose-status-reason.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

Unique instance identifier assigned to a device by organizations like manufacturers or owners. If the identifier indicates the type of device, Device.type should be used. This is a business identifier, not a resource identifier, often fixed to the device as a barcode, and may include names given to the device in local usage. Note that some of the barcodes affixed to the device identify its type, not its instance. For the FDA mandated Unique Device Identifier (UDI), use the Device.udi element.

type

CodeableConcept

1..1

Code or identifier to indicate a kind of device. For the FDA mandated Unique Device Identifier (UDI), use the Device.udi element.

note

Annotation

0..*

Device notes and comments, including annotations.

status

code

0..1

Status of the device availability. This value set has an inline system that defines the following codes: Available, Not Available, and Entered-in-Error. For more information on this value set, see devicestatus.

manufacturer

string

0..1

Name of device manufacturer.

model

string

0..1

Model ID assigned by the manufacturer.

version

string

0..1

Version number. For example, software.

manufactureDate

dateTime

0..1

Manufacture date.

expiry

dateTime

0..1

Date and time of expiration of this device, if applicable.

udi

string

0..1

FDA mandated Unique Device Identifier.

lotNumber

string

0..1

Lot number of manufacturer.

owner

Reference(Organization)

0..1

Organization responsible for device.

location

Reference(Location)

0..1

Where the resource is found.

patient

Reference(Patient)

0..1

If the resource is affixed to a person.

contact

ContactPoint

0..*

Details for human/organization for support.

url

URI

0..1

Network address to contact device.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

External IDs for this plan. This is a business identifier, not a resource identifier. This records identifiers associated with this care plan that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. For example, in CDA documents or in written/printed documentation.

subject

Reference(Patient, Group)

0..1

Who the care plan is for. This identifies the patient or group whose intended care is described by the plan.

status

code

1..1

Indicates hether the plan is currently acted upon, represents future intentions, or is now a historical record. It allows clinicians to determine whether the plan is actionable or not. Conformance is required, and the valid statuses include: Proposed, Pending, Active, Completed, and Cancelled. For more information on this value set, see: http://hl7.org/fhir/ValueSet/care-plan-status.

category

CodeableConcept

0..*

Identifies what kind of plan this is to support differentiation between multiple co-existing plans. For example, “Home health”, “psychiatric”, “asthma”, “disease management”, “wellness plan”, and so forth. There may be multiple axis of categorization, and one plan may serve multiple purposes. In some cases, this may be redundant with references to CarePlan.concern. This value set contains 21 concepts. For more information on this value set, see: http://hl7.org/fhir/ValueSet/care-plan-category.

narrative summary

string

0..1

Text or HTML description of the assessment and plan. CarePlan.text.status is either Generated or Additional. This tool uses Generated. For more information on this value set, see: http://hl7.org/fhir/narrative-status, which defines the following codes: Generated, Extensions, Additional, and Empty.

Name

Required?

Type

Description

pid

yes

URL

The logical ID of the patient. This is retrieved using the search function.

date

no

string

A string representing a date to include in the search. See below for more information.

Name

Type

Cardinality

Description

identifier

0..*

External ID for this goal. This is a business identifier, not a resource identifier. This records identifiers associated with this care plan that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate (for example, in CDA documents, or in written/printed documentation).

subject

Reference(Patient, Group, Organization)

0..1

Who the goal is intended for. Subject identifies the patient, group, or organization for whom the goal is being established, typically the patient. Subject is optional to support anonymized reporting.

startDate

Date

0..1

When the goal pursuit begins. A date or partial date (for example, just year or year + month) as used in human communication. There is no time zone. Dates shall be valid dates.

startCodeableConcept

CodeableConcept

0..1

When the goal pursuit begins. This option is a codable concept that identifies types of events that might trigger the start of a goal as defined in http://snomed.info/sct. For example, Admission to the hospital (32485007), Childbirth (386216000), or Completion time of procedure (442137000).

targetDate

Date

0..1

Reach goal on or before. Indicates either the date or the duration after the start by which the goal should be met. This identifies when the goal should be evaluated. This can be a target date (or partial) or a duration of time.

targetQuantity

Quantity

0..1

Reach goal on or before. Indicates either the date or the duration after start by which the goal should be met. This identifies when the goal should be evaluated. This can be a target date (or partial) or a duration of time.

category

CodeableConcept

0..*

Indicates a category the goal falls within, and allows goals to be filtered and sorted based on a particular category. Examples of category include: Treatment, Dietary, or Behavioral. For more information on this value set, see http://hl7.org/fhir/ValueSet/goal-category.

description

string

1..1

Desired outcome. This is a human-readable description of a specific desired objective of care. Without a description of what’s trying to be achieved, the element has no purpose.

status

code

1..1

Indicates whether the goal has been reached and is still considered relevant. Options include: Proposed, Planned, Accepted, Rejected, In-progress, Achieved, Sustaining, On-hold, and Cancelled. For more information on this value set, see http://hl7.org/fhir/ValueSet/goal-status.

statusDate

date)

0..1

When goal status took effect. This identifies the current status. For example, when the goal was initially created, when the goal was achieved, when the goal was cancelled, and so on.

statusReason

CodeableConcept

0..1

Captures the reason for the current status. This is typically captured for statuses such as Rejected, On-hold, or Cancelled but could be present for others. Conformance is set as example. For more information on this value set, see: http://hl7.org/fhir/ValueSet/goal-status-reason.

author

Reference( Patient, Practitioner- https://www.hl7.org/fhir/Practitioner.html or Related Person- https://www.hl7.org/fhir/RelatedPerson.html

0..1

Who is responsible for creating the goal. This indicates whose goal this is: patient goal, practitioner goal, related person goal, and so on. This is the individual responsible for establishing the goal, not necessarily who recorded it. (For that, use the provenance resource.)

priority

CodeableConcept

0..1

Identifies the mutually agreed level of importance associated with reaching and/or sustaining the goal. This is used for sorting and presenting goals. Extensions are available to track priorities as established by each participant. For example, priority from the patient’s perspective, different practitioners’ perspectives, or family member’s perspectives. The ordinal extension on coding can be used to convey a numerically comparable ranking to priority. Conformance is preferred and defines the following codes: High, Medium, and Low. Different coding systems may use “low value=important.” For more information on this value set, see: http://hl7.org/fhir/ValueSet/goal-priority.

addresses

Reference(Condition, Observation, MedicationStatement, NutritionOrder, ProcedureRequest, RiskAssessment)

0..*

Identified conditions and other health record elements that are intended to be addressed by the goal. This allows specific goals to be explicitly linked to the concerns they’re dealing with which makes the goal more understandable. Reference profiles include: Condition, Observation, MedicationStatement, NutritionOrder, ProcedureRequest, and RiskAssessment.

note

Annotation

0..*

Comments or annotation about the goal. Must capture information about the goal that doesn’t actually describe the goal. May be used for progress notes, concerns, or other related information that doesn’t actually describe the goal itself. This is also an MU requirement, which determines the narrative portion of the goal.

outcome

0..*

The end result of goal. Outcome identifies the change (or lack of change) at the point where the goal was deemed to be cancelled or achieved. Outcome tracking is a key aspect of care planning. Note that this should not duplicate the goal status.

outcome.resultCodeableConcept

CodeableConcept

0..1

Code or observation that resulted from goal.

outcome.resultReference

Reference(Observation)

0..1

Code or observation that resulted from the goal. This describes what has or has not changed. GoalOutcome: The result of the goal. For example, “25% increase in shoulder mobility,” “Anxiety reduced to moderate levels,” or “15 kg weight loss sustained over 6 months.”

Name

Required?

Type

Description

pid

yes

URL

Patient’s logical ID. This is retrieved using the search function.

Name

Type

Cardinality

Description

identifier

0..*

Identifier associated with this condition that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. For example, in CDA documents or in written/printed documentation.

patient

Reference(Patient)

1..1

Indicates the patient who the condition record is associated with. This defines constraints and extensions on the patient resource for use in querying and retrieving patient demographic information.

encounter

Reference(Encounter)

0..1

Encounter during which the condition was first asserted.

asserter

Reference(Practitioner, Patient)

0..1

Individual who is making the condition statement. This could be a provider or patient reference.

dateRecorded

date)

0..1

Indicates the date when this particular condition record was created in the EHR, not the date of the most recent update in terms of when severity, abatement, and so forth were specified. The date of the last record modification can be retrieved from the resource metadata.

code

CodeableConcept

1..1

Identification of the condition, problem, or diagnosis. For more information on this value set, see http://hl7.org/fhir/ValueSet/condition-code.

category

CodeableConcept

0..1

A category assigned to the condition. The categorization is often highly contextual and may appear poorly differentiated or not very useful in other contexts. The value set conformance is preferred and options include: Complaint, Symptom, Finding, and Diagnosis. For more information on this value set, see http://hl7.org/fhir/ValueSet/condition-category.

clinicalStatus

code

0..1

The clinical status of the condition. The value set conformance is preferred and options include: Active, Relapse, Remission, and Resolved. For more information on this value set, see http://hl7.org/fhir/ValueSet/condition-clinical

verificationStatus

code

1..1

The verification status of the condition or rather, the verification status to support or decline the clinical status of the condition or diagnosis. The value set conformance is required and options include: Provisional, Differential, Confirmed, Refuted, Entered-in-error, and Unknown. For more information on this value set, see http://hl7.org/fhir/ValueSet/condition-ver-status.

severity

CodeableConcept

0..1

Subjective severity of condition. The value set conformance is extensible and options include: Fatal, Severe, Moderate, and Mild. Extensions are allowed. For more information on this value set, see http://hl7.org/fhir/ValueSet/condition-severity.

onsetDateTime

dateTime

0..1

Estimated or actual date, date-time, or age. A date, when the Condition statement was documented. The Date Recorded represents the date when this particular Condition record was created in the EHR, not the date of the most recent update in terms of when severity, abatement, etc. were specified. The date of the last record modification can be retrieved from the resource metadata.

onsetQuantity

Quantity

0..1

There shall be a code if there is a value and it shall be an expression of time. If system is present, it shall be UCUM. If value is present, it shall be positive. The context of use may frequently define what kind of quantity this is and therefore what kind of units can be used. In this case, it is used to define the onset of the condition.

onsetPeriod

Period

0..1

A time period defined by a start and end date/time. A period specifies a range of times. The context of use will specify whether the entire range applies (for example, “the patient was an inpatient of the hospital for this time range”) or one value from the period applies For example, “give to the patient between 2 and 4 pm on 24-Jun 2013.”

onsetRange

Hl7.Fhir.Model.Range

0..1

A set of ordered Quantity values defined by a low and high limit. A Range specifies a set of possible values; usually, one value from the range applies. For example, “give the patient between 2 and 4 tablets.” Ranges are typically used in instructions.

onsetString

String

0..1

A sequence of Unicode characters to convey the estimated onset of when the condition started.

abatementDateTime

dateTime

0..1

Estimated or actual date or date-time when the Condition statement was resolved or in remission.

abatementQuantity

Quantity

0..1

There shall be a code if there is a value and it shall be an expression of time. If system is present, it shall be UCUM. If value is present, it shall be positive. The context of use may frequently define what kind of quantity this is and therefore what kind of units can be used. In this case, it is used to indicate when the condition was resolved or in remission.

abatementBoolean

Boolean

0..1

There is no explicit distinction between resolution and remission because in many cases the distinction is not clear. Age is generally used when the patient reports an age at which the Condition abated. If there is no abatement element, it is unknown whether the condition was resolved or in remission; applications and users should generally assume that the condition is still valid.

abatementPeriod

Period

0..1

A time period defined by a start and end date/time. A period specifies a range of times for if or when the condition was resolved or in remission.

abatementRange

Hl7.Fhir.Model.Range

0..1

A set of ordered quantity values defined by a low and high limit. A range specifies a set of possible values; usually, one value from the range applies. In this case, the range defines if and when the condition was resolved or in remission.

abatementString

String

0..1

A sequence of unicode characters to convey when the condition was resolved or in remission.

stage

0..1

A set of codified values for which the conformance is example and is typically used to indicate stages of cancer and other conditions. Stage/grade, usually assessed formally. For more information on this value set, see http://hl7.org/fhir/valueset-condition-stage.html.

stage.summary

CodeableConcept

0..1

A simple summary of the stage such as “Stage 3.” The determination of the stage is disease-specific. For more information on this value set, see http://hl7.org/fhir/ValueSet/condition-stage.

stage.assessment

Reference(ClinicalImpression, DiagnosticReport, Observation)

0..*

Reference to a formal record of the evidence on which the staging assessment is based. Reference resources include: ClinicalImpression, DiagnosticReport, and Observation.

evidence

0..*

Supporting evidence or manifestations that are the basis on which this condition is suspected or confirmed. The evidence may be a simple list of coded symptoms/manifestations, references to observations or formal assessments, or both.

evidence.code

CodeableConcept

0..1

A manifestation or symptom that led to the recording of this condition. This includes a value set where the conformance is examples that describe the manifestations or symptoms. For more information on this value set, see http://hl7.org/fhir/ValueSet/manifestation-or-symptom.

evidence.detail

Reference(Resource)

0..*

Supporting information found elsewhere, such as links to other relevant information, including pathology reports.

bodySite

CodeableConcept

0..*

Anatomical location, if relevant. This value set includes all the Anatomical Structure SNOMED CT codes. For example, codes with an is-a relationship with 91723000: Anatomical structure. For more information on this value set, see http://hl7.org/fhir/ValueSet/body-site.

notes

string

0..1

Additional information about the Condition. This is a general note or comment entry for further description of the condition, diagnosis, and prognosis.