{
"description": null,
"_filename": "profile-condition-patientchart.StructureDefinition.json",
"package_name": "ForgePatientChart.0830",
"date": "2022-03-30T17:59:35.70094+00:00",
"derivation": "constraint",
"meta": {
"versionId": "2",
"lastUpdated": "2022-08-24T15:25:14.1127437+00:00"
},
"publisher": null,
"fhirVersion": "4.0.1",
"name": "Condition",
"mapping": [ {
"uri": "http://hl7.org/fhir/workflow",
"name": "Workflow Pattern",
"identity": "workflow"
}, {
"uri": "http://snomed.info/conceptdomain",
"name": "SNOMED CT Concept Domain Binding",
"identity": "sct-concept"
}, {
"uri": "http://hl7.org/v2",
"name": "HL7 v2 Mapping",
"identity": "v2"
}, {
"uri": "http://hl7.org/v3",
"name": "RIM Mapping",
"identity": "rim"
}, {
"uri": "http://hl7.org/fhir/fivews",
"name": "FiveWs Pattern Mapping",
"identity": "w5"
}, {
"uri": "http://snomed.org/attributebinding",
"name": "SNOMED CT Attribute Binding",
"identity": "sct-attr"
} ],
"abstract": false,
"type": "Condition",
"experimental": null,
"resourceType": "StructureDefinition",
"title": "Condition Patient Chart",
"package_version": "0.1.0",
"status": "draft",
"id": "bbce4020-e6c3-42f9-a019-893a65d210f3",
"kind": "resource",
"url": "http://telus.com/fhir/patientChart/StructureDefinition/profile-condition",
"version": null,
"differential": {
"element": [ {
"id": "Condition.id",
"path": "Condition.id",
"comment": "Usage Note: This will usually be a GUID that is assigned by the sending application.\r\n\r\nThe only time that a resource does not have an id is when it is being submitted to the server using a create operation.",
"mustSupport": true
}, {
"id": "Condition.meta",
"path": "Condition.meta",
"mustSupport": true
}, {
"id": "Condition.meta.lastUpdated",
"path": "Condition.meta.lastUpdated",
"mustSupport": true
}, {
"id": "Condition.meta.source",
"path": "Condition.meta.source",
"mustSupport": true
}, {
"id": "Condition.meta.profile",
"path": "Condition.meta.profile",
"comment": "Usage: This will be determined by each impelmenttion. This may be useful for validation of message instances against this profile.\r\n\r\nIt is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time. The list of profile URLs is a set.",
"mustSupport": true
}, {
"id": "Condition.meta.security",
"path": "Condition.meta.security",
"mustSupport": true
}, {
"id": "Condition.meta.security.system",
"path": "Condition.meta.security.system",
"mustSupport": true
}, {
"id": "Condition.meta.security.code",
"path": "Condition.meta.security.code",
"mustSupport": true
}, {
"id": "Condition.text",
"path": "Condition.text",
"comment": "Conformance Rule: This must be formatted, as closely as possible what was presented to the user in the originating system and must include all clinical data. \r\n\r\nContained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a \"text blob\" or where text is additionally entered raw or narrated and encoded information is added later.",
"mustSupport": true
}, {
"id": "Condition.clinicalStatus",
"path": "Condition.clinicalStatus",
"comment": "Usage: Problem List items are active; past health events/problems are inactive. When conditions are added to an encounter, this could be active in or inactive/resolved, etc. though a state is not usually captured discretely in the EMR. This may be captured as text which is not accessible.\r\nUsage Note: For problem list items, this should be treated as mandatory; these will be active unless user has chosen a different statuss. For past health events, this should be mandatory and inactive. \r\nUsage Note: For encounter-diagnosis, this is optional and only specified when EMR's discretely capture this data.\r\n\r\nAlignment: Ths is mandatory in R5; known issue: the EMR does not always have an encounter diagnosis.\r\nAlignment: Mandatory in PS-ON and PS-CA. This is not mandatory in the Patient Chart as the status is not always known in the context of an encounter-diagnosis as this may not be captured discretely.\r\n \r\nMA: urn:telus:emr:ma:*:codetable:problem-clinical-status\r\nPSS:urn:telus:emr:pss:*:codetable:problem-clinicalstatus\r\nMS: N/A\r\nEMRAPI = clinicalStatus\r\n\r\nThe data type is CodeableConcept because clinicalStatus has some clinical judgment involved, such that there might need to be more specificity than the required FHIR value set allows. For example, a SNOMED coding might allow for additional specificity.",
"mustSupport": true
}, {
"id": "Condition.clinicalStatus.coding",
"max": "1",
"path": "Condition.clinicalStatus.coding",
"mustSupport": true
}, {
"id": "Condition.clinicalStatus.coding.system",
"min": 1,
"path": "Condition.clinicalStatus.coding.system",
"mustSupport": true
}, {
"id": "Condition.clinicalStatus.coding.code",
"min": 1,
"path": "Condition.clinicalStatus.coding.code",
"mustSupport": true
}, {
"id": "Condition.clinicalStatus.text",
"path": "Condition.clinicalStatus.text",
"mustSupport": true
}, {
"id": "Condition.verificationStatus",
"path": "Condition.verificationStatus",
"comment": "EMRAPI = ConfirmationStatus\r\nMA: urn:telus:emr:ma:*:codetable:problem-clinical-status\r\nPSS:urn:telus:emr:pss:*:codetable:problem-clinicalstatus\r\nMS: N/A\r\n\r\nverificationStatus is not required. For example, when a patient has abdominal pain in the ED, there is not likely going to be a verification status.\nThe data type is CodeableConcept because verificationStatus has some clinical judgment involved, such that there might need to be more specificity than the required FHIR value set allows. For example, a SNOMED coding might allow for additional specificity.",
"mustSupport": true
}, {
"id": "Condition.verificationStatus.coding",
"max": "1",
"path": "Condition.verificationStatus.coding",
"mustSupport": true
}, {
"id": "Condition.verificationStatus.coding.system",
"min": 1,
"path": "Condition.verificationStatus.coding.system",
"mustSupport": true
}, {
"id": "Condition.verificationStatus.coding.code",
"min": 1,
"path": "Condition.verificationStatus.coding.code",
"mustSupport": true
}, {
"id": "Condition.verificationStatus.text",
"path": "Condition.verificationStatus.text",
"mustSupport": true
}, {
"id": "Condition.category",
"path": "Condition.category",
"comment": "Usage: this should always be set to \"problem-list-item\" when exporting the problem list, eg in Ontario Patient Summary.\r\n\r\nFDG - do we want this element? Maybe we just always use problem-list or go with what the EMRs return?\r\nEMRAPI = category\r\nMA: urn:telus:emr:ma:*:codetable:problem-category\r\nPSS: N/A\r\nMS: Not able to distinguish between an encounter diagnosis and a problem. Therefore NA\r\nCHR: ?\r\n\r\nThe categorization is often highly contextual and may appear poorly differentiated or not very useful in other contexts.",
"mustSupport": true
}, {
"id": "Condition.category.coding",
"max": "1",
"path": "Condition.category.coding",
"mustSupport": true
}, {
"id": "Condition.category.coding.system",
"min": 1,
"path": "Condition.category.coding.system",
"mustSupport": true
}, {
"id": "Condition.category.coding.code",
"min": 1,
"path": "Condition.category.coding.code",
"mustSupport": true
}, {
"id": "Condition.category.coding.display",
"path": "Condition.category.coding.display",
"mustSupport": true
}, {
"id": "Condition.category.text",
"min": 1,
"path": "Condition.category.text",
"mustSupport": true
}, {
"id": "Condition.severity",
"path": "Condition.severity",
"comment": "EMRAPI: severity\r\nMA: urn:telus:emr:ma:*:codetable:problem-severity\r\nPSS: N/A\r\nMS: N/A\r\nCHR: severity not attached to a diagnosis\r\n\r\nMA: Not supported for: surgical hx, obstetric, lifestyle, social hx, \r\nFHIR-->MA \r\nsevere--> severe/alert\r\nmoderate-->moderate\r\nmild-->mild\r\nnew code-->unknown\r\nN/A-->blank\r\n\r\nFDG - do we want a code for unknown, or just leave blank?Coding of the severity with a terminology is preferred, where possible.",
"mustSupport": true
}, {
"id": "Condition.severity.coding",
"max": "1",
"path": "Condition.severity.coding",
"mustSupport": true
}, {
"id": "Condition.severity.coding.system",
"min": 1,
"path": "Condition.severity.coding.system",
"mustSupport": true
}, {
"id": "Condition.severity.coding.code",
"min": 1,
"path": "Condition.severity.coding.code",
"mustSupport": true
}, {
"id": "Condition.severity.coding.display",
"path": "Condition.severity.coding.display",
"mustSupport": true
}, {
"id": "Condition.severity.text",
"path": "Condition.severity.text",
"mustSupport": true
}, {
"id": "Condition.code",
"min": 1,
"path": "Condition.code",
"comment": "Conformance Rule: The local code must always be specified where present. If a SNOMED. Encode, ICD-9 or ICD-10 code is present, this must also be sent.\r\n\r\nAlignment PS-ON: Must support SNOMED coding; this is very often not in the EMR; EMRs will send if there is an exact match on the code or if the EMR supports SNOMED\r\n\r\nAlignment PS-ON: n situations where the EMR cannot distinguish between no-known and no information about patient procedures, then the code for no information should be used. In the instance where a patient is KNOWN to have no procedures, the no-known code should be used.\r\n\r\nEMRAPI = code\r\n\r\nMA: ICD9-BILL, ICD9, free text, snomed, PIN (AB) code sets are too many and too large for mapping at the moment. Requires clinic input and maybe a health informatics specialist as well.\r\nPSS: http://hl7.org/fhir/sid/icd-9,10, also supports SNOMED. \r\nMS: ICD 10 or free text\r\n\r\n\r\nNot 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.",
"mustSupport": true
}, {
"id": "Condition.code.coding",
"path": "Condition.code.coding",
"mustSupport": true
}, {
"id": "Condition.code.coding.system",
"min": 1,
"path": "Condition.code.coding.system",
"mustSupport": true
}, {
"id": "Condition.code.coding.code",
"min": 1,
"path": "Condition.code.coding.code",
"mustSupport": true
}, {
"id": "Condition.code.coding.display",
"path": "Condition.code.coding.display",
"mustSupport": true
}, {
"id": "Condition.code.text",
"min": 1,
"path": "Condition.code.text",
"comment": "Usage Note: Text must always be sent to ensure there is no loss of data. Often there is additional text recorded in the EMR\r\n\r\nVery often the text is the same as a displayName of one of the codings.",
"mustSupport": true
}, {
"id": "Condition.bodySite",
"path": "Condition.bodySite",
"comment": "Conformance Rule: This is not currently supported; may be in future\r\n\r\nEMRAPI = BodySites\r\nMA: N/A\r\nPSS: N/A\r\nMS: N/A\r\n\r\nOnly 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](extension-bodysite.html). May be a summary code, or a reference to a very precise definition of the location, or both.",
"mustSupport": true
}, {
"id": "Condition.bodySite.coding",
"max": "1",
"path": "Condition.bodySite.coding",
"mustSupport": true
}, {
"id": "Condition.bodySite.coding.system",
"min": 1,
"path": "Condition.bodySite.coding.system",
"mustSupport": true
}, {
"id": "Condition.bodySite.coding.code",
"min": 1,
"path": "Condition.bodySite.coding.code",
"mustSupport": true
}, {
"id": "Condition.bodySite.text",
"path": "Condition.bodySite.text",
"mustSupport": true
}, {
"id": "Condition.subject",
"path": "Condition.subject",
"type": [ {
"code": "Reference",
"aggregation": [ "bundled" ],
"targetProfile": [ "http://telus.com/fhir/StructureDefinition/profile-patient-patientchart" ]
} ],
"mustSupport": true
}, {
"id": "Condition.subject.reference",
"min": 1,
"path": "Condition.subject.reference",
"mustSupport": true
}, {
"id": "Condition.subject.display",
"path": "Condition.subject.display",
"mustSupport": true
}, {
"id": "Condition.encounter",
"path": "Condition.encounter",
"comment": "Usage Note: If data is definitively tied to an encounter in the EMR, this reference should be sent. If there is no definitive reference, this should not be derived using date or other data points.\r\n\r\nThis 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\".",
"mustSupport": true
}, {
"id": "Condition.onset[x]",
"path": "Condition.onset[x]",
"comment": "EMRAPI: dateOfOnsetFD\r\n\r\nMA & CHR - only capture a date format and lifestage (eg adolescence) \r\nPSS: captures age, string\r\n\r\nAge is generally used when the patient reports an age at which the Condition began to occur.",
"mustSupport": true
}, {
"id": "Condition.abatement[x]",
"path": "Condition.abatement[x]",
"comment": "EMRAPI: dateOfAbatement\r\nPSS: Supports date, age and life stage\r\nMA & CHR - only capture a date format, \r\n\r\nThere 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.",
"mustSupport": true
}, {
"id": "Condition.recordedDate",
"path": "Condition.recordedDate",
"comment": "EMRAPI: dateFD\r\nPSS: Note date from database",
"mustSupport": true
}, {
"id": "Condition.recorder",
"path": "Condition.recorder",
"comment": "EMRAPI: not supported\r\n\r\nMA - Whoever created the profile via the task history\r\nPSS - NA\r\nMS - Active problem-> createdBy\r\n\r\nReferences 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.",
"mustSupport": true
}, {
"id": "Condition.recorder.reference",
"path": "Condition.recorder.reference",
"mustSupport": true
}, {
"id": "Condition.recorder.display",
"path": "Condition.recorder.display",
"mustSupport": true
}, {
"id": "Condition.asserter",
"path": "Condition.asserter",
"comment": "Usage Note: Not required for Patient Chart\r\n\r\nAlignment-PS-ON: If the asserter is known to be someone other than Composition.author, that information should be conveyed using this element. Otherwise, it may be left empty\r\n\r\nReferences 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.",
"mustSupport": true
}, {
"id": "Condition.asserter.reference",
"path": "Condition.asserter.reference",
"mustSupport": true
}, {
"id": "Condition.asserter.display",
"path": "Condition.asserter.display",
"mustSupport": true
}, {
"id": "Condition.stage",
"path": "Condition.stage",
"comment": "EMRAPI: disease stage\r\n\r\nDISCUSSION: NO EMR'S ARE SUPPORTED THIS TODAY. DO WE REMOVE THIS? FDG",
"mustSupport": false
}, {
"id": "Condition.note",
"path": "Condition.note",
"comment": "EMRAPI: notes\r\nThis is description for the PHR project. \r\nDISCUSSION REQUIRED - determine whether this should map to code.text as opposed to here AS THE definition for this is \"additional information\". Do we need a limit? Are the EMR's supporting this concept?\r\n\r\n\r\nNote: OMD would like this to be just additional details, not the description.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).",
"mustSupport": true
}, {
"id": "Condition.note.author[x]",
"path": "Condition.note.author[x]",
"mustSupport": true
}, {
"id": "Condition.note.time",
"min": 1,
"path": "Condition.note.time",
"mustSupport": true
}, {
"id": "Condition.note.text",
"path": "Condition.note.text",
"mustSupport": true
} ]
},
"baseDefinition": "http://hl7.org/fhir/StructureDefinition/Condition"
}