This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R3 R2 Structuredefinition-example.xml Raw XML ( canonical form ) Example of structuredefinition (id = "example") Raw XML Describes how the lab report is used for a standard Lipid Profile - Cholesterol, Triglyceride and Cholesterol fractions. Uses LOINC codes In this profile, mustSupport means that authoring systems must include the ability to report these elements, and processing systems must cater for them by either displaying them to the user or considering them appropriately in decision support systems. May be used to represent additional information that is not part of the basic definition of the resource. In order to make the use of extensions safe and manageable, there is a strict governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. there can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core simplicity for everyone. A human-readable narrative that contains a summary of the resource, and may be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it &quot;clinically safe&quot; for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety. Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope. This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. This is labeled as &quot;Is Modifier&quot; because applications need to take appropriate action if a report is withdrawn. The date and/or time that this version of the report was released from the source diagnostic service. 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. The subject of the report. Usually, but not always, this is a patient. However diagnostic services also perform analyses on specimens collected from a variety of other sources. This is not necessarily the source of the atomic data items - it's the entity that takes responsibility for the clinical report. The local ID assigned to the report by the order filler, usually by the Information System of the diagnostic service provider. Note: Usually there is one test request for each result, however in some circumstances multiple test requests may be represented using a single Pathology test result resource. Note that there are also cases where one request leads to multiple reports. This is often implicit or explicit in the requested test, and doesn't need to be specified if so. Details of the clinical information provided to the diagnostic service along with the original request. The section of the diagnostic service that performs the examination e.g. biochemistry, haematology, MRI. The diagnostically relevant time for this report - that is, the point in time at which the observations that are reported in this diagnostic report relate to the patient. If the diagnostic procedure was performed on the patient, this is the time it was performed. If there is 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. LOINC code includes &quot;direct&quot; LDL - does this mean LDL derived by measuring VLDL by ultracentrifugation? This panel includes both measured and calculated LDL. Nested report groups beyond the first level are not used often, but arise in structured pathology reports, and where there is more than one sensitivity assessment per discovered organism. A list of key images associated with this report. The images are generally created during the diagnostic process, and maybe directly of the patient, or of treated specimens (i.e. slides of interest). An imaging study is a list of images following a DICOM specification - only list one of these, or multiple images. It's not unusual for the lab to make some kind of interpretative comment on the set of results. Rich text representation of the entire result as issued by the diagnostic service. Multiple formats are allowed but they SHALL be semantically equivalent. Possible formats: text/html, text/plain, text/rtf, application/msword, application/pdf, application/rtf, application/vnd.oasis.opendocument.text, application/vnd.openxmlformats-officedocum ent.wordprocessingml.document. Application/pdf is recommended as the most reliable and interoperable in this context. </StructureDefinition> Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification. © HL7.org 2011+. FHIR DSTU (v0.4.0-4902) generated on Fri, Mar 27, 2015 00:23+1100. Links: What's a DSTU? | Version History | Specification Map | Compare to DSTU1 | | Propose a change