This is the current version of the PS-CA Implementation Guide. Other releases of the PS-CA Implementation Guide may be found at Guides.
Condition (PS-CA)
Additional information on this profile (including the JSON & XML structure and detailed element descriptions) can be found at Condition (PS-CA)
Profile
Condition | I | Condition | There are no (further) constraints on this element Element IdCondition Detailed information about conditions, problems or diagnoses DefinitionA clinical condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern.
| |
identifier | Σ | 0..* | Identifier | There are no (further) constraints on this element Element IdCondition.identifier External Ids for this condition DefinitionBusiness identifiers assigned to this condition by the performer or other systems which remain constant as the resource is updated and propagates from server to server. Allows identification of the condition as it is known by various participating systems and in a way that remains consistent across servers. This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.
|
clinicalStatus | S Σ ?! I | 1..1 | CodeableConceptBinding | Element IdCondition.clinicalStatus active | recurrence | relapse | inactive | remission | resolved DefinitionThe clinical status of the condition. While the IPS-UV specification considers this a Must Support element, some systems will not have a field directly representing clinicalStatus, but have other means of differentiating between current and historical conditions. Implementers are expected to be able to differentiate between active and inactive conditions. The requirement from the base FHIR specification to provide a system and value from the bound value set means the PS-CA CodeableConcept data type profile does not need to be applied on this particular element. In the scope of the IPS-UV the entered-in-error concept is not allowed and so the modifier on this element has been removed. The clinical status of the condition or diagnosis. ConditionClinicalStatusCodes (required)Constraints
|
verificationStatus | Σ ?! I | 0..1 | CodeableConceptBinding | Element IdCondition.verificationStatus unconfirmed | provisional | differential | confirmed | refuted | entered-in-error DefinitionThe verification status to support the clinical status of the condition. IPS-UV no longer flags this as a Must Support element. It is not currently flagged as Must Support in PS-CA, as stakeholders have indicated the element may not be supported by the majority of systems today. Systems that do support the element are encouraged to include it in generated Patient Summary documents, and support it when received. FHIR Base Note: This element is a modifier element with a required vocabulary binding in the base FHIR specification. IPS-UV Note: In the scope of the IPS-UV the entered-in-error concept is not allowed and so the modifier on this element has been removed. The verification status to support or decline the clinical status of the condition or diagnosis. ConditionVerificationStatus (required)Constraints
|
category | 0..* | CodeableConceptBinding | Element IdCondition.category problem-list-item | encounter-diagnosis DefinitionA category assigned to the condition. In this profile, a health problem of the patient, therefore a 'problem-list-item'. IPS-UV flags this as a Must Support element. It is not currently flagged as Must Support in PS-CA, as stakeholders have indicated the element may not be supported by the majority of systems today. Systems that do support the element are encouraged to include it in generated Patient Summary documents, and support it when received. Implementers should be aware that IPS heavily encourages a LOINC value of 75326-9 be sent as an additional coding for category. However, the method that IPS will use to enforce this coding is still evolving and therefore not reflected in this current profile. A category assigned to the condition. ConditionCategoryCodes (extensible)Constraints
| |
severity | 0..1 | CodeableConceptBinding | Element IdCondition.severity Subjective severity of condition DefinitionA subjective assessment of the severity of the condition as evaluated by the clinician. IPS-UV flags this as a Must Support element. It is not currently flagged as Must Support in PS-CA, as stakeholders have indicated the element may not be supported by the majority of systems today. Systems that do support the element are encouraged to include it in generated Patient Summary documents, and support it when received. A subjective assessment of the severity of the condition as evaluated by the clinician. SeverityCode (preferred)Constraints
| |
coding | Σ | 0..* | Coding | Element IdCondition.severity.coding Code defined by a terminology system DefinitionA reference to a code defined by a terminology system. Allows for alternative encodings within a code system, and translations to other code systems. Future releases of PS-CA may require use of coded entries. In this release, however, implementations that support codings are encouraged to send the codings for codeable concepts if they are available. Consistent with FHIR best practice, receivers should not produce failures or rejections if codings are received. Vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content. Unordered, Open, by $this(Pattern) Constraints
|
severityLOINC | Σ | 0..* | CodingBinding | Element IdCondition.severity.coding:severityLOINC Optional slice for representing the severity of a problem using the LOINC value set defined by IPS. DefinitionCode for representing the severity of a problem using the LOINC value set defined by IPS. Allows for alternative encodings within a code system, and translations to other code systems. Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true. IPS LOINC Severity Value Set ProblemSeverityUvIps (required)Constraints
|
severitySCTCA | Σ | 0..* | CodingBinding | Element IdCondition.severity.coding:severitySCTCA Optional slice for representing the severity of a problem from the SNOMED CT Canadian edition value set. DefinitionCode for the severity of a problem that is selected from the SNOMED CT Canadian edition value set. Allows for alternative encodings within a code system, and translations to other code systems. Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true. severitySCTCA SeverityCode (required)Constraints
|
text | Σ | 0..1 | string | There are no (further) constraints on this element Element IdCondition.severity.text Plain text representation of the concept DefinitionA human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user. The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source. Very often the text is the same as a displayName of one of the codings.
|
code | S Σ | 1..1 | Data Type: Codeable Concept (PS-CA)Binding | Element IdCondition.code Concept - reference to a terminology or just text Alternate namestype DefinitionIdentification of the condition, problem or diagnosis or recording of "problem absent" or of "problems unknown". 0..1 to account for primarily narrative only resources. Many Canadian implementations use codes from either SNOMED CT and the SNOMED CT Canada Extension to describe this concept, while others may still be using localized code systems or text descriptions. The Condition - IPS ValueSet contains codes that are subsumed within the SNOMED CT CA ClinicalFindingCode ValueSet that is preferred for this element. Future releases of PS-CA may require use of coded entries. In this release, however, implementations that support codings are encouraged to send the codings for codeable concepts if they are available. Consistent with FHIR best practice, receivers should not produce failures or rejections if codings are received. Vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content. Data Type: Codeable Concept (PS-CA) BindingIdentification of the condition or diagnosis. ClinicalFindingCode (preferred)Constraints
|
coding | Σ | 0..* | Data Type: Coding (PS-CA) | Element IdCondition.code.coding A reference to a code defined by a terminology system DefinitionA reference to a code defined by a terminology system. Allows for alternative encodings within a code system, and translations to other code systems. While the IPS-UV specification considers this a Must Support element, some systems will not have the ability to support codings for every codeableConcept, further feedback is required on whether these systems are still expected to be able to demonstrate they can construct this element when developing the patient summary instance. Implementors that support codings should still send the codings for codeable concepts if they are available and receivers should not produce failures or rejections if codings are included in the patient summary in the first release (a base tenet of FHIR). Additionally vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content Unordered, Open, by $this(Pattern) Constraints
|
codeSCTCA | Σ | 0..* | Data Type: Coding (PS-CA)Binding | Element IdCondition.code.coding:codeSCTCA Optional slice for representing the code for a problem from the SNOMED CT Canadian edition value set DefinitionCode for representing the code for a problem that is selected from the SNOMED CT Canadian edition value set. This is the preferred code system for pan-Canadian use and should be provided, or used, if available. Allows for alternative encodings within a code system, and translations to other code systems. While the IPS-UV specification considers this a Must Support element, some systems will not have the ability to support codings for every codeableConcept, further feedback is required on whether these systems are still expected to be able to demonstrate they can construct this element when developing the patient summary instance. Implementors that support codings should still send the codings for codeable concepts if they are available and receivers should not produce failures or rejections if codings are included in the patient summary in the first release (a base tenet of FHIR). Additionally vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content Codes for problems from the SNOMED CT Canadian edition value set ClinicalFindingCode (required)Constraints
|
codeICD9CM | Σ | 0..* | Data Type: Coding (PS-CA)Binding | Element IdCondition.code.coding:codeICD9CM Optional slice to reflect that ICD-9 CM is used in some Canadian jurisdictions for conditions DefinitionThis slice reflects that ICD-9 CM is used in some Canadian jurisdictions for conditions. While SNOMED-CT CA is the preferred code system for this element, implementers may encounter ICD-9 CM codes in some circumstances or jurisdictions. Note: Implementers should be cautioned that ICD-9 CM is considered a legacy terminology that is no longer maintained by the organization that developed it. Allows for alternative encodings within a code system, and translations to other code systems. While the IPS-UV specification considers this a Must Support element, some systems will not have the ability to support codings for every codeableConcept, further feedback is required on whether these systems are still expected to be able to demonstrate they can construct this element when developing the patient summary instance. Implementors that support codings should still send the codings for codeable concepts if they are available and receivers should not produce failures or rejections if codings are included in the patient summary in the first release (a base tenet of FHIR). Additionally vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content Any code from ICD-9 CM. ICD9CMAllCode (required)Constraints
|
codeICD10CA | Σ | 0..* | Data Type: Coding (PS-CA)Binding | Element IdCondition.code.coding:codeICD10CA Optional slice to reflect that ICD-10 CA is used in some Canadian jurisdictions for conditions DefinitionThis slice reflects that ICD-10 CA is used in some Canadian jurisdictions for conditions. While SNOMED-CT CA is the preferred code system for this element, implementers may encounter ICD-10 CA codes in some circumstances or jurisdictions. Allows for alternative encodings within a code system, and translations to other code systems. While the IPS-UV specification considers this a Must Support element, some systems will not have the ability to support codings for every codeableConcept, further feedback is required on whether these systems are still expected to be able to demonstrate they can construct this element when developing the patient summary instance. Implementors that support codings should still send the codings for codeable concepts if they are available and receivers should not produce failures or rejections if codings are included in the patient summary in the first release (a base tenet of FHIR). Additionally vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content Any code from ICD-10 CA. ICD10CAAllCode (required)Constraints
|
absentOrUnknownProblem | Σ | 0..* | Data Type: Coding (PS-CA)Binding | Element IdCondition.code.coding:absentOrUnknownProblem Optional slice for representing the code for absent problem or for unknown problem DefinitionCode representing the statement "absent problem" or the statement "problems unknown" Allows for alternative encodings within a code system, and translations to other code systems. IPS-UV no longer flags this as a Must Support Element. Many systems will not have a field within their data dictionaries that directly corresponds to absentOrUnknownProblem and so the MS flag has been removed. However, it is recommended that systems be able to support the communication of this concept across a number of clinical profiles where population of the clinical element is crucial to clinical interpretation and use. Absent problem or unknown problem AbsentOrUnknownProblemsUvIps (required)Constraints
|
text | S Σ | 0..1 | string | There are no (further) constraints on this element Element IdCondition.code.text Plain text representation of the concept DefinitionA human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user. The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source. Very often the text is the same as a displayName of one of the codings.
|
bodySite | Σ | 0..* | CodeableConceptBinding | Element IdCondition.bodySite Anatomical location, if relevant DefinitionThe anatomical location where this condition manifests itself. Only used if not implicit in code found in Condition.code. If the use case requires attributes from the BodySite resource (e.g. to identify and track separately) then use the standard extension bodySite. May be a summary code, or a reference to a very precise definition of the location, or both. Codes describing anatomical locations. May include laterality. AnatomicalOrAcquiredBodyStructureCode (preferred)Constraints
|
subject | S Σ I | 1..1 | Reference(Patient (PS-CA)) | Element IdCondition.subject Who has the condition? Alternate namespatient DefinitionIndicates the patient or group who the condition record is associated with. Group is typically used for veterinary or public health use cases. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
reference | S Σ I | 1..1 | string | There are no (further) constraints on this element Element IdCondition.subject.reference Literal reference, Relative, internal or absolute URL DefinitionA reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources. Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.
|
type | Σ | 0..1 | uriBinding | There are no (further) constraints on this element Element IdCondition.subject.type Type the reference refers to (e.g. "Patient") DefinitionThe expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent. The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. "Patient" is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources). This element is used to indicate the type of the target of the reference. This may be used which ever of the other elements are populated (or not). In some cases, the type of the target may be determined by inspection of the reference (e.g. a RESTful URL) or by resolving the target of the reference; if both the type and a reference is provided, the reference SHALL resolve to a resource of the same type as that specified. Aa resource (or, for logical models, the URI of the logical model). ResourceType (extensible)Constraints
|
identifier | Σ | 0..1 | Identifier | There are no (further) constraints on this element Element IdCondition.subject.identifier Logical reference, when literal reference is not known DefinitionAn identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference. When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy. When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it. Reference is intended to point to a structure that can potentially be expressed as a FHIR resource, though there is no need for it to exist as an actual FHIR resource instance - except in as much as an application wishes to actual find the target of the reference. The content referred to be the identifier must meet the logical constraints implied by any limitations on what resource types are permitted for the reference. For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference(Observation|DiagnosticReport). One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (where the type is Reference (Any).
|
display | Σ | 0..1 | string | There are no (further) constraints on this element Element IdCondition.subject.display Text alternative for the resource DefinitionPlain text narrative that identifies the resource in addition to the resource reference. This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.
|
encounter | Σ I | 0..1 | Reference(Encounter) | There are no (further) constraints on this element Element IdCondition.encounter Encounter created as part of DefinitionThe Encounter during which this Condition was created or to which the creation of this record is tightly associated. This will typically be the encounter the event occurred within, but some activities may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter. This record indicates the encounter this particular record is associated with. In the case of a "new" diagnosis reflecting ongoing/revised information about the condition, this might be distinct from the first encounter in which the underlying condition was first "known".
|
onset[x] | S Σ | 0..1 | Element IdCondition.onset[x] Estimated or actual date, date-time, or age DefinitionEstimated or actual date or date-time the condition began, in the opinion of the clinician. IPS-UV constrains the condition onset element to only DateTime and Period data types. Both IPS-UV and PS-CA prefer the use of onsetDateTime Unordered, Open, by $this(Type) Constraints
| |
onsetAge | Age | There are no (further) constraints on this element Data Type | ||
onsetRange | Range | There are no (further) constraints on this element Data Type | ||
onsetString | string | There are no (further) constraints on this element Data Type | ||
onsetDateTime | S Σ | 0..1 | dateTime | Element IdCondition.onset[x]:onsetDateTime Estimated or actual date, date-time, or age DefinitionEstimated or actual date or date-time the condition began, in the opinion of the clinician. Age is generally used when the patient reports an age at which the Condition began to occur.
|
onsetPeriod | Σ | 0..1 | Period | Element IdCondition.onset[x]:onsetPeriod Estimated or actual date, date-time, or age DefinitionEstimated or actual date or date-time the condition began, in the opinion of the clinician. Age is generally used when the patient reports an age at which the Condition began to occur.
|
abatement[x] | I | 0..1 | There are no (further) constraints on this element Element IdCondition.abatement[x] When in resolution/remission DefinitionThe date or estimated date that the condition resolved or went into remission. This is called "abatement" because of the many overloaded connotations associated with "remission" or "resolution" - Conditions are never really resolved, but they can abate. 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 has resolved or entered remission; applications and users should generally assume that the condition is still valid. When abatementString exists, it implies the condition is abated.
| |
abatementDateTime | dateTime | There are no (further) constraints on this element Data Type | ||
abatementAge | Age | There are no (further) constraints on this element Data Type | ||
abatementPeriod | Period | There are no (further) constraints on this element Data Type | ||
abatementRange | Range | There are no (further) constraints on this element Data Type | ||
abatementString | string | There are no (further) constraints on this element Data Type | ||
recordedDate | Σ | 0..1 | dateTime | There are no (further) constraints on this element Element IdCondition.recordedDate Date record was first recorded DefinitionThe recordedDate represents when this particular Condition record was created in the system, which is often a system-generated date.
|
recorder | Σ I | 0..1 | Reference(Practitioner | PractitionerRole | Patient | RelatedPerson) | There are no (further) constraints on this element Element IdCondition.recorder Who recorded the condition DefinitionIndividual who recorded the record and takes responsibility for its content. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Practitioner | PractitionerRole | Patient | RelatedPerson) Constraints
|
asserter | Σ I | 0..1 | Reference(Practitioner | PractitionerRole | Patient | RelatedPerson) | There are no (further) constraints on this element Element IdCondition.asserter Person who asserts this condition DefinitionIndividual who is making the condition statement. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Practitioner | PractitionerRole | Patient | RelatedPerson) Constraints
|
stage | I | 0..* | BackboneElement | There are no (further) constraints on this element Element IdCondition.stage Stage/grade, usually assessed formally DefinitionClinical stage or grade of a condition. May include formal severity assessments.
|
summary | I | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdCondition.stage.summary Simple summary (disease specific) DefinitionA simple summary of the stage such as "Stage 3". The determination of the stage is disease-specific. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Codes describing condition stages (e.g. Cancer stages). ConditionStage (example)Constraints
|
assessment | I | 0..* | Reference(ClinicalImpression | DiagnosticReport | Observation) | There are no (further) constraints on this element Element IdCondition.stage.assessment Formal record of assessment DefinitionReference to a formal record of the evidence on which the staging assessment is based. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(ClinicalImpression | DiagnosticReport | Observation) Constraints
|
type | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdCondition.stage.type Kind of staging DefinitionThe kind of staging, such as pathological or clinical staging. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Codes describing the kind of condition staging (e.g. clinical or pathological). ConditionStageType (example)Constraints
| |
evidence | I | 0..* | BackboneElement | There are no (further) constraints on this element Element IdCondition.evidence Supporting evidence DefinitionSupporting evidence / manifestations that are the basis of the Condition's verification status, such as evidence that confirmed or refuted the condition. The evidence may be a simple list of coded symptoms/manifestations, or references to observations or formal assessments, or both.
|
code | Σ I | 0..* | CodeableConcept | There are no (further) constraints on this element Element IdCondition.evidence.code Manifestation/symptom DefinitionA manifestation or symptom that led to the recording of this condition. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Codes that describe the manifestation or symptoms of a condition. ManifestationAndSymptomCodes (example)Constraints
|
detail | Σ I | 0..* | Reference(Resource) | There are no (further) constraints on this element Element IdCondition.evidence.detail Supporting information found elsewhere DefinitionLinks to other relevant information, including pathology reports. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
note | 0..* | Annotation | There are no (further) constraints on this element Element IdCondition.note Additional information about the Condition DefinitionAdditional information about the Condition. This is a general notes/comments entry for description of the Condition, its diagnosis and prognosis. For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).
|
Key Differences between the IPS-UV and PS-CA
Must Support Differences:
The following elements are considered Must Support in the Condition (IPS) profile that are relaxed in this version of the PS-CA profile:
Condition.category
Condition.severity
Note: Systems that support these elements are encouraged to send them in patient summaries
Cardinality Differences:
There are no cardinality differences between this profile and IPS-UV
Vocabulary Differences:
Condition.severity
- optional slice added for SNOMED CT Canadian Edition SeverityCode
- SNOMED CT Canadian Edition SeverityCode indicated as preferred
Condition.code
- optional slices added for SNOMED CT Canadian Edition ClinicalFindingCode, ICD9CMAllCode, and ICD10CAAllCode
- SNOMED CT Canadian Edition ClinicalFindingCode indicated as preferred
- Removal of AllergyIntoleranceSubstanceConditionUvIps value set slice as its values are already in the SCTCA slice
- Temporary removal of slice pointing to CoreProblemListFindingSituationEventGpsUvIps value set until modeling is corrected by IPS to ensure validator tools can identify and distinguish use of the value set. See Known Issues & Future Development
Condition.bodySite
- SNOMED CT Canadian Edition AnatomicalOrAcquiredBodyStructureCode indicated as preferred
Other differences between the IPS and PS-CA Include:
Condition.subject
- reference target changed to Patient (PS-CA)