Design Comments: Free text entry of the human readable title of the document. It is this title of a document that is rendered. The title describes (but does not guarantee) the content of the document. The title is either a simple string (ST) or an XML content (ED) with limited NarrativeBlock markup which allows for stylesCode, super- and sub-script, line breaks and few other functions, but explicitly excludes tables, lists, etc.

Design Comments: xml title content model

Design Comments: The release date of the product labeling document.

Design Comments: Release date

Design Comments: Specifies confidentiality of the entire document. May be overriden for specific parts of the document. Values may be drawn from the Confidentiality vocabulary domain. Values other than those in the HL7 vocabulary domain (such as local codes) can also be used if necessary.

Design Comments: A code specifying the human language of character data in the product labeling document (whether in contents or attribute values). The values of the attribute are language identifiers as defined by the IETF (Internet Engineering Task Force) RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand, 1995 (http://www.ietf.org/rfc/rfc3066.txt), which obsoletes RFC 1766. Language is a contextual component of SPL, where the value expressed in the header holds true for the entire document, unless overridden by a nested value.

Design Comments: An optional globally-unique identifier, that remains constant across all document revisions that derive from a common original document.

Design Comments: An optional version number is incremented for each subsequent version of a document. For example, an original document is the first version of a document, and gets a new globally unique "id" value; it can also contain a new value for "setId" and a value of "versionNumber" set to equal "1".

Design Comments: A Participation clone that links a Document (or Section) to the Person who originated the document (or section, respectively), and, through AssignedEntity, also links to the Organization that owns the document. If desired, the author(s) of specific sections can be identified using the same structures as it is done for Document.author, which will then override the author(s) specified for the Document. (Note: In the SPL RMIM, this class is represented as a "shadow" of the author class for document, indicating that this participation is used by both the section and the document classes.

Design Comments: In some realms there may be a requirement to capture a legal authenticator of the labeling content. A legally authenticated document exists when an individual with the proper legal authority has attested to the accuracy of the document content. A document can be legally authenticated by zero or more people. Requirements for capture of information about a potential legal authenticator have not been defined to date. However, in the case where a local document is transformed into a SPL document for exchange, authentication only occurs on the local document and the fact of authentication is reflected in the exchanged SPL document. An SPL document can reflect the unauthenticated or authenticated state. The unauthenticated state exists when no authentication information has been recorded (i.e., it is the absence of being authenticated).

Design Comments: Represents reviewers, typically within the regulatory agency, where the AssignedEntity.representedOrganization provides details about the organization (e.g., the regulatory agency) for which the verifier is working. (It is possible to indicate reviewers of a different organization, such as the manufacturer itself, the representedOrganization specification will tell what level of review the Verifier participation represents.)

Design Comments: One or more specific relationships between documents. These relationships rely on document identifiers described above.

Design Comments: Connects the Document with its content structure.

Design Comments: Possible persons and organizations involved in the creation and review of a product labeling document are associated with the document as Participations. Participations may include document originators (authors), legal authenticators, organizations that own the marketing authority for the product, and product labeling reviewers at the regulatory agency. Participants are capable of and accountable for their independent decisions. All of these participants are optional in the SPL model but could be constrained to be required for a given realm. Information about participants is captured by means of clones of several interrelated RIM classes: Participations, Roles, and Entities. In general, an Entity (person or organization) playing a particular Role (in this case, AssignedEntity), participates in an Act (e.g., a document). It is the Participation clone that identifies the type of participant. The type of Participation (e.g., author) is indicated by a code. The Role played by the Entity establishes that entity's competency or authority to participate as indicated. For example, a person participating as an author of a label is only authorized to do so if assigned by the organization responsible for authorship of the label. The way in which a Person or Organization is participating in the document is specified by the typeCode attribute on the relevant Participation class clone. While the nature of the participation may be suggested by the XML element name, the typeCode values are the definitive indication.

Design Comments: The AssignedEntity.assignedPerson, provides the details (e.g., name) about the person participating in the document as an author. Because assignedPerson is optional, it is possible to capture only information about the representedOrganization.

Design Comments: The AssignedEntity.representedOrganization provides details about the organization (the manufacturer or owner of the marketing authority) for which the author is working. This specifies the organization from which the document originates and that is in charge of maintaining the document (e.g., the owner of the marketing authority or a contractor in charge of the labeling), commonly called the manufacturer.

Design Comments: WHAT? NO DESCRIPTION?

Design Comments: WHAT? NO DESCRIPTION?

Design Comments: e.g., manufacturer, packer, printer

Design Comments: B - remove from published label

Design Comments: WHAT? NO DESCRIPTION?

Design Comments: Specifies the kind of activity assigned to the related organization.

Design Comments: WHAT? NO DESCRIPTION?

Design Comments: WHAT? NO DESCRIPTION?

Design Comments: Document the existence of a signature if the value for signatureCode is "S" (for "signed"). Authentication involves signing of the document either manually or electronically by the responsible individual. The electronic signature mechanism that uses the RIM attributes Participation.signatureText and Role.certificateText, is currently not included in SPL.

Design Comments: Possible persons and organizations involved in the creation and review of a product labeling document are associated with the document as Participations. Participations may include document originators (authors), legal authenticators, organizations that own the marketing authority for the product, and product labeling reviewers at the regulatory agency. Participants are capable of and accountable for their independent decisions. All of these participants are optional in the SPL model but could be constrained to be required for a given realm. Information about participants is captured by means of clones of several interrelated RIM classes: Participations, Roles, and Entities. In general, an Entity (person or organization) playing a particular Role (in this case, AssignedEntity), participates in an Act (e.g., a document). It is the Participation clone that identifies the type of participant. The type of Participation (e.g., author) is indicated by a code. The Role played by the Entity establishes that entity's competency or authority to participate as indicated. For example, a person participating as an author of a label is only authorized to do so if assigned by the organization responsible for authorship of the label. The way in which a Person or Organization is participating in the document is specified by the typeCode attribute on the relevant Participation class clone. While the nature of the participation may be suggested by the XML element name, the typeCode values are the definitive indication.

Design Comments: Document the existence of a signature if the value for signatureCode is "S" (for "signed"). Verification may involve signing of the document either manually or electronically by the responsible individual. The electronic signature mechanism that uses the RIM attributes Participation.signatureText and Role.certificateText, is currently not included in SPL.

Design Comments: Possible persons and organizations involved in the creation and review of a product labeling document are associated with the document as Participations. Participations may include document originators (authors), legal authenticators, organizations that own the marketing authority for the product, and product labeling reviewers at the regulatory agency. Participants are capable of and accountable for their independent decisions. All of these participants are optional in the SPL model but could be constrained to be required for a given realm. Information about participants is captured by means of clones of several interrelated RIM classes: Participations, Roles, and Entities. In general, an Entity (person or organization) playing a particular Role (in this case, AssignedEntity), participates in an Act (e.g., a document). It is the Participation clone that identifies the type of participant. The type of Participation (e.g., author) is indicated by a code. The Role played by the Entity establishes that entity's competency or authority to participate as indicated. For example, a person participating as an author of a label is only authorized to do so if assigned by the organization responsible for authorship of the label. The way in which a Person or Organization is participating in the document is specified by the typeCode attribute on the relevant Participation class clone. While the nature of the participation may be suggested by the XML element name, the typeCode values are the definitive indication.

Design Comments: A reference to another Document. The set of attributes in this class has the purpose of identifying the related document by identifiers only. To learn the contents of the related document, one needs to retrieve that document by the identifier(s) provided here.

Design Comments: Can be used to support conventional revision numbering in addition to the explicit links to the ancestor versions using the RelatedDocument.id. One example scenario is: The new replacement Document gets a new globally unique id value, and uses the same value for setId as the RelatedDocument being replaced, and increments the value of versionNumber. The RelatedDocument is then considered superseded, but is still retained in the system for historical reference.

Design Comments: Can be used to support conventional revision numbering in addition to the explicit links to the ancestor versions using the RelatedDocument.id. One example scenario is: The new replacement Document gets a new globally unique id value, and uses the same value for setId as the RelatedDocument being replaced, and increments the value of versionNumber by 1. (If used, the versionNumber will be incremented by one when a document is replaced, but can also be incremented more often to meet local requirements.) The parent document is considered superseded, but is still retained in the system for historical reference.

Design Comments: Represents a document body that is in some format other than SPL XML (e.g., a PDF document.)

Design Comments: Represents an XML document body that is comprised of one or more Sections.

Design Comments: Connects the top-level sections with the Document.

Design Comments: Provides a means of organizing the product labeling content into the commonly understood sections generally found in these documents. The Section class is a container used to wrap other containers. A section element can occur in the StructuredBody, or can be nested within another Section. A section can also be replaced by another section. A section can contain nested section elements or other structures such as observations. The SPL section contains the actual product labeling text and graphics to be rendered. There are three logical components of the SPL section: General section information. Information about participants in creation of the section. The actual product labeling text and graphics to be included in the label section (and which will be rendered), along with structured data elements (that may be used for machine processing). The mechanisms to uniquely identify a specific product labeling section, to indicate a standard type code and name for the section, and to include a local name for the section (e.g. realm or language specific name; possibly constrained by the type code) are all included. Note the section element contains an optional local identifier (represented as an XML ID attribute) that can serve as the target of an XML reference.

Design Comments: Interval of time, specifying the section origination time, i.e., when the section was created.

Design Comments: Can override the confidentialityCode attribute in Document.

Design Comments: Specifies the human language of character in the same way that Document.languageCode works. Language is a contextual component of SPL, where the value expressed in the header holds true for the entire document, unless overridden by a nested value

Design Comments: Links the Medicine (as a Manufactured Product) to be the subject of a Section in which it is described.

Design Comments: A Participation clone that links a Document (or Section) to the Person who originated the document (or section, respectively), and, through AssignedEntity, also links to the Organization that owns the document. If desired, the author(s) of specific sections can be identified using the same structures as it is done for Document.author, which will then override the author(s) specified for the Document. (Note: In the SPL RMIM, this class is represented as a "shadow" of the author class for document, indicating that this participation is used by both the section and the document classes.

Design Comments: An explicit representation of the relationships between versions of sections. Whether and how this information is used depends on the document management system in use. A replacement section replaces an existing section.

Design Comments: Connects a section with one of its sub-sections.

Design Comments: The relationship which links the Highlight to the Section which is being excerpted by the Highlight.

Design Comments: Allows narrowing the subject of the comment down to a specific fragment inside the Section.text.

Design Comments: A Role of the Product (or Medicine) as a ManufacturedProduct is taken as the principal role for the SPL product model.

Design Comments: A section that is related to the section it replaces through the replacementOf relationship (an ActRelationship clone).

Design Comments: Holds multi-medial content, that is logically a part of a product labeling document, but may be stored outside the document and incorporated by reference. Multimedia that is integral to a document, and part of the attestable content of the document, requires the use of observationMedia. (An example might be the molecular structure for a drug in a drug product labeling document.) Multimedia that is simply referenced by the document and not an integral part of the document can use linkHtml. The XML ID attribute on the observationMedia element is used by the renderMultiMedia element (of the Narrative Block) to identify the media to be rendered.

Design Comments: Provides a means of organizing the product labeling content into the commonly understood sections generally found in these documents. The Section class is a container used to wrap other containers. A section element can occur in the StructuredBody, or can be nested within another Section. A section can also be replaced by another section. A section can contain nested section elements or other structures such as observations. The SPL section contains the actual product labeling text and graphics to be rendered. There are three logical components of the SPL section: General section information. Information about participants in creation of the section. The actual product labeling text and graphics to be included in the label section (and which will be rendered), along with structured data elements (that may be used for machine processing). The mechanisms to uniquely identify a specific product labeling section, to indicate a standard type code and name for the section, and to include a local name for the section (e.g. realm or language specific name; possibly constrained by the type code) are all included. Note the section element contains an optional local identifier (represented as an XML ID attribute) that can serve as the target of an XML reference.

Design Comments: An ObservationMedia class contains an optional instance identifier.

Design Comments: Detailed plain-text for those disabled to perceive the original media.

Design Comments: An abstract or excerpt of a single topic discussed in a single section or sub-section. This abstract is presented in the form of a short text fragment as well as with structured information. The highlights are targeted at prescribers and judiciously chosen to present the most important information the prescriber needs to know in order to prescribe a medicine safely and effectively. The Highlights can be assembled to form a short abstract of the comprehensive prescribing information as a "quick reference" for the prescriber. All structured information to specify the clinical use of the drug is connected through the highlights element. The practical purpose of this construct is to focus the coding of information on the most important points guiding the appropriate use of the medicine without attempting to code nuances which would not be part of a concise summary. It also facilitates review of the structured information for correctness. Specific information structures cover the general topics: Indication, Dosage and Administration, Adverse Events, Interactions, Contraindications and other Cautions or Warnings, as well as Monitoring guidelines.

Design Comments: The relationship which links the SubstanceAdministration to the Highlight as its subject matter.

Design Comments: Since the clinical medication module is all about appropriate and safe use of the drug, this "use" of the drug, i.e., the central SubstanceAdministration is the pivot of all structured data of the highlights. This SubstanceAdministration is a definition and defines the key data of a proper use of the medicine.

Design Comments: Timing patterns (e.g., twice a day, every 8 hours, etc.) and timing boundaries (e.g., for 10 days) can be specified for the main SubstanceAdministration and its component SubstanceAdministration. In addition, SubstanceAdministration.effectiveTime can give general timing constraints, such as, "give 1 hour before meal". However, more specific clinical situations in which to give the medicine (e.g., "15 minutes before exercise" or "before sexual intercourse", etc.) must be specified using preconditions to a ClinicalSituationCriterion.

Design Comments: Amount of the medicine given at one single administration. The medicine in terms of which this dose is specified can be clarified using the consumable participation which leads either to the Medicine or to an ActiveIngredient. This can be specified by means of reference to the ManufacturedProduct.id or the ActiveIngredient.id, without requiring repeating the detail of these roles and entities playing the roles.

Design Comments: A participation which connects to the material which in terms of which the dose is specified. This connects either to the Medicine or to an ActiveIngredient. The referenced material is elsewhere specified in the label and at here only needs to be referred to using the ManufacturedProduct.id or the ActiveIngredient.id.

Design Comments: Dose unit must be specified when not dosing based on the specific formulation (e.g., tablet, actuation) otherwise the strength is not known.

Design Comments: The indication can be further specified to express an objective as to what the treatment should accomplish. For instance, if the goal of the treatment is absence of acute asthma attacks, the maintenance goal can describe this. This is used to allow the treatment effect to be coded and still keep the indication a simple code that is comparable with actual patient problem list data. For instance, the indication would be "asthma" and the maintenance goal would be "no bronchiospasm" to indicate "prevention of bronchiospasm in patients with asthma".

Design Comments: An ActRelationship of type "reason" representing the indication of the substance administration by linking to an observation criterion. The typeCode of the reason ActRelationship can be further refined to indicate different motivations, such as therapeutic reason (as a remedy), prophylactic reason (as a means of prevention), or as diagnostic reason (something done to diagnose the disease.

Design Comments: An ActRelationship that links ClinicalSitutaionCriteria with the pivotal SubstanceAdministration. A ClinicalSituationCriterion is a choice of either ObservationCriterion, SubstanceAdministrationCriterion or general ActCriterion. These preconditions further limit the indication to a specific population or other clinical situation. Multiple preconditions can be specified. When multiple criteria are specified, they are logically conjoined (AND), i.e., they must all hold true.

Design Comments: Links a SubstanceAdministation to a specified kind of Observation which is used for calculated dosage. An example would be: <substanceAdministration> ... <maxDoseQuantity> <numerator xsi:type="EXPR_PQ" unit="mg"> <expression mediaType="application/hl7-factor+xml"/> <factor value="57" unit="mg/kg"> <factor>bodyMass</factor> </expression> >/numerator> <denominator value="1" unit="d"/> </maxDoseQuantity> ... <consumable> <activeIngredient ... /> </consumable> <derivedFrom> <localVariableName>bodyMass</localVariableName> <monitoringObservation> <code code="29463-7" codeSystem="&LOINC;" displayName="BODY WEIGHT:MASS:PT:^PATIENT:QN"/> </monitoringObservation> </derivedFrom> </substanceAdministration> Note: the EXPR data type is forthcoming in the release 2 of the HL7 data type specification under ballot at the same time as release 4 of this specification is being balloted. Also note, the unit attribute on the maxDoseQuantity numerator indicates the unit of the expression value, i.e., it guarantees that the expression evaluates to a physical quantity in this specified unit.

Design Comments: If dosage regimens should vary, this can be specified by component SubstanceAdministrations. In that case, the main SubstanceAdministration must not have a doseQuantity of itself, and instead the subordinate component SusbtanceAdministration would carry the doseQuantity for each different dose. This is used for example, to specify a loading dose, or a tapering dose. A regimen with a loading dose is specified using two components, the first representing the initial dose, with repeatNumber = 1 (meaning "once") or any other limitation in number or time. That first component would be followed by a second component that can repeat for the rest of the duration of the therapy. For tapering doses, the first component would represent the duration of the therapy and the second (or following) components specify the tapering-off scheme.

Design Comments: An ActRelationship connecting the SubstanceAdministration with an Issue a Characteristic. For example, adverse effects, interactions, contraindications and other issues of caution are connected as Issue; pharmacokinetic properties such as half life or whether or not this administration would have systemic effect can be described using a Characteristic. Either way the description is specific to this mode administration (route, dose, etc.)

Design Comments: A therapeutically active ingredient (player) in a mixture (scoper), where the mixture is typically a manufactured pharmaceutical. This class is being deprecated since release 4 of this specification and replaced by the Ingredient class, with the classCode active ingredient (ACTI) and specializations. This class is deprecated since release 4 of this specification. Use the Ingredient class instead with classCode specified as active ingredient (ACTI).

Design Comments: Special ingredient classesdeprecated since SPL R4. INGR classCode specilai- zations, IACT, ACTI and ACTIB, ACTIM, ACTIR) retain the distinction.

Design Comments: Relates an ingredient substance (player) to the product (scoper). Ingredients can be specified for medicines or other products, including devices, but they always mean the same thing: a material (here: chemical substance) in the make-up of the main product, not a structural part or content, and not a material added into a device for operation. For medicines and food this is obvious. For devices, an example for ingredient would be latex in a chest tube (but not an inhalant in a nebulizer device). This class supercedes the two special classes ActiveIngredient and InactiveIngredient from previous revisions of this specification.

Design Comments: A Role of the Product (or Medicine) as a ManufacturedProduct is taken as the principal role for the SPL product model.

Design Comments: See Ingredient.id.

Design Comments: Generalization elements to specify a classification to the Medicine, Substance and ActiveMoiety. For example, one can specify any or all of (a) cellular/molecular action (e.g., Ca-channel blocker); (b) physiologic effect (e.g., vasodilator); and (c) molecular/chemical class (e.g. aminopenicillin).

Design Comments: Used when the ingredient strength is expressed in terms of a reference substance, which is specified by the ingredient classCode ACTIR (active ingredient where strength is specified in terms of a reference drug.) For example, it is customary for beta-adrenergic receptor inhibitors (beta-blockers, e.g., propranolol) to specify strengths in terms of the precise ingredient. This has led to variants of the same active moiety to be dosed in terms of the precise ingredient used when that active moiety first appeared on the market. For example, metoporolol tartrate was first, its strength was specified in terms of precise ingredient, and hence, for easier comparison of doses, the subsequent metoprolol succinate was specified in terms of equivalent metoprolol tartrate.

Design Comments: Links to the molecule or ion that is responsible for the intended pharmacological action of the drug substance. Note that if a molecule (e.g., salt) dissociates into moieties (ions) where each ions could be considered responsible for the (potentially different) pharmacological action of the drug, one should use multiple activeMoieties, one for each ion.

Design Comments: A ratio specifying the amount of the precise ingredient (numerator) that is equivalent to an amount of the reference substance (denominator). For example, 23.75 mg (numerator) of metoprolol succinate equivalates 25 mg (denominator) of metoprolol tartrate.

Design Comments: qty of ingredient over that of reference substance

Design Comments: A ratio specifying how much of the active moiety (numerator) is in the precise ingredient compound (denominator). For example, 5.6 mg (=denominator) betaxolol hydrochloride (compound) contain 5 mg (=numerator) of betaxolol (moiety).

Design Comments: amount of active moiety in ingredient

Design Comments: Generalization elements to specify a classification to the Medicine, Substance and ActiveMoiety. For example, one can specify any or all of (a) cellular/molecular action (e.g., Ca-channel blocker); (b) physiologic effect (e.g., vasodilator); and (c) molecular/chemical class (e.g. aminopenicillin).

Design Comments: A specificiation of a kind of medicine, food material, or any product for the purpose of (a) describing a specific product with classification categories and (b) refering to a kind of product or material for describing drug-drug interactions or adjunct treatments. The classifying category may refer to any of various classifications and abstractions of products by any aspect, including, mechanism of action category, physiologic effect category, chemical structure category, or "clinical drug" category. This may also be used to represent a specific material or an ingredient when specifying drug-drug interactions or adjunct treatments. Note: this class supercedes the special class PharmaceuticalClass since release 4 of this specification for all uses. This class has existed since release 2, but had been used exclusively for specifying drug-drug-interactions and adjunct treatments, where it was essentially a reference to another PharmaceuticalClass. Otherwise both classes had the same constraints and, indeed, the same meaning.

Design Comments: A generalization of Medicine, Substance and ActiveMoiety, can specify any or all of (a) cellular/molecular action (e.g., Ca-channel blocker); (b) physiologic action (e.g., vasodilator); and (c) molecular/chemical class (e.g. aminopenicillin). Note: since release 4 of this specification this class will be deprecated. Use MaterialKind instead, which has existed since release 2 of this specification and which has the same constraints and, the same meaning, relates directly to is use in specifying drug-drug-interactions and adjunct treatments, and is named less specifically for medications such that it can be used for classifying devices and other products as well.

Design Comments: PharmaceuticalClass special name deprecated in R4 for functionally equivalent MaterialKind.

Design Comments: An identifier to establish mostly internal references as a SubstanceAdministration.consumable for the unambiguous specification of dose quantity without having to repeat the entire content. Example: <section ... DESCRIPTION ...> <subject> <manufacturedProduct> <manufacturedMedicine> <activeIngredient> <id root="60a4db80-573d-11db-b0de-0800200c9a66"/> <quantity .../> <activeIngredientSubstance .../> </activeIngredient> </manufacturedMedicine> </manufacturedProduct> </subject> </section> ... <section ... DOSAGE AND ADMINISTRATION ...> <excerpt> <highlight> <substanceAdministration> ... <consumable> <activeIngredient> <id root="60a4db80-573d-11db-b0de-0800200c9a66"/> </activeIngredient> </consumable> ... </substanceAdministration> </highlight> </excerpt> </section>

Design Comments: B - trade secret

Design Comments: Links the Product with Characteristics, Policies and Approvals.

Design Comments: Labels a product, part, or package as the unitary item for uniform billing standards. For example, on the product in the form of a tablet to indicate that the product is billed by the tablet (each); to a product in cream form to indicate it is billed volume or mass; on a vial or sachet package to indicate it is billed by vial or sachet (each). NOTE: This item is added in SPL R4 membership as an INFORMATIVE extension for the purpose of pilot testing.

Design Comments: A role representing the relationship between the medicine and its package.

Design Comments: Links the product as a component of a system or assembly. The system may be a defined product labeled elsewhere or it may be an anonymous product which is only used to specify that additional parts are also needed to make that system complete. For example, a hose system used within several intravenous infusion pump systems would refer to those pump systems but would not describe the pump systems in detail. On the other hand, the label for one of those pumps (not including the hose system) would have to refer to the hose sytem in a similar manner. The line: <manufacturedProduct> <code ... /> <name>FlexiFuse Line</name> <asPartOfAssembly> <wholeProduct> ... no code specified here ... <part> <partProduct> <code ... /> <name>PreciFuse Pump</name> </partProduct> </part> </wholeProduct> </asPartOfAssembly> </manufacturedProduct> The pump itself: <manufacturedProduct> <code ... /> <name>PreciFuse Pump</name> <asPartOfAssembly> <wholeProduct> ... no code specified here ... <part> <partProduct> <code ... /> <name>FlexiFuse Line</name> </partProduct> </part> </wholeProduct> </asPartOfAssembly> </manufacturedProduct> Notice that in either case the assembly itself remains anonymous because it has not a defined product code. Notice also that the pump itself does not come with the line, and hence the line cannot be described as a component of the pump. However, let's assume that that same FlexiFuse line is also a part of kit comprised of the portable version of the PreciFuse Pump product and 10 such lines. In that case the kit that is sold under a specific registered product code would also be specified as an assembly with a code. In that case the other parts of the assembly need not be described: <manufacturedProduct> <code ... /> <name>FlexiFuse Line</name> <asPartOfAssembly ... /> <asPartOfAssembly ... /> <asPartOfAssembly ... /> <asPartOfAssembly> <wholeProduct> <code .../> <name>PreciFuse PorterPump Kit</name> </wholeProduct> </asPartOfAssembly> </manufacturedProduct> and the the kit would be described as: <manufacturedProduct> <code ... /> <name>PreciFuse PorterPump Kit</name> <part> <quantity value="1"/> <partProduct> <code .../> <name>PreciFuse PorterPump</name> <formCode ... KIT .../> </partProduct> </part> <part> <quantity value="10"/> <partProduct> <code .../> <name>FlexiFuse Line</name> </partProduct> </part> </manufacturedProduct>

Design Comments: Generalization elements to specify a classification to the Medicine, Substance and ActiveMoiety. For example, one can specify any or all of (a) cellular/molecular action (e.g., Ca-channel blocker); (b) physiologic effect (e.g., vasodilator); and (c) molecular/chemical class (e.g. aminopenicillin).

Design Comments: Specifies the original innovator product which is the reference product for a generics product. This class allows referencing the original innovator or reference product as a MaterialKind on the scoper-end of this role, and a code specifying precisely in what way this product is bio-equivalent to the reference product (equivalence evaluation code).

Design Comments: Relates a multiple-component product (scoper) to one of its components (player). For example, a contraceptive product to its separate estrogen and progestin tablets in a single container. The quantity of each part is represented as the Part.quantity. (The quantity of the parent Medicine would be "1" for a single wheel containing both medications in this example.)

Design Comments: Relates an ingredient substance (player) to the product (scoper). Ingredients can be specified for medicines or other products, including devices, but they always mean the same thing: a material (here: chemical substance) in the make-up of the main product, not a structural part or content, and not a material added into a device for operation. For medicines and food this is obvious. For devices, an example for ingredient would be latex in a chest tube (but not an inhalant in a nebulizer device). This class supercedes the two special classes ActiveIngredient and InactiveIngredient from previous revisions of this specification.

Design Comments: The product, e.g., a medicine or device or food item, that is the primary unit which is manufactured and the object of an intended administration described in the label, and that is not just packaging. Examples are tablet, capsule, solution for injection, powder, device. Conversely, vial, bottle, pouch, and carton are containers, which though sometimes necessary for handling of the product, are not themselves administered, but emptied into some other container, or used with an injection or inhalation device. Notice, even though a capsule can be considered a container holding granules, a capsule is still considered primary Product not PackagedProduct, because the capsule is the unit normally intended for administration, and so the capsule is the medicine. In this way, a solution packaged in an administration unit, such as a dragee or a prefilled syringe may be considered primary Product rather than PackagedProduct, if it is intended to be applied completely as one unit, and not subdivided. This requires that the ingredients of such products are specified as a total amount per complete application rather than as a concentration. Examples for devices are chest tube, wound dressing, dental chair, ventilator machine. Devices are any kind of product used for medical purposes or in conjunction with medical services, including, but not limited to, direct use for therapeutic purposes (e.g., orthopedic screw), diagnostic purposes (e.g. EKG machine), usage as applicator devices for the administration of medicines (e.g., syringes), or as tools (e.g., dental chair). A kit is a product that contains multiple parts administered together or used together in some intricate way. Some of the parts of a kit may be medicinal substances (medicines), and others may be devices, e.g., applicator devices. Kits are described as a primary product of form code meaning "kit" with parts.

Design Comments: The medicine is the primary unit which is manufactured and the object of an intended substance administration and is not just packaging. Examples are tablet, capsule, solution for injection, powder. Conversely, vial and bottle are containers, which though necessary for handling of the medicine, are not administered to the patient, but emptied into some other solution, or used with an injection or inhalation device. Notice, even though a capsule can be considered a container holding granules, capsules are still considered primary Medicines not PackagedMedicines, because the capsule is the unit normally intended for administration, and so the capsule is the medicine. In this way, a solution packaged in an administration unit, such as a dragee or a prefilled syringe may be considered primary Medicines rather than PackagedMedicines, if it is intended to be applied completely as one unit, and not subdivided. This requires that the ingredients of such medicines are specified as a total amount per complete application rather than as a concentration. A kit, which is a collection of parts which are administered together or used in some intricate way are sometimes also described as primary Medicine with parts. The key criterion is that the kit as a whole is considered the object of a SubstanceAdministration.

Design Comments: Labels a product, part, or package as the unitary item for uniform billing standards. For example, on the product in the form of a tablet to indicate that the product is billed by the tablet (each); to a product in cream form to indicate it is billed volume or mass; on a vial or sachet package to indicate it is billed by vial or sachet (each). NOTE: This item is added in SPL R4 membership as an INFORMATIVE extension for the purpose of pilot testing.

Design Comments: A role representing the relationship between an (inner) package and its larger (outer) package. This is the standard way to describe "intermediate" packaging, which regularly occur with non-solid medicines. For example, a solution for injection (Medicine) is packaged in a vial (a primary package or sometimes called "intermediary" package) and then several such vials are packed in a carton. Notice that the vial is not the Medicine, it is the content in the vial which is the medicine; the vial is just a necessary packaging to hold the liquid.

Design Comments: A product in a container, or package.

Design Comments: A medicine in a container, or package. Thes class by this name is deprecated. Use the equivalent class named PackagedProduct instead.

Design Comments: Labels a product, part, or package as the unitary item for uniform billing standards. For example, on the product in the form of a tablet to indicate that the product is billed by the tablet (each); to a product in cream form to indicate it is billed volume or mass; on a vial or sachet package to indicate it is billed by vial or sachet (each). NOTE: This item is added in SPL R4 membership as an INFORMATIVE extension for the purpose of pilot testing.

Design Comments: Defines the standard way of billing for this product. The billing unit definition is associated through an IndirectTarget participation [to be refined with a more specific type ValuedUnitItem] with the product, part, or package which serves as the standard unitary item for billing purposes. NOTE: This material is INFORMATIVE in SPL R4 for the purpose of pilot testing.

Design Comments: This is INFORMATIVE only. See text.

Design Comments: A code specifying in what way the equivalent entity (player) is considered equivalent to is reference entity (scoper). This is used to reference materials submitted from another source (e.g., repackagers, OTC, etc.) Examples: no known or suspected bioequivalence problems; potential bioequivalence problems have been resolved with evidence supporting bioequivalence; bioequivalence problems have not been fully resolved. See also: U.S. Food and Drug Administration. Center for Drug Evaluation and Research. Approved drug products with therapeutic equivalence evaluations. Available from: http://www.fda.gov/cder/ob/docs/preface/ecpreface.htm.

Design Comments: A ratio specifying the amount of a part (numerator) in an amount (denominator) of the whole Medicine. It is important to note that as all Role quantities the numerator and denominator stand for the amount of the exact kind of entity specified as the part and whole respectively, and not something else. For example, when the medicine is a kit with tablets being the parts, the numerator numbers the amount of tablets of the same kind in the kit. However, if the kit consists of 2 vial-packaged liquids, each vial holding 3 mL, the part quantity specifies the total amount of this liquid (e.g. 6 mL), not 2 (vials). Thus all quantities have the exact same interpretation which is important to draw any quantitative inference from these relationships (e.g. "how much ingredient is in a package?")

Design Comments: Links the Product as part of a kit or assembly with Characteristics, Policies and Approvals.

Design Comments: Links a Medicine as a ManufacturedProduct with the SubstanceAdministration definition representing the labeled route.

Design Comments: Labels a product, part, or package as the unitary item for uniform billing standards. For example, on the product in the form of a tablet to indicate that the product is billed by the tablet (each); to a product in cream form to indicate it is billed volume or mass; on a vial or sachet package to indicate it is billed by vial or sachet (each). NOTE: This item is added in SPL R4 membership as an INFORMATIVE extension for the purpose of pilot testing.

Design Comments: A record of the approval of a Medicine (product) or Substance, signifying that a substance or product is approved for the use specified in the SPL data.

Design Comments: A code-value pair specifying descriptive properties of the medicine, such as color, shape, imprints, etc. The code has a data type of CE and the value has a data type of ANY, which allows codes or numeric values to be specified.

Design Comments: Specifies if and when the product is marketed.

Design Comments: The purpose of this element is to capture the controlled substance classification or schedule of a drug (e.g., DEA schedule in the U.S.).

Design Comments: The medicinal product oversight authority.

Design Comments: The counry name, if not coded.

Design Comments: country name if not coded

Design Comments: A text field that allows entry of free text description of the characteristics.

Design Comments: The status of the marketing activity, i.e., product is actively marketed (active), product has been withdrawn from the market (aborted).

Design Comments: active: curently marketed; aborted: withdrawn off the market

Design Comments: Time range (start - end) in which a product was marketed.

Design Comments: The only purpose of the SubstanceAdministration class in the Medicine model is to represent the labeled route.

Design Comments: Links the product instance with a product event.

Design Comments: Links to the manufacturer site or establishment having produced this particular lot or instance.

Design Comments: Relates a product instance to its lot of which it is an individual member, subset or portion. A product instance can only relate to one lot. In case where a product is a mix of multiple lots use the ingredient role instead to constitute a mixed lot. This mixed lot can then be further portioned into sub-lots. Either way, a member or portion of a lot still only has one parent lot.

Design Comments: Connects a product instance with a MaterialKind specifying what kind of product it is. This is used when listing a ProductInstance along with its Part or Ingredient instances. The MaterialKind.code will then cite the Product code of which this Part or Ingredient material is an instance.

Design Comments: Relates a multiple-component product instance (scoper) to one of its component instances (player) consistent with the definition of Part linking the product (kind) with its part-product (kinds).

Design Comments: Relates an ingredient instance (player) to the product instance (scoper). See the Ingredient class (from Product) about the general meaning. Specifically for product instances, ingredients may be the constituents of a mixed lot, even if the ingredient are of the same kind.

Design Comments: Relates a product lot (or batch) to an instance or portion of it. This role would typically appear more than once to list all the members of a product lot. These members of a product lot may be individual serialized portions filled into a container (e.g., bottle or ampoule) for retail, or larger batches shipped to other manufacturers, wholesalers or repackers. Either way, each portion can be individually identified, such as with the serial number which may or may not be printed on the package.

Design Comments: A product instance is (a) an individual product instance, i.e., an individually identified thing with a serial number; (b) a product lot, i.e., a set of things of the same kind (e.g., 1000 tablets) or an amorphous mass (e.g., 100 L of a liquid raw material), or (c) any subset, member, or portion of a product lot. The distinction between an individual thing and a lot is made in the quantity attibute, which is set to 1 (one) for individual items, or any number e.g., 1000 or amount 100 L for sets of things or amorphous masses respectively.

Design Comments: An individually ("serialized") device of the labeled kind, and/or a production lot for multiple equal products, considered devices, even if they are not individually distinguished. This is used for the purpose of listing and tracking individual device instance. The main distinction between DeviceInstance and the more generic ProductInstance is that the DeviceInstance allows specifying manufactuere model name/number and software version number.

Design Comments: Links the product instance with a product event.

Design Comments: A significant event in the life of a product instance, including, but not limited to recall, refurbishing, salvaging, and maintenance procedures.

Design Comments: Code specifying the nature of the product event, e.g., recall, refurbishing, salvaging.

Design Comments: e.g. recall, refurbished, salvaged

Design Comments: The time when the event occurred. Often specified only to the precision of a date.

Design Comments: Links the product instance with a product event.

Design Comments: Links the product instance with a product event.

Design Comments: The amount of product comprised by this product instance. An individually identified thing with a serial number always has quantity set to 1 (one). A product lot, i.e., a set of things of the same kind has quantity set to the lot size. E.g., 1000 tablets or 100 L of a liquid raw material. Constraint: the dimension of this attribute must be the same as the dimension of the package quantity numerator and of the ingredient quantity denominator.

Design Comments: lot size, 1 = individual instance

Design Comments: An interval of time specifying the begin and end of the time range in which the product is considered safe and effective for use. If only an expiration date is known, this is represented in the high boundary of the interval.

Design Comments: lot size, 1 = individual instance

Design Comments: An interval of time specifying the begin and end of the time range in which the product is considered safe and effective for use. If only an expiration date is known, this is represented in the high boundary of the interval.

Design Comments: The model number or designation of minor production variants which do not affect the properties of the device as labeled. For example, the same device might come with silver or black bezel and may have different model number designations by the manufacturer. This number is not a controlled identifier but has meaning in the context of the product and its manufacturer.

Design Comments: The software or firmware version number installed in this product instance.

Design Comments: software version

Design Comments: The principle form of a product, such as dosage form of a medicine. Values may be drawn from the MaterialForm HL7 vocabulary table or from other external code value sources. Notice the difference between an (Administered) Medicine and a PackagedMedicine. Both have formCodes. A box or vial is usually not a medicine Product.formCode but a PackageProduct.formCode, unless the entire box or the entire vial is meant for direct administration as a single unit.

Design Comments: dosage form

Design Comments: A therapeutically active ingredient (player) in a mixture (scoper), where the mixture is typically a manufactured pharmaceutical. This class is being deprecated since release 4 of this specification and replaced by the Ingredient class, with the classCode active ingredient (ACTI) and specializations. This class is deprecated since release 4 of this specification. Use the Ingredient class instead with classCode specified as active ingredient (ACTI).

Design Comments: Special ingredient classesdeprecated since SPL R4. INGR classCode specilai- zations, IACT, ACTI and ACTIB, ACTIM, ACTIR) retain the distinction.

Design Comments: Relates a mixture (scoper) to an ingredient (player), where the ingredient is not considered the ActiveIngredient. This class is being deprecated since release 4 of this specification, and replaced by the Ingredient class, with the classCode active ingredient (ACTI) and specializations. This class is deprecated since release 4 of this specification. Use the Ingredient class instead with classCode specified as inactive ingredient (IACT).

Design Comments: See Ingredient quantity.

Design Comments: The only purpose of the SubstanceAdministration class in the Medicine model is to represent the labeled route.

Design Comments: Specifies an observation that would be made in the described situation, and would characterize the situation. Used as a precondition to the situation. The observation criterion consists of a code to indicate that the observation is a diagnoses, symptoms, conditions, etc. and a value to represent the specific condition, e.g. renal failure, impaired liver function (as value code); systolic blood pressure < 100 mmHg (as numeric value range), etc.

Design Comments: if true it means "this is not an indication'

Design Comments: An observation criterion that is specified as the "reason" (ActRelationship) of the SubstanceAdministration. The observation criterion consists of a code to indicate that the observation is a diagnoses, symptoms, conditions, etc. and a value-code to represent the specific indication, e.g. hypertension, etc.

Design Comments: Allows specifying further constraints on the indication itself, thus more narrowly defining the indication condition as opposed to specifying sub-populations unrelated to the condition.

Design Comments: Specifies an observation that would be made in the described situation, and would characterize the situation. Used as a precondition to the situation. The observation criterion consists of a code to indicate that the observation is a diagnoses, symptoms, conditions, etc. and a value to represent the specific condition, e.g. renal failure, impaired liver function (as value code); systolic blood pressure < 100 mmHg (as numeric value range), etc.

Design Comments: Specifies a certain time constraint between the clinical situation and the use of the drug. E.g., "use 15 minutes before exercise" or "X should be given at least 8 hours after Y".

Design Comments: The ActCriterion is a general criterion to give a procedure code or a code of any other clinical service that would be used to limit either positively or negatively the indication of the drug.

Design Comments: Specifies an observation that would be made in the described situation, and would characterize the situation. Used as a precondition to the situation. The observation criterion consists of a code to indicate that the observation is a diagnoses, symptoms, conditions, etc. and a value to represent the specific condition, e.g. renal failure, impaired liver function (as value code); systolic blood pressure < 100 mmHg (as numeric value range), etc.

Design Comments: The SubstanceAdministrationCriterion specifies another treatment and is used by Issue to specify an interacting treatment, and with a Precondition to specify adjunctive treatment.

Design Comments: labeled route of administration

Design Comments: Specifies a kind of Observation which is used for calculated dosage.

Design Comments: A subordinate component SusbtanceAdministration which carries the doseQuantity for a step in a complex dosage plan. This is used for example, to specify a loading dose, or a tapering dose.

Design Comments: A code-value pair specifying descriptive properties of the medicine, such as color, shape, imprints, etc. The code has a data type of CE and the value has a data type of ANY, which allows codes or numeric values to be specified.

Design Comments: Adverse events, interactions, contraindications and other issues of special caution are represented in one uniform structure. The Pharmacy SIG has established a special kind of Act, called Issue for this purpose. An Issue has one or more other Acts as subjects and indicate that there is a certain problem requiring special caution with its subject Acts. In the case of SPL, the subject is the SubstanceAdministration described in the label. One or more additional subjects can be used to specify additional ClinicalSituationCriteria such as ObservationCriteria or SubstanceAdministrationCriteria. The latter is used to represent interactions which is an Issue involving the administration of two substances.

Design Comments: An ActRelationship linking an Issue to a risk, i.e. a coded ConsequenceObservation criterion with information about severity and frequency of the undesired outcome.

Design Comments: An observation criterion specifying the adverse outcome as the usual code-value pair of an observation.

Design Comments: The description of the risk can nest to refine to a level of specificity that makes the adverse event actually recognizable. For example, a risk may be specified as a "hypersensitivity syndrome" but then specific manifestations may be given including "rash," or "Guillain-Barre Syndrome", or even quantitative measures as "leukopenia with WBC below 1000/mm3."

Design Comments: An observation criterion specifying the adverse outcome as the usual code-value pair of an observation.

Design Comments: A specification of frequency of occurrence of an adverse event as an observation criterion.

Design Comments: A specification of severity of an adverse event as an observation criterion.

Design Comments: This attribute is fixed to 2. See the sequenceNumber attribute of component[monitoringObservation] for its use.

Design Comments: Specifies a criterion (e.g., range) within which certain test results should remain, such as blood levels of the drug or its metabolites should remain to ensure efficacy and avoid toxicity. MonitoringObservation.code specifies the observations that would be performed (e.g. digoxin level, gentamicin level, etc.) and the MonitoringObservation.value specifies a result-value interval with single bounds (e.g. maximal limits) or two bounds (range) that should be maintained throughout the treatment.

Design Comments: Specifies an observation that would be made in the described situation, and would characterize the situation. Used as a precondition to the situation. The observation criterion consists of a code to indicate that the observation is a diagnoses, symptoms, conditions, etc. and a value to represent the specific condition, e.g. renal failure, impaired liver function (as value code); systolic blood pressure < 100 mmHg (as numeric value range), etc.

Design Comments: This attribute is set to 1 for "screening" tests, i.e., those that should be performed before start of treatment, and is left as 2 for monitoring observations that should be done during the treatment. The underlying semantics is that sequenceNumber orders the components of the protocol. If the sequence number is equal in both components, it means these are done in parallel. Otherwise the components are to be executed in the order of ascending sequenceNumber. For simplicity of use and interpretation, the sequenceNumber of the treatment component has been fixed to 2, so that the choice between screening and monitoring can be done in a single element.

Design Comments: "screening" = 1, "monitoring" = 2

Design Comments: Editorial comments much like the comments which can be attached to text with some word processors. Comment.text contains the free text of the comment. The comment can reference a precise location in the section text using the TextFragmentReference. The following is an example: <section> ... <text>Pramoxicol SM is <content ID="cmt123">the cure for hair loss</content>.</text> ... <subjectOf> <comment> <text>This is a unfounded hype, you need to strike this</text> <statusCode code="active"/> <effectiveTime .../> <subject> <textFragmentReference> <text> <reference url="#cmt123"/> </text> </textFragmentReference> </subject> </comment> </subjectOf> ... </section> A comment should be attributed to an author but this author is separate from the document author (explicitly not inherited). Even if no specific author is assigned to a Comment, such Comment is not automatically attributed to the document or section author. A Comment is not even considered part of the Section; it only references the Section and can be sent along with a Section but might be stripped from the Section without such stripping being considered an alteration of the Section. Such a Comment would never be considered part of the authenticated (signed) content of the Document.

Design Comments: A Participation clone that links a Document (or Section) to the Person who originated the document (or section, respectively), and, through AssignedEntity, also links to the Organization that owns the document. If desired, the author(s) of specific sections can be identified using the same structures as it is done for Document.author, which will then override the author(s) specified for the Document. (Note: In the SPL RMIM, this class is represented as a "shadow" of the author class for document, indicating that this participation is used by both the section and the document classes.

Design Comments: Links to an earlier comment, such that one commenter can respond to another comment. When linking comments, the response to a comment is nested as a sequel/comment inside the comment element to which it responds. <section> ... <text><content ID="cmt987" revised="delete">Pramoxicol SM is <content ID="cmt123">the cure for hair loss</content><content>.</text> ... <subjectOf> <comment> <text>O.K. you're right, we did strike the whole sentence.</text> <statusCode code="active"/> <effectiveTime .../> <subject> <textFragmentReference> <text> <reference url="#cmt987"/> </text> </textFragmentReference> </subject> <sequel> <comment> <text>This is a unfounded hype, you need to strike this</text> <statusCode code="active"/> <effectiveTime .../> <subject> <textFragmentReference> <text> <reference url="#cmt123"/> </text> </textFragmentReference> </subject> </comment> </sequel> </comment> </subjectOf> ... </section>

Design Comments: References a specific fragment in the section text using the XML ID attributes on the content element in the section.

Design Comments: The reference to the text, using the referencing function of the ED data type, i.e., as a URL with a fragment reference, where the fragment is typically created by a content element with an XML ID attribute as defined in the Narrative Block schema (see Section.text).

Design Comments: refers to a content element in the section text

Design Comments: Editorial comments much like the comments which can be attached to text with some word processors. Comment.text contains the free text of the comment. The comment can reference a precise location in the section text using the TextFragmentReference. The following is an example: <section> ... <text>Pramoxicol SM is <content ID="cmt123">the cure for hair loss</content>.</text> ... <subjectOf> <comment> <text>This is a unfounded hype, you need to strike this</text> <statusCode code="active"/> <effectiveTime .../> <subject> <textFragmentReference> <text> <reference url="#cmt123"/> </text> </textFragmentReference> </subject> </comment> </subjectOf> ... </section> A comment should be attributed to an author but this author is separate from the document author (explicitly not inherited). Even if no specific author is assigned to a Comment, such Comment is not automatically attributed to the document or section author. A Comment is not even considered part of the Section; it only references the Section and can be sent along with a Section but might be stripped from the Section without such stripping being considered an alteration of the Section. Such a Comment would never be considered part of the authenticated (signed) content of the Document.