From 0f9214b41b701f787ce0bd4a06b588055fe574f1 Mon Sep 17 00:00:00 2001 From: Healthedata1 Date: Wed, 16 Oct 2019 17:37:37 -0700 Subject: [PATCH 1/2] create bash files to load locally --- _updatePublisher.sh | 10 + input-cache/schemas-r5/fhir-single.xsd | 2693 +++++++----------------- input/pagecontent/best-practice.md | 172 +- input/pagecontent/using-templates.xml | 326 ++- publish.sh | 67 + 5 files changed, 1140 insertions(+), 2128 deletions(-) create mode 100644 _updatePublisher.sh create mode 100644 publish.sh diff --git a/_updatePublisher.sh b/_updatePublisher.sh new file mode 100644 index 0000000..0c92d37 --- /dev/null +++ b/_updatePublisher.sh @@ -0,0 +1,10 @@ +#!/bin/bash +echo "========================================================================" +echo "Downloading most recent publisher to:" +echo ~/Downloads/org.hl7.fhir.igpublisher.jar +echo "... it's ~100 MB, so this may take a bit" +echo "========================================================================" +mv ~/Downloads/org.hl7.fhir.igpublisher.jar ~/Downloads/org.hl7.fhir.igpublisher-old.jar +curl -L https://github.com/FHIR/latest-ig-publisher/raw/master/org.hl7.fhir.publisher.jar -o ~/Downloads/org.hl7.fhir.igpublisher.jar +echo "=========================== Done ====================================" +sleep 3 diff --git a/input-cache/schemas-r5/fhir-single.xsd b/input-cache/schemas-r5/fhir-single.xsd index c479297..4c9e04e 100644 --- a/input-cache/schemas-r5/fhir-single.xsd +++ b/input-cache/schemas-r5/fhir-single.xsd @@ -27,7 +27,7 @@ POSSIBILITY OF SUCH DAMAGE. - Generated on Thu, Sep 12, 2019 17:07+0000 for FHIR v4.1.0 + Generated on Wed, Oct 16, 2019 18:52+0000 for FHIR v4.1.0 --> @@ -410,7 +410,6 @@ - @@ -477,19 +476,15 @@ - - - - @@ -1694,6 +1689,179 @@ The value of mustSupport SHALL be a FHIRPath resolveable on the type of the Data + + + A fact or piece of data from a study of a large quantity of numerical data. A mathematical or quantified characteristic of a group of observations. + If the element is present, it must have a value for at least one of the defined elements, an @id referenced from the Narrative, or extensions + + + + + + + A description of the content value of the statistic. + + + + + Footnotes and/or explanatory notes. + + + + + Type of statistic, eg relative risk. + + + + + Statistic value. + + + + + Number of samples in the statistic. + + + + + An estimate of the precision of the statistic. + + + + + + + + + A fact or piece of data from a study of a large quantity of numerical data. A mathematical or quantified characteristic of a group of observations. + If the element is present, it must have a value for at least one of the defined elements, an @id referenced from the Narrative, or extensions + + + + + + + Human-readable summary of population sample size. + + + + + Footnote or explanatory note about the sample size. + + + + + Number of participants in the population. + + + + + A human-readable string to clarify or explain concepts about the sample size. + + + + + Number of participants with known results for measured variables. + + + + + Number of participants with “positive” results, only used to report actual numerator count for a proportion. + + + + + + + + + A fact or piece of data from a study of a large quantity of numerical data. A mathematical or quantified characteristic of a group of observations. + If the element is present, it must have a value for at least one of the defined elements, an @id referenced from the Narrative, or extensions + + + + + + + Human-readable summary of the estimate. + + + + + Footnote or explanatory note about the estimate. + + + + + The estimateType of precision estimate, eg confidence interval or p value type. + + + + + The singular quantity of the precision estimate, for precision estimates represented as single values; also used to report unit of measure. + + + + + Use 95 for a 95% confidence interval. + + + + + Lower bound of confidence interval. + + + + + An estimate of the precision of the estimate. + + + + + + + + + A fact or piece of data from a study of a large quantity of numerical data. A mathematical or quantified characteristic of a group of observations. + If the element is present, it must have a value for at least one of the defined elements, an @id referenced from the Narrative, or extensions + + + + + + + Human-readable summary of the estimate. + + + + + Footnote or explanatory note about the estimate. + + + + + The estimateType of attribute estimate, eg confidence interval or p value type. + + + + + The singular quantity of the attribute estimate, for attribute estimates represented as single values; also used to report unit of measure. + + + + + Use 95 for a 95% confidence interval. + + + + + Lower bound of confidence interval. + + + + + + A reference to a code defined by a terminology system. @@ -1847,6 +2015,70 @@ The value of mustSupport SHALL be a FHIRPath resolveable on the type of the Data + + + An ordered list (distribution) of statistics. + If the element is present, it must have a value for at least one of the defined elements, an @id referenced from the Narrative, or extensions + + + + + + + A description of the content and value of the statistic. + + + + + Footnotes and/or explanatory notes. + + + + + Number of intervals in an array, eg 4 for quartiles. + + + + + Bottom of first interval. + + + + + Interval. + + + + + Singular value of the statistic at the upper bound of the interval. + + + + + + + + + An ordered list (distribution) of statistics. + If the element is present, it must have a value for at least one of the defined elements, an @id referenced from the Narrative, or extensions + + + + + + + Relative order of interval. + + + + + Values and parameters for a single statistic related to the interval. + + + + + + A length - a value with a unit that is a physical distance. @@ -4174,71 +4406,6 @@ Modifier extensions SHALL NOT change the meaning of any elements on Resource or - - - - - Related To - - - - - Equivalent - - - - - Equal - - - - - Wider - - - - - Subsumes - - - - - Narrower - - - - - Specializes - - - - - Inexact - - - - - Unmatched - - - - - Disjoint - - - - - - - - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - @@ -4982,6 +5149,11 @@ A coverage may only be responsible for specific types of charges, and the sequen Todo. + + + The manufactured item(s) that this administrable product is produced from. Either a single item, or several that are mixed before administration (e.g. a power item and a solution item). Note that these are not raw ingredients. + + The ingredients of this administrable pharmaceutical product. @@ -5015,9 +5187,20 @@ A coverage may only be responsible for specific types of charges, and the sequen - A coded characteristic. + A code expressing the type of characteristic. + + + A value for the characteristic. + + + + + + + + The status of characteristic e.g. assigned or pending. @@ -5138,6 +5321,11 @@ A coverage may only be responsible for specific types of charges, and the sequen Business identifiers assigned to this adverse event by the performer or other systems which remain constant as the resource is updated and propagates from server to server. + + + The current state of the data entry of the adverse event or potential adverse event. + + Whether the event actually happened, or just had the potential to. Note that this is independent of whether anyone was affected or harmed or how severely. @@ -5163,11 +5351,14 @@ A coverage may only be responsible for specific types of charges, and the sequen The Encounter during which AdverseEvent was created or to which the creation of this record is tightly associated. - + The date (and perhaps time) when the adverse event occurred. - - + + + + + Estimated or actual date the AdverseEvent began, in the opinion of the reporter. @@ -5203,19 +5394,29 @@ A coverage may only be responsible for specific types of charges, and the sequen Information on who recorded the adverse event. May be the patient or a practitioner. - + + + Indicates who or what participated in the adverse event and how they were involved. + + + - Parties that may or should contribute or have contributed information to the adverse event, which can consist of one or more activities. Such information includes information leading to the decision to perform the activity and how to perform the activity (e.g. consultant), information that the activity itself seeks to reveal (e.g. informant of clinical history), or information about what activity was performed (e.g. informant witness). + Describes the entity that is suspected to have caused the adverse event. - + - Who or what identified a change in physiological state or condition. + The contributing factors suspected to have increased the probability or severity of the adverse event. - + - Describes the entity that is suspected to have caused the adverse event. + Preventive actions that contributed to avoiding the adverse event. + + + + + The ameliorating action taken after the adverse event occured in order to reduce the extent of harm. @@ -5232,6 +5433,27 @@ A coverage may only be responsible for specific types of charges, and the sequen + + + An event (i.e. any change to current patient status) that may be related to unintended effects on a patient or research subject. The unintended effects may require additional monitoring, treatment or hospitalization or may result in death. The AdverseEvent resource also extends to potential or avoided events that could have had such effects. + + + + + + + Distinguishes the type of involvement of the actor in the adverse event, such as contributor or informant. + + + + + Indicates who or what participated in the event. + + + + + + An event (i.e. any change to current patient status) that may be related to unintended effects on a patient or research subject. The unintended effects may require additional monitoring, treatment or hospitalization or may result in death. The AdverseEvent resource also extends to potential or avoided events that could have had such effects. @@ -5281,24 +5503,74 @@ A coverage may only be responsible for specific types of charges, and the sequen - + An event (i.e. any change to current patient status) that may be related to unintended effects on a patient or research subject. The unintended effects may require additional monitoring, treatment or hospitalization or may result in death. The AdverseEvent resource also extends to potential or avoided events that could have had such effects. - + - Relevant past history for the subject. In a clinical care context, an example being a patient had an adverse event following a penciliin administration and the patient had a previously documented penicillin allergy. In a clinical trials context, an example is a bunion or rash that was present prior to the study. -Additionally, the supporting item can be a document that is relevant to this instance of the adverse event that is not part of the subject's medical history. For example, a clinical note, staff list, or material safety data sheet (MSDS). - - - + The item that is suspected to have increased the probability or severity of the adverse event. + + + + + + + + + + + An event (i.e. any change to current patient status) that may be related to unintended effects on a patient or research subject. The unintended effects may require additional monitoring, treatment or hospitalization or may result in death. The AdverseEvent resource also extends to potential or avoided events that could have had such effects. + + + + + - If true, the item has been assessed to be a contributing factor of the adverse event. - - + The action that contributed to avoiding the adverse event. + + + + + + + + + + + An event (i.e. any change to current patient status) that may be related to unintended effects on a patient or research subject. The unintended effects may require additional monitoring, treatment or hospitalization or may result in death. The AdverseEvent resource also extends to potential or avoided events that could have had such effects. + + + + + + + The ameliorating action taken after the adverse event occured in order to reduce the extent of harm. + + + + + + + + + + + An event (i.e. any change to current patient status) that may be related to unintended effects on a patient or research subject. The unintended effects may require additional monitoring, treatment or hospitalization or may result in death. The AdverseEvent resource also extends to potential or avoided events that could have had such effects. + + + + + + + Relevant past history for the subject. In a clinical care context, an example being a patient had an adverse event following a pencillin administration and the patient had a previously documented penicillin allergy. In a clinical trials context, an example is a bunion or rash that was present prior to the study. Additionally, the supporting item can be a document that is relevant to this instance of the adverse event that is not part of the subject's medical history. For example, a clinical note, staff list, or material safety data sheet (MSDS). Supporting information is not a contributing factor, preventive action, or mitigating action. + + + + @@ -5328,6 +5600,41 @@ Additionally, the supporting item can be a document that is relevant to this ins + + + + + In Progress + + + + + Completed + + + + + Entered in Error + + + + + Unknown + + + + + + + Codes identifying the lifecycle stage of an event. + If the element is present, it must have either a @value, an @id, or extensions + + + + + + + Risk of harmful or undesirable, physiological response which is unique to an individual and associated with exposure to a substance. @@ -5976,6 +6283,11 @@ The duration (usually in minutes) could also be provided to indicate the length Indicator for type of action performed during the event that generated the audit. + + + Indicates and enables segmentation of various severity including debugging from critical. + + The period during which the activity occurred. @@ -6170,11 +6482,6 @@ The duration (usually in minutes) could also be provided to indicate the length A name of the entity in the audit event. - - - Text that describes the entity in more detail. - - The query parameters for a query-type entities. @@ -6287,6 +6594,61 @@ The duration (usually in minutes) could also be provided to indicate the length + + + + + Emergency + + + + + Alert + + + + + Critical + + + + + Error + + + + + Warning + + + + + Notice + + + + + Informational + + + + + Debug + + + + + + + The severity of the audit entry. + If the element is present, it must have either a @value, an @id, or extensions + + + + + + + @@ -8939,11 +9301,6 @@ into another (possibly the same) biological entity. Identifies the patient or group whose intended care is handled by the team. - - - The Encounter during which this CareTeam was created or to which the creation of this record is tightly associated. - - Indicates when the team did (or is intended to) come into effect and end. @@ -11250,7 +11607,7 @@ into another (possibly the same) biological entity. Business identifiers assigned to this clinical impression by the performer or other systems which remain constant as the resource is updated and propagates from server to server. - + Identifies the workflow status of the assessment. @@ -11260,11 +11617,6 @@ into another (possibly the same) biological entity. Captures the reason for the current state of the ClinicalImpression. - - - Categorizes the type of clinical assessment performed. - - A summary of the context and/or cause of the assessment - why / where it was performed, and what patient events/status prompted it. @@ -11372,13 +11724,33 @@ into another (possibly the same) biological entity. - + + + + Preparation + + In Progress + + + Not Done + + + + + On Hold + + + + + Stopped + + Completed @@ -11389,16 +11761,21 @@ into another (possibly the same) biological entity. Entered in Error + + + Unknown + + - + The workflow state of a clinical impression. If the element is present, it must have either a @value, an @id, or extensions - + @@ -12334,61 +12711,6 @@ into another (possibly the same) biological entity. - - - - - Preparation - - - - - In Progress - - - - - Not Done - - - - - On Hold - - - - - Stopped - - - - - Completed - - - - - Entered in Error - - - - - Unknown - - - - - - - The status of the communication. - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - A request to convey information; e.g. the CDS system proposes that an alert be sent to a responsible provider, the CDS system proposes that the public health agency be notified about a reportable condition. @@ -13243,7 +13565,7 @@ into another (possibly the same) biological entity. - What to do when there is no mapping for the source concept. "Unmapped" does not include codes that are unmatched, and the unmapped element is ignored in a code is specified to have equivalence = unmatched. + What to do when there is no mapping to a target concept from the source concept. This provides the "default" to be applied when there is no target concept mapping specified. The 'unmapped' element is ignored if a code is specified to have relationship = not-related-to. @@ -13267,6 +13589,11 @@ into another (possibly the same) biological entity. The display for the code. The display is only provided to help editors when editing the concept map. + + + If noMap = true this indicates that no mapping to a target concept exists for this source concept. + + A concept from the target value set that this concept maps to. @@ -13293,9 +13620,9 @@ into another (possibly the same) biological entity. The display for the code. The display is only provided to help editors when editing the concept map. - + - The equivalence between the source and target concepts (counting for the dependencies and products). The equivalence is read from target to source (e.g. the target is 'wider' than the source). + The relationship between the source and target concepts. The relationship is read from target to source (e.g. the target is 'broader' than the source). @@ -13310,7 +13637,7 @@ into another (possibly the same) biological entity. - A set of additional outcomes from this mapping to other elements. To properly execute this mapping, the specified element must be mapped to some data element or source that is in context. The mapping may still be useful without a place for the additional data elements, but the equivalence cannot be relied on. + A set of additional outcomes from this mapping to other elements. To properly execute this mapping, the specified element must be mapped to some data element or source that is in context. The mapping may still be useful without a place for the additional data elements, but the relationship (e.g., equivalent) cannot be relied on. @@ -13479,7 +13806,7 @@ into another (possibly the same) biological entity. - The 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. + The 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" - Some conditions, such as chronic conditions, are never really resolved, but they can abate. @@ -13912,12 +14239,12 @@ into another (possibly the same) biological entity. - Indicates the current state of this consent. + Indicates the current state of this Consent resource. - A selector of the type of consent being presented: ADR, Privacy, Treatment, Research. This list is now extensible. + A selector of the type of consent being presented: Privacy, Treatment, or Research. This list is now extensible. @@ -15313,7 +15640,7 @@ into another (possibly the same) biological entity. The party who has signed-up for or 'owns' the contractual relationship to the policy or to whom the benefit of the policy for services rendered to them or their family is due. - + The insurer assigned ID for the Subscriber. @@ -15325,7 +15652,7 @@ into another (possibly the same) biological entity. - A unique identifier for a dependent under the coverage. + A designator for a dependent under the coverage. @@ -17774,12 +18101,12 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* seralized object with a mime-type, so includes formal patient centric documents (CDA), clniical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. + A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* serialized object with a mime-type, it includes formal patient-centric documents (CDA), clinical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. - A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* seralized object with a mime-type, so includes formal patient centric documents (CDA), clniical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. + A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* serialized object with a mime-type, it includes formal patient-centric documents (CDA), clinical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. If the element is present, it must have either a @value, an @id, or extensions @@ -17857,7 +18184,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - The document and format referenced. There may be multiple content element repetitions, each with a different format. + The document and format referenced. If there are multiple content element repetitions, these must all represent the same document in different format, or attachment metadata. @@ -17871,7 +18198,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* seralized object with a mime-type, so includes formal patient centric documents (CDA), clniical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. + A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* serialized object with a mime-type, it includes formal patient-centric documents (CDA), clinical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. @@ -17892,7 +18219,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* seralized object with a mime-type, so includes formal patient centric documents (CDA), clniical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. + A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* serialized object with a mime-type, it includes formal patient-centric documents (CDA), clinical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. @@ -17913,7 +18240,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* seralized object with a mime-type, so includes formal patient centric documents (CDA), clniical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. + A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this "document" encompasses *any* serialized object with a mime-type, it includes formal patient-centric documents (CDA), clinical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. @@ -17962,394 +18289,6 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - - - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - An absolute URI that is used to identify this effect evidence synthesis when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this effect evidence synthesis is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the effect evidence synthesis is stored on different servers. - - - - - A formal identifier that is used to identify this effect evidence synthesis when it is represented in other formats, or referenced in a specification, model, design or an instance. - - - - - The identifier that is used to identify this version of the effect evidence synthesis when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the effect evidence synthesis author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. - - - - - A natural language name identifying the effect evidence synthesis. This name should be usable as an identifier for the module by machine processing applications such as code generation. - - - - - A short, descriptive, user-friendly title for the effect evidence synthesis. - - - - - The status of this effect evidence synthesis. Enables tracking the life-cycle of the content. - - - - - The date (and optionally time) when the effect evidence synthesis was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the effect evidence synthesis changes. - - - - - The name of the organization or individual that published the effect evidence synthesis. - - - - - Contact details to assist a user in finding and communicating with the publisher. - - - - - A free text natural language description of the effect evidence synthesis from a consumer's perspective. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate effect evidence synthesis instances. - - - - - A legal or geographic region in which the effect evidence synthesis is intended to be used. - - - - - A copyright statement relating to the effect evidence synthesis and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the effect evidence synthesis. - - - - - The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. - - - - - The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date. - - - - - The period during which the effect evidence synthesis content was or is planned to be in active use. - - - - - Descriptive topics related to the content of the EffectEvidenceSynthesis. Topics provide a high-level categorization grouping types of EffectEvidenceSynthesiss that can be useful for filtering and searching. - - - - - An individiual or organization primarily involved in the creation and maintenance of the content. - - - - - An individual or organization primarily responsible for internal coherence of the content. - - - - - An individual or organization primarily responsible for review of some aspect of the content. - - - - - An individual or organization responsible for officially endorsing the content for use in some setting. - - - - - Related artifacts such as additional documentation, justification, or bibliographic references. - - - - - Type of synthesis eg meta-analysis. - - - - - Type of study eg randomized trial. - - - - - A reference to a EvidenceVariable resource that defines the population for the research. - - - - - A reference to a EvidenceVariable resource that defines the exposure for the research. - - - - - A reference to a EvidenceVariable resource that defines the comparison exposure for the research. - - - - - A reference to a EvidenceVariable resomece that defines the outcome for the research. - - - - - A description of the size of the sample involved in the synthesis. - - - - - A description of the results for each exposure considered in the effect estimate. - - - - - The estimated effect of the exposure variant. - - - - - A description of the certainty of the effect estimate. - - - - - - - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - - - - - - - Human-readable summary of sample size. - - - - - Number of studies included in this evidence synthesis. - - - - - Number of participants included in this evidence synthesis. - - - - - - - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - - - - - - - Human-readable summary of results by exposure state. - - - - - Whether these results are for the exposure state or alternative exposure state. - - - - - Used to define variant exposure states such as low-risk state. - - - - - Reference to a RiskEvidenceSynthesis resource. - - - - - - - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - - - - - - - Human-readable summary of effect estimate. - - - - - Examples include relative risk and mean difference. - - - - - Used to define variant exposure states such as low-risk state. - - - - - The point estimate of the effect estimate. - - - - - Specifies the UCUM unit for the outcome. - - - - - A description of the precision of the estimate for the effect. - - - - - - - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - - - - - - - Examples include confidence interval and interquartile range. - - - - - Use 95 for a 95% confidence interval. - - - - - Lower bound of confidence interval. - - - - - Upper bound of confidence interval. - - - - - - - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - - - - - - - A rating of the certainty of the effect estimate. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - A description of a component of the overall certainty. - - - - - - - - - The EffectEvidenceSynthesis resource describes the difference in an outcome between exposures states in a population where the effect estimate is derived from a combination of research studies. - - - - - - - Type of subcomponent of certainty rating. - - - - - A rating of a subcomponent of rating certainty. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - - - - - - - Exposure - - - - - Exposure Alternative - - - - - - - Whether the results by exposure is describing the results for the primary exposure of interest (exposure) or the alternative state (exposureAlternative). - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - An interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient. @@ -19314,12 +19253,12 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - The Evidence resource describes the conditional state (population and any exposures being compared within the population) and outcome (if specified) that the knowledge (evidence, assertion, recommendation) is about. + This represents statistics, certainty, both the intended and actual population, and evidence variables. - The Evidence resource describes the conditional state (population and any exposures being compared within the population) and outcome (if specified) that the knowledge (evidence, assertion, recommendation) is about. + This represents statistics, certainty, both the intended and actual population, and evidence variables. If the element is present, it must have either a @value, an @id, or extensions @@ -19327,57 +19266,57 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - An absolute URI that is used to identify this evidence when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this evidence is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the evidence is stored on different servers. + An absolute URI that is used to identify this evidence when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this summary is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the summary is stored on different servers. - A formal identifier that is used to identify this evidence when it is represented in other formats, or referenced in a specification, model, design or an instance. + A formal identifier that is used to identify this summary when it is represented in other formats, or referenced in a specification, model, design or an instance. - The identifier that is used to identify this version of the evidence when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the evidence author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. To provide a version consistent with the Decision Support Service specification, use the format Major.Minor.Revision (e.g. 1.0.0). For more information on versioning knowledge assets, refer to the Decision Support Service specification. Note that a version is required for non-experimental active artifacts. + The identifier that is used to identify this version of the summary when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the summary author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. - + - A natural language name identifying the evidence. This name should be usable as an identifier for the module by machine processing applications such as code generation. + A short, descriptive, user-friendly title for the summary. - + - A short, descriptive, user-friendly title for the evidence. + The status of this summary. Enables tracking the life-cycle of the content. - + - The short title provides an alternate title for use in informal descriptive contexts where the full, formal title is not necessary. + The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate evidence instances. - + - An explanatory or alternate title for the Evidence giving additional information about its content. + The date (and optionally time) when the summary was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the summary changes. - + - The status of this evidence. Enables tracking the life-cycle of the content. + The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. - + - The date (and optionally time) when the evidence was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the evidence changes. + The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date. - + - The name of the organization or individual that published the evidence. + Contact detail and role for contributor to summary. - + - Contact details to assist a user in finding and communicating with the publisher. + Link or citation to artifact associated with the summary. @@ -19385,84 +19324,188 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | A free text natural language description of the evidence from a consumer's perspective. + + + Declarative description of the Evidence. + + - A human-readable string to clarify or explain concepts about the resource. + Footnotes and/or explanatory notes. - + - The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate evidence instances. + Group being referenced. - + - A legal or geographic region in which the evidence is intended to be used. + Evidence variable. - + - A copyright statement relating to the evidence and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the evidence. + The particular type of synthesis if this is a synthesis summary. - + - The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. + The type of study that produced this summary. - + - The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date. + The statistic value(s). - + - The period during which the evidence content was or is planned to be in active use. + Ordered distribution. - + - Descriptive topics related to the content of the Evidence. Topics provide a high-level categorization grouping types of Evidences that can be useful for filtering and searching. + Level of certainty. - + + + + + + + This represents statistics, certainty, both the intended and actual population, and evidence variables. + + + + + - An individiual or organization primarily involved in the creation and maintenance of the content. + Textual description of referent group. - + - An individual or organization primarily responsible for internal coherence of the content. + Footnotes and/or explanatory notes. - + - An individual or organization primarily responsible for review of some aspect of the content. + Various information categories of group. - + - An individual or organization responsible for officially endorsing the content for use in some setting. + Non-actual group that is a set of characteristics. - + - Related artifacts such as additional documentation, justification, or bibliographic references. + Indication of quality of match between intended group to actual group. + + + + + + + + + This represents statistics, certainty, both the intended and actual population, and evidence variables. + + + + + + + Description of the variable. + + + + + Footnotes and/or explanatory notes. + + + + + exposure | referenceExposure | measuredVariable | confounder. + + + + + Definition of the actual variable related to the statistic(s). + + + + + Definition of the intended variable related to the Evidence. + + + + + Indication of quality of match between intended variable to actual variable. + + + + + + + + + This represents statistics, certainty, both the intended and actual population, and evidence variables. + + + + + + + Textual description of certainty. + + + + + Footnotes and/or explanatory notes. + + + + + Rating of certainty. + + + + + Subcomponent of certainty. + + + + + + + + + This represents statistics, certainty, both the intended and actual population, and evidence variables. + + + + + + + Textual description of certainty subcomponent. - + - A reference to a EvidenceVariable resource that defines the population for the research. + Textual note of certainty subcomponent. - + - A reference to a EvidenceVariable resource that defines the exposure for the research. + Footnotes and/or explanatory notes. - + - A reference to a EvidenceVariable resomece that defines the outcome for the research. + Rating of certainty subcomponent. @@ -19612,7 +19655,12 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | The type of evidence element, a population, an exposure, or an outcome. - + + + True if the actual variable measured, false if a conceptual representation of the intended variable. + + + A characteristic that defines the members of the evidence element. Multiple characteristics are applied with "and" semantics. @@ -19644,9 +19692,19 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - + - Use UsageContext to define the members of the population, such as Age Ranges, Genders, Settings. + Method used for describing characteristic. + + + + + Device used for determining characteristic. + + + + + Use booleanSet to define the members of the population, such as Age Ranges, Genders, Settings. @@ -20563,12 +20621,6 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | 领域资源 - - - EffectEvidenceSynthesis - EffectEvidenceSynthesis - - Encounter @@ -21138,18 +21190,6 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | 请求分组 - - - ResearchDefinition - ResearchDefinition - - - - - ResearchElementDefinition - ResearchElementDefinition - - ResearchStudy @@ -21183,12 +21223,6 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | 风险评估 - - - RiskEvidenceSynthesis - RiskEvidenceSynthesis - - Schedule @@ -21245,12 +21279,6 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | 标本定义 - - - Statistic - Statistic - - StructureDefinition @@ -24047,7 +24075,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - A list of all the series.modality values that are actual acquisition modalities, i.e. those in the DICOM Context Group 29 (value set OID 1.2.840.10008.6.1.19). + A list of all the distinct values of series.modality. This may include both aquisition and non-aquisition modalities. @@ -24095,14 +24123,9 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | Number of SOP Instances in Study. This value given may be larger than the number of instance elements this resource contains due to resource availability, security, or other factors. This element should be present if any instance elements are present. - + - The procedure which this ImagingStudy was part of. - - - - - The code for the performed procedure type. + The procedure or code from which this ImagingStudy was part of. @@ -24139,6 +24162,24 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | + + + Representation of the content produced in a DICOM imaging study. A study comprises a set of series, each of which includes a set of Service-Object Pair Instances (SOP Instances - images or other data) acquired or produced in a common context. A series is of only one modality (e.g. X-ray, CT, MR, ultrasound), but a study may have multiple series of different modalities. + + + + + + + The procedure which this ImagingStudy was part of. + + + + + + + + Representation of the content produced in a DICOM imaging study. A study comprises a set of series, each of which includes a set of Service-Object Pair Instances (SOP Instances - images or other data) acquired or produced in a common context. A series is of only one modality (e.g. X-ray, CT, MR, ultrasound), but a study may have multiple series of different modalities. @@ -24158,7 +24199,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - The modality of this series sequence. + The distinct modality for this series. This may include both aquisition and non-aquisition modalities. @@ -27161,14 +27202,14 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - + The quantity of substance in the unit of presentation, or in the volume (or mass) of the single pharmaceutical product or manufactured item. - + - A lower limit for the quantity of substance in the unit of presentation. For use when there is a range of strengths, this is the lower limit, with the presentation attribute becoming the upper limit. + An upper limit for the quantity of substance in the unit of presentation. For use when there is a range of strengths, this is the high limit, with the presentation attribute becoming the lower limit. @@ -27176,9 +27217,9 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | The strength per unitary volume (or mass). - + - A lower limit for the strength per unitary volume (or mass), for when there is a range. The concentration attribute then becomes the upper limit. + An upper limit for the strength per unitary volume (or mass), for when there is a range. The concentration attribute then becomes the lower limit. @@ -27219,9 +27260,9 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | Strength expressed in terms of a reference substance. - + - Strength expressed in terms of a reference substance. + Strength expressed in terms of a reference substance, upper limit. @@ -28441,6 +28482,11 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | + + + Unique identifier. + + Dose form as manufactured and before any transformation into the pharmaceutical product. @@ -28461,16 +28507,38 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | Ingredient. - + - Dimensions, color etc. + General characteristics of this item. - + + + + + + + The manufactured item as contained in the packaged medicinal product. + + + + + - Other codeable characteristics. + A code expressing the type of characteristic. + + + A value for the characteristic. + + + + + + + + @@ -29203,7 +29271,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - The actual ingredient - either a substance (simple ingredient) or another medication of a medication. + The ingredient (substance or medication) that the ingredient.strength relates to. This is represented as a concept from a code system or described in another resource (Substance or Medication). @@ -29303,6 +29371,11 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this MedicationAdministration. + + + A plan that is fulfilled in whole or in part by this MedicationDispense. + + A larger event of which this particular event is a component or step. @@ -29483,6 +29556,11 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | Identifiers associated with this Medication Dispense that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. They are business identifiers assigned to this resource by the performer or other systems and remain constant as the resource is updated and propagates from server to server. + + + A plan that is fulfilled in whole or in part by this MedicationDispense. + + The procedure that trigger the dispense. @@ -30084,7 +30162,7 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | Specifies if changes are allowed when dispensing a medication from a regulatory perspective. - + Specifies the schedule of a medication in jurisdiction. @@ -30119,22 +30197,6 @@ UDILabelName | UserFriendlyName | PatientReportedName | ManufactureDeviceName | - - - Information about a medication that is used to support knowledge. - - - - - - - Specifies the specific drug schedule. - - - - - - Information about a medication that is used to support knowledge. @@ -30786,7 +30848,7 @@ The primary difference between a medicationusage and a medicationadministration Whether the Medicinal Product is subject to additional monitoring for regulatory reasons. - + Whether the Medicinal Product is subject to special measures for regulatory reasons. @@ -32907,6 +32969,7 @@ The primary difference between a medicationusage and a medicationadministration + @@ -33035,6 +33098,7 @@ The primary difference between a medicationusage and a medicationadministration + @@ -33477,47 +33541,6 @@ The primary difference between a medicationusage and a medicationadministration - - - - - Draft - черновик - ontwerp - - - - - Active - активный - actief - - - - - Retired - удалён - verouderd - - - - - Unknown - - - - - - - Codes identifying the state of an ObservationDefinition. - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - A formal computable definition of an operation (on the RESTful interface) or a named query (using the search interaction). @@ -37736,522 +37759,6 @@ Deceased patients may also be marked as inactive for the same reasons, but may b - - - The ResearchDefinition resource describes the conditional state (population and any exposures being compared within the population) and outcome (if specified) that the knowledge (evidence, assertion, recommendation) is about. - - - - - The ResearchDefinition resource describes the conditional state (population and any exposures being compared within the population) and outcome (if specified) that the knowledge (evidence, assertion, recommendation) is about. - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - An absolute URI that is used to identify this research definition when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this research definition is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the research definition is stored on different servers. - - - - - A formal identifier that is used to identify this research definition when it is represented in other formats, or referenced in a specification, model, design or an instance. - - - - - The identifier that is used to identify this version of the research definition when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the research definition author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. To provide a version consistent with the Decision Support Service specification, use the format Major.Minor.Revision (e.g. 1.0.0). For more information on versioning knowledge assets, refer to the Decision Support Service specification. Note that a version is required for non-experimental active artifacts. - - - - - A natural language name identifying the research definition. This name should be usable as an identifier for the module by machine processing applications such as code generation. - - - - - A short, descriptive, user-friendly title for the research definition. - - - - - The short title provides an alternate title for use in informal descriptive contexts where the full, formal title is not necessary. - - - - - An explanatory or alternate title for the ResearchDefinition giving additional information about its content. - - - - - The status of this research definition. Enables tracking the life-cycle of the content. - - - - - A Boolean value to indicate that this research definition is authored for testing purposes (or education/evaluation/marketing) and is not intended to be used for genuine usage. - - - - - The intended subjects for the ResearchDefinition. If this element is not provided, a Patient subject is assumed, but the subject of the ResearchDefinition can be anything. - - - - - - - The date (and optionally time) when the research definition was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the research definition changes. - - - - - The name of the organization or individual that published the research definition. - - - - - Contact details to assist a user in finding and communicating with the publisher. - - - - - A free text natural language description of the research definition from a consumer's perspective. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate research definition instances. - - - - - A legal or geographic region in which the research definition is intended to be used. - - - - - Explanation of why this research definition is needed and why it has been designed as it has. - - - - - A detailed description, from a clinical perspective, of how the ResearchDefinition is used. - - - - - A copyright statement relating to the research definition and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the research definition. - - - - - The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. - - - - - The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date. - - - - - The period during which the research definition content was or is planned to be in active use. - - - - - Descriptive topics related to the content of the ResearchDefinition. Topics provide a high-level categorization grouping types of ResearchDefinitions that can be useful for filtering and searching. - - - - - An individiual or organization primarily involved in the creation and maintenance of the content. - - - - - An individual or organization primarily responsible for internal coherence of the content. - - - - - An individual or organization primarily responsible for review of some aspect of the content. - - - - - An individual or organization responsible for officially endorsing the content for use in some setting. - - - - - Related artifacts such as additional documentation, justification, or bibliographic references. - - - - - A reference to a Library resource containing the formal logic used by the ResearchDefinition. - - - - - A reference to a ResearchElementDefinition resource that defines the population for the research. - - - - - A reference to a ResearchElementDefinition resource that defines the exposure for the research. - - - - - A reference to a ResearchElementDefinition resource that defines the exposureAlternative for the research. - - - - - A reference to a ResearchElementDefinition resomece that defines the outcome for the research. - - - - - - - - - The ResearchElementDefinition resource describes a "PICO" element that knowledge (evidence, assertion, recommendation) is about. - - - - - The ResearchElementDefinition resource describes a "PICO" element that knowledge (evidence, assertion, recommendation) is about. - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - An absolute URI that is used to identify this research element definition when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this research element definition is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the research element definition is stored on different servers. - - - - - A formal identifier that is used to identify this research element definition when it is represented in other formats, or referenced in a specification, model, design or an instance. - - - - - The identifier that is used to identify this version of the research element definition when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the research element definition author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. To provide a version consistent with the Decision Support Service specification, use the format Major.Minor.Revision (e.g. 1.0.0). For more information on versioning knowledge assets, refer to the Decision Support Service specification. Note that a version is required for non-experimental active artifacts. - - - - - A natural language name identifying the research element definition. This name should be usable as an identifier for the module by machine processing applications such as code generation. - - - - - A short, descriptive, user-friendly title for the research element definition. - - - - - The short title provides an alternate title for use in informal descriptive contexts where the full, formal title is not necessary. - - - - - An explanatory or alternate title for the ResearchElementDefinition giving additional information about its content. - - - - - The status of this research element definition. Enables tracking the life-cycle of the content. - - - - - A Boolean value to indicate that this research element definition is authored for testing purposes (or education/evaluation/marketing) and is not intended to be used for genuine usage. - - - - - The intended subjects for the ResearchElementDefinition. If this element is not provided, a Patient subject is assumed, but the subject of the ResearchElementDefinition can be anything. - - - - - - - The date (and optionally time) when the research element definition was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the research element definition changes. - - - - - The name of the organization or individual that published the research element definition. - - - - - Contact details to assist a user in finding and communicating with the publisher. - - - - - A free text natural language description of the research element definition from a consumer's perspective. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate research element definition instances. - - - - - A legal or geographic region in which the research element definition is intended to be used. - - - - - Explanation of why this research element definition is needed and why it has been designed as it has. - - - - - A detailed description, from a clinical perspective, of how the ResearchElementDefinition is used. - - - - - A copyright statement relating to the research element definition and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the research element definition. - - - - - The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. - - - - - The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date. - - - - - The period during which the research element definition content was or is planned to be in active use. - - - - - Descriptive topics related to the content of the ResearchElementDefinition. Topics provide a high-level categorization grouping types of ResearchElementDefinitions that can be useful for filtering and searching. - - - - - An individiual or organization primarily involved in the creation and maintenance of the content. - - - - - An individual or organization primarily responsible for internal coherence of the content. - - - - - An individual or organization primarily responsible for review of some aspect of the content. - - - - - An individual or organization responsible for officially endorsing the content for use in some setting. - - - - - Related artifacts such as additional documentation, justification, or bibliographic references. - - - - - A reference to a Library resource containing the formal logic used by the ResearchElementDefinition. - - - - - The type of research element, a population, an exposure, or an outcome. - - - - - The type of the outcome (e.g. Dichotomous, Continuous, or Descriptive). - - - - - A characteristic that defines the members of the research element. Multiple characteristics are applied with "and" semantics. - - - - - - - - - The ResearchElementDefinition resource describes a "PICO" element that knowledge (evidence, assertion, recommendation) is about. - - - - - - - Define members of the research element using Codes (such as condition, medication, or observation), Expressions ( using an expression language such as FHIRPath or CQL) or DataRequirements (such as Diabetes diagnosis onset in the last year). - - - - - - - - - Use UsageContext to define the members of the population, such as Age Ranges, Genders, Settings. - - - - - When true, members with this characteristic are excluded from the element. - - - - - Specifies the UCUM unit for the outcome. - - - - - A narrative description of the time period the study covers. - - - - - Indicates what effective period the study covers. - - - - - - - - - Indicates duration from the study initiation. - - - - - Indicates how elements are aggregated within the study effective period. - - - - - A narrative description of the time period the study covers. - - - - - Indicates what effective period the study covers. - - - - - - - - - Indicates duration from the participant's study entry. - - - - - Indicates how elements are aggregated within the study effective period. - - - - - - - - - - - Population - - - - - Exposure - - - - - Outcome - - - - - - - The possible types of research elements (E.g. Population, Exposure, Outcome). - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - - - - - - Dichotomous - - - - - Continuous - - - - - Descriptive - - - - - - - The possible types of variables for exposures or outcomes (E.g. Dichotomous, Continuous, Descriptive). - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - A process where a researcher or organization plans and then executes a series of steps intended to increase the field of healthcare-related knowledge. This includes studies of safety, efficacy, comparative effectiveness and other information about medications, devices, therapies and other interventional and investigative techniques. A ResearchStudy involves the gathering of information about human or animal subjects. @@ -38792,333 +38299,6 @@ Deceased patients may also be marked as inactive for the same reasons, but may b - - - The RiskEvidenceSynthesis resource describes the likelihood of an outcome in a population plus exposure state where the risk estimate is derived from a combination of research studies. - - - - - The RiskEvidenceSynthesis resource describes the likelihood of an outcome in a population plus exposure state where the risk estimate is derived from a combination of research studies. - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - An absolute URI that is used to identify this risk evidence synthesis when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this risk evidence synthesis is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the risk evidence synthesis is stored on different servers. - - - - - A formal identifier that is used to identify this risk evidence synthesis when it is represented in other formats, or referenced in a specification, model, design or an instance. - - - - - The identifier that is used to identify this version of the risk evidence synthesis when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the risk evidence synthesis author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. - - - - - A natural language name identifying the risk evidence synthesis. This name should be usable as an identifier for the module by machine processing applications such as code generation. - - - - - A short, descriptive, user-friendly title for the risk evidence synthesis. - - - - - The status of this risk evidence synthesis. Enables tracking the life-cycle of the content. - - - - - The date (and optionally time) when the risk evidence synthesis was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the risk evidence synthesis changes. - - - - - The name of the organization or individual that published the risk evidence synthesis. - - - - - Contact details to assist a user in finding and communicating with the publisher. - - - - - A free text natural language description of the risk evidence synthesis from a consumer's perspective. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate risk evidence synthesis instances. - - - - - A legal or geographic region in which the risk evidence synthesis is intended to be used. - - - - - A copyright statement relating to the risk evidence synthesis and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the risk evidence synthesis. - - - - - The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. - - - - - The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date. - - - - - The period during which the risk evidence synthesis content was or is planned to be in active use. - - - - - Descriptive topics related to the content of the RiskEvidenceSynthesis. Topics provide a high-level categorization grouping types of EffectEvidenceSynthesiss that can be useful for filtering and searching. - - - - - An individiual or organization primarily involved in the creation and maintenance of the content. - - - - - An individual or organization primarily responsible for internal coherence of the content. - - - - - An individual or organization primarily responsible for review of some aspect of the content. - - - - - An individual or organization responsible for officially endorsing the content for use in some setting. - - - - - Related artifacts such as additional documentation, justification, or bibliographic references. - - - - - Type of synthesis eg meta-analysis. - - - - - Type of study eg randomized trial. - - - - - A reference to a EvidenceVariable resource that defines the population for the research. - - - - - A reference to a EvidenceVariable resource that defines the exposure for the research. - - - - - A reference to a EvidenceVariable resomece that defines the outcome for the research. - - - - - A description of the size of the sample involved in the synthesis. - - - - - The estimated risk of the outcome. - - - - - A description of the certainty of the risk estimate. - - - - - - - - - The RiskEvidenceSynthesis resource describes the likelihood of an outcome in a population plus exposure state where the risk estimate is derived from a combination of research studies. - - - - - - - Human-readable summary of sample size. - - - - - Number of studies included in this evidence synthesis. - - - - - Number of participants included in this evidence synthesis. - - - - - - - - - The RiskEvidenceSynthesis resource describes the likelihood of an outcome in a population plus exposure state where the risk estimate is derived from a combination of research studies. - - - - - - - Human-readable summary of risk estimate. - - - - - Examples include proportion and mean. - - - - - The point estimate of the risk estimate. - - - - - Specifies the UCUM unit for the outcome. - - - - - The sample size for the group that was measured for this risk estimate. - - - - - The number of group members with the outcome of interest. - - - - - A description of the precision of the estimate for the effect. - - - - - - - - - The RiskEvidenceSynthesis resource describes the likelihood of an outcome in a population plus exposure state where the risk estimate is derived from a combination of research studies. - - - - - - - Examples include confidence interval and interquartile range. - - - - - Use 95 for a 95% confidence interval. - - - - - Lower bound of confidence interval. - - - - - Upper bound of confidence interval. - - - - - - - - - The RiskEvidenceSynthesis resource describes the likelihood of an outcome in a population plus exposure state where the risk estimate is derived from a combination of research studies. - - - - - - - A rating of the certainty of the effect estimate. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - A description of a component of the overall certainty. - - - - - - - - - The RiskEvidenceSynthesis resource describes the likelihood of an outcome in a population plus exposure state where the risk estimate is derived from a combination of research studies. - - - - - - - Type of subcomponent of certainty rating. - - - - - A rating of a subcomponent of rating certainty. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - - A container for slots of time that may be available for booking appointments. @@ -40396,354 +39576,6 @@ Deceased patients may also be marked as inactive for the same reasons, but may b - - - The Statistic resource codifies a statistical measure and corresponding certainty. - - - - - The Statistic resource codifies a statistical measure and corresponding certainty. - If the element is present, it must have either a @value, an @id, or extensions - - - - - - - An absolute URI that is used to identify this statistic when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which at which an authoritative instance of this statistic is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the statistic is stored on different servers. - - - - - A formal identifier that is used to identify this statistic when it is represented in other formats, or referenced in a specification, model, design or an instance. - - - - - The identifier that is used to identify this version of the statistic when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the statistic author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. - - - - - A short, descriptive, user-friendly title for the statistic. - - - - - The status of this statistic. Enables tracking the life-cycle of the content. - - - - - The date (and optionally time) when the statistic was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the statistic changes. - - - - - The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate evidence instances. - - - - - The date on which the resource content was approved by the publisher. Approval happens once when the content is officially approved for usage. - - - - - The date on which the resource content was last reviewed. Review happens periodically after approval but does not change the original approval date. - - - - - The individual or organization that produced this statistic. - - - - - Contact detail and role for contributor to statistic. - - - - - Link to artifact associated with statistic. - - - - - A free text natural language description of the statistic from a consumer's perspective. - - - - - Footnotes and/or explanatory notes. - - - - - The particular type of synthesis if this is a synthesis statistic. - - - - - The type of study that produced this statistic. - - - - - TBD. - - - - - TBD. - - - - - Exposure or intervention or exposure state. - - - - - Outcome or characteristic that is measured. - - - - - The effect or risk estimate type. - - - - - The statistic value. - - - - - Population sample size. - - - - - An estimate of the precision of the statistic. - - - - - The probability that this statistic would be the same given the null hypothesis. - - - - - A description of the certainty of the effect estimate. - - - - - - - - - The Statistic resource codifies a statistical measure and corresponding certainty. - - - - - - - The name of the publisher. - - - - - Contact details for the publisher. - - - - - - - - - The Statistic resource codifies a statistical measure and corresponding certainty. - - - - - - - Human-readable summary of population sample size. - - - - - Footnote or explanatory note about the sample size. - - - - - Number of participants in the population. - - - - - A human-readable string to clarify or explain concepts about the sample size. - - - - - TBD. - - - - - TBD. - - - - - - - - - The Statistic resource codifies a statistical measure and corresponding certainty. - - - - - - - Human-readable summary of the estimate. - - - - - Footnote or explanatory note about the estimate. - - - - - The estimate type. - - - - - Use 95 for a 95% confidence interval. - - - - - Lower bound of confidence interval. - - - - - Upper bound of confidence interval. - - - - - - - - - The Statistic resource codifies a statistical measure and corresponding certainty. - - - - - - - Human-readable summary of the estimate. - - - - - Footnote or explanatory note about the p value. - - - - - TBD. - - - - - Actual p value. - - - - - TBD. - - - - - - - - - The Statistic resource codifies a statistical measure and corresponding certainty. - - - - - - - Human-readable summary of the certainty. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - A rating of the certainty of the effect estimate. - - - - - A description of a component of the overall certainty. - - - - - - - - - The Statistic resource codifies a statistical measure and corresponding certainty. - - - - - - - Human-readable summary of the subcomponent. - - - - - A human-readable string to clarify or explain concepts about the resource. - - - - - Type of subcomponent of certainty rating. - - - - - A rating of a subcomponent of rating certainty. - - - - - - A definition of a FHIR structure. This resource is used to describe the underlying resources, data types defined in FHIR, and also for describing extensions and constraints on resources and data types. @@ -42463,9 +41295,14 @@ Deceased patients may also be marked as inactive for the same reasons, but may b The molecular weight or weight range (for proteins, polymers or nucleic acids). - + - Supporting literature. + Describes the source of information. + + + + + Supporting literature about the source of information. @@ -42726,9 +41563,9 @@ Deceased patients may also be marked as inactive for the same reasons, but may b - + - For use when the numeric. + For use when the numeric has an uncertain range. diff --git a/input/pagecontent/best-practice.md b/input/pagecontent/best-practice.md index 088bf5c..af02f47 100644 --- a/input/pagecontent/best-practice.md +++ b/input/pagecontent/best-practice.md @@ -1,144 +1,94 @@ -The IG publication tooling enforces lots of validation rules that try to enforce that your implementation guide is 'technically' correct. However, -it's possible to create implementation guides that are 'technically correct', but are going to be problematic for the target implementer community -or for the implementer community at large. - -This page tries to consolidate a number of recommendations/best practices for creating "good" IGs that will be easy to understand by developers, -will be consistent with other IGs and will create specifications that reduce implementation costs for the community as a whole (and as a result, -hopefully result in increased/faster adoption. - -The guidance here is not static. New recommendations will be added and existing recommendations will be reworded, clarified or even removed based on -feedback from the community. At some point, we may even seek formal review of the content listed here. +The IG publication tooling enforces lots of validation rules that try to enforce that your implementation guide is 'technically' correct. However,it's possible to create implementation guides that are 'technically correct', but are going to be problematic for the target implementer communityor for the implementer community at large.This page tries to consolidate a number of recommendations/best practices for creating "good" IGs that will be easy to understand by developers,will be consistent with other IGs and will create specifications that reduce implementation costs for the community as a whole (and as a result,hopefully result in increased/faster adoption.The guidance here is not static. New recommendations will be added and existing recommendations will be reworded, clarified or even removed based onfeedback from the community. At some point, we may even seek formal review of the content listed here. ### Writing and narrative -* Your best technical person may not be your best technical writer. Try to have documentation written by people who know how to write and communicate, -rather than presuming that someone who knows how to write super-awesome FHIRPath and can code slice discriminators in their sleep is going to be good at -writing intuitive, clear and concise IG text. -* Write for your primary audience – generally software developers. That means: - * Avoiding medical jargon or any language that wouldn't be familiar to a non-clinical lay-person. - * If specific medical terms must be used because they're intrinsically tied to the purpose of the implementation guide, then either point to directly - include a 'primary' that provides a simple overview of the relevant concepts that would be easily consumable by a non-clinician - * Use hyperlinks or flyovers for complex terms to provide definitions -* Keep documentation brief and focus on what software developers must know in order to implement. - * It should be possible for a developer to skim an IG and have a pretty good idea of what's in the IG, how it relates to what they need and how long it'll - take to implement in ~30 minutes. If it takes more than an hour, the IG is probably too complex or doesn't have appropriate overview/explanatory text and - diagrams. -* Make your IG navigable. Use hyperlinks wherever possible – both to content that exists within the implementation guide as well to external sources that -provide additional "drill-down" information. The only time a hyperlink isn't appropriate is when the concept has already been linked to within the same -couple of paragraphs of a single section. +* Your best technical person may not be your best technical writer. Try to have documentation written by people who know how to write and communicate,rather than presuming that someone who knows how to write super-awesome FHIRPath and can code slice discriminators in their sleep is going to be good at writing intuitive, clear and concise IG text. +* Write for your primary audience – generally software developers. That means: + * Avoiding medical jargon or any language that wouldn't be familiar to a non-clinical lay-person. + * If specific medical terms must be used because they're intrinsically tied to the purpose of the implementation guide, then either point to directly include a 'primary' that provides a simple overview of the relevant concepts that would be easily consumable by a non-clinician + * Use hyperlinks or flyovers for complex terms to provide definitions + * Keep documentation brief and focus on what software developers must know in order to implement. + * It should be possible for a developer to skim an IG and have a pretty good idea of what's in the IG, how it relates to what they need and how long it'll take to implement in ~30 minutes. If it takes more than an hour, the IG is probably too complex or doesn't have appropriate overview/explanatory text and diagrams. +* Make your IG navigable. Use hyperlinks wherever possible – both to content that exists within the implementation guide as well to external sources that provide additional "drill-down" information. The only time a hyperlink isn't appropriate is when the concept has already been linked to within the same couple of paragraphs of a single section. * This includes both page content as well as intro and notes sections and even definitions and usage notes within profiles. -* Design the order of presentation of content in the implementation guide such that reading from start to end presents information in a logical order. -However, don't presume that readers will navigate in order. They may jump directly into the middle of the IG and navigate at random through the content -based on their instance. As such, both backward and forward hyperlinks are appropriate – especially for content in distinct sections. -* Single, large pages are better then numerous short pages - * Single pages can easily be searched using Ctrl-F and can be scrolled around to see related content. Multiple small pages make it easy to get lost - and/or misscontent -* Put "good" anchor names on all pages (harder to do this for markdown) - * You never know when someone might need to link to a particular page in the spec. While, the publisher will auto-generate link points, these will be - version-specific. The anchor names you define will persist across versions -* Put intros on all artifacts - * Every artifact should have text that explains what it's for and where it fits in the grand scheme of things (including how it's different from potentially - related artifacts. +* Design the order of presentation of content in the implementation guide such that reading from start to end presents information in a logical order. However, don't presume that readers will navigate in order. They may jump directly into the middle of the IG and navigate at random through the content based on their instance. As such, both backward and forward hyperlinks are appropriate – especially for content in distinct sections. +* Single, large pages are better then numerous short pages + * Single pages can easily be searched using Ctrl-F and can be scrolled around to see related content. Multiple small pages make it easy to get lost and/or misscontent +* Put "good" anchor names on all pages (see how to do this for markdown using kramdown syntax) +* You never know when someone might need to link to a particular page in the spec. While, the publisher will auto-generate link points, these will be version-specific. The anchor names you define will persist across versions +* Put introductions on all artifacts + * Every artifact should have text that explains what it's for and where it fits in the grand scheme of things (including how it's different from potentially related artifacts. * If it's a complex artifact, include usage notes too. * Use aliases to ensure that common domain terms will show up when searching -* If there's controversy about why something is the way it is or it's driven by subtle/non-widely-understood requirements, be sure to capture the reasons -for the current design in rationale so that future maintainers can take that information into account when designing +* If there's controversy about why something is the way it is or it's driven by subtle/non-widely-understood requirements, be sure to capture the reasons for the current design in rationale so that future maintainers can take that information into account when designing * The index page should always start with a patient-friendly explanation of the purpose of the IG - ### Images and Diagrams - * Diagrams can be very helpful, but it takes time to do them well. Don't leave them until the last minute * Try to ensure that pictures have a consistent color scheme and visual approach * Make sure embedded graphics can be distributed under a CC-no-attribution license (or provide attribution if that's required under the open-source license) * Make sure the source for the graphic is checked in and that the authoring tool is either free or widely used. Don't use esoteric websites that might not be around in 5-10 years or formats that are unlikely to be convertable. - +* Use SVG format whenever possible for crisp and clean image at any size* ### Artifacts - -* Manage artifact volume - * Consider "What is computably useful?" - I.e. What do you actually need to validate automatically and what might be better (more clear) as text - * In some cases, consider producing both a computable and 'human' friendly profile where the formeris a constraint on the latter - * At the same time, do try to be computable most of the time. Human-readable text is frequently ambiguous and very expensive to enforce - * What is reasonably reviewable/implementable? Yes, you could write 200 profiles. However, if balloters can't realistically check all of them and confirm - that they're correct and/or implementers aren't going to be able to implement that sort of volume in the next 5 years, you're wasting your time - * Also consider long-term maintenance. Every artifact you introduce is going to need to be maintained for 10-20 years, maybe longer. Make sure there's - a good reason for the resource to exist -* Use appropriate artifacts. Implementation Guides can (and should) contain more than just profiles - * Use capability statements to define what interface capabilities implementers are expected to support (including using extensions to differentiate - MAY/SHOULD/SHALL) - * OperationDefinition, NamingSystem, MessageDefinition, GraphDefinition, Questionnaire, etc. are all available - +* Manage artifact volume + * Consider "What is computably useful?" - I.e. What do you actually need to validate automatically and what might be better (more clear) as text + * In some cases, consider producing both a computable and 'human' friendly profile where the former is a constraint on the latter + * At the same time, do try to be computable most of the time. Human-readable text is frequently ambiguous and very expensive to enforce + * What is reasonably reviewable/implementable? Yes, you could write 200 profiles. However, if balloters can't realistically check all of them and confirm that they're correct and/or implementers aren't going to be able to implement that sort of volume in the next 5 years, you're wasting your time + * Also consider long-term maintenance. Every artifact you introduce is going to need to be maintained for 10-20 years, maybe longer. Make sure there's a good reason for the resource to exist +* Use appropriate artifacts. Implementation Guides can (and should) contain more than just profiles +* Use capability statements to define what interface capabilities implementers are expected to support (including using extensions to differentiate MAY/SHOULD/SHALL) +* OperationDefinition, NamingSystem, MessageDefinition, GraphDefinition, Questionnaire, etc. are all available ### Profiles - * Use mustSupport to identify what must be supported, not cardinality -* Try to allow for existing/legacy data unless you're happy to throw it all away. - * 0..1, mustSupport allows for missing data while still setting expectations for data sharing -* Avoid constraining 'max' - * It's better to slice and set constraints that let you extract the specific repetition(s) you need than to prevent others from sending the data they have - * If you constrain max, it means you're forcing implementations to create a custom implementation interface that just strips data out that could be - ignored for free -* Be cautious about constraints enforcing business rules - * legacy data and/or external data may not comply - * business rules will often change more frequently than systems do (and aren't constrained by backward-compatibility rules) - * different systems may have different business rules - * Instead, only enforce constraints that you're confident will stand the test of time. Other constraints can be expressed as usage notes to warn implementers - about what's 'currently expected' and/or handled as business rules within the system. (It's totally fine to reject instances that pass profile validation - because they fail context-specific business rules.) - - -### Terminology - -* Leverage external terminologies whenever you can. +* Try to allow for existing/legacy data unless you're happy to throw it all away. +* 0..1, mustSupport allows for missing data while still setting expectations for data sharing +* Avoid constraining 'max' + * It's better to slice and set constraints that let you extract the specific repetition(s) you need than to prevent others from sending the data they have + * If you constrain max, it means you're forcing implementations to create a custom implementation interface that just strips data out that could be ignored for free +* Be cautious about constraints enforcing business rules + * legacy data and/or external data may not comply + * business rules will often change more frequently than systems do (and aren't constrained by backward-compatibility rules) + * different systems may have different business rules + * Instead, only enforce constraints that you're confident will stand the test of time. Other constraints can be expressed as usage notes to warn implementers about what's 'currently expected' and/or handled as business rules within the system. (It's totally fine to reject instances that pass profile validation because they fail context-specific business rules.)### Terminology +* Leverage external terminologies whenever you can. * For higher maturity, expectation is that you're using external terminologies for non-'code' elements unless it's simply not possible -* You *cannot* create 'required' or 'extensible' bindings to terminologies that aren't "free for use" in the realm that you're implementing in + * You cannot create 'required' or 'extensible' bindings to terminologies that aren't "free for use" in the realm that you're implementing in * SNOMED CT is ok in US IGs, but not in international IGs (unless SNOMED has granted an open license for everyone to freely use those codes) -* If you need to define temporary FHIR codes for low-maturity artifacts as you're just experimenting, make very clear that they're "temporary" -* If using terminologies that use advanced capabilities (subsumption, post-coordination, or even value set expansions), consider whether the implementation -community is likely to support these. -* Be cautious of 'required' bindings that don't have an "other" - * If there's a required binding and the element is min=1, then you can't send the instance if no code exists. + * If you need to define temporary FHIR codes for low-maturity artifacts as you're just experimenting, make very clear that they're "temporary" +* If using terminologies that use advanced capabilities (subsumption, post-coordination, or even value set expansions), consider whether the implementation community is likely to support these. +* Be cautious of 'required' bindings that don't have an "other" + * If there's a required binding and the element is min=1, then you can't send the instance if no code exists. * Ensure an escape valve exists if one is needed (including for legacy content) * If you can't use required or extensible, try to at least define "preferred" if interoperability matters for an element -* Consider whether vocabulary bindings should be "locked" to the IG version or unconstrained - * Version-specific means the definition will be more stable, but means the only way to update the codes used is to release a new version of the IG. - sometimes that's desirable, sometimes not -* Don't use OIDs to identify code systems or identifiers - * When implementaters have v3 experience, they may well have OIDs for some of these. Because you can prefix the OID with "uri:oid:" and get a valid URN, - the temptation will be to do this because it's cheaper and it eases conversion. However, it increases the costs for the community as a whole. - * OIDs are *not* human readable which makes errors easier and debugging harder +* Consider whether vocabulary bindings should be "locked" to the IG version or unconstrained + * Version-specific means the definition will be more stable, but means the only way to update the codes used is to release a new version of the IG. sometimes that's desirable, sometimes not +* Don't use OIDs to identify code systems or identifiers + * When implementaters have v3 experience, they may well have OIDs for some of these. Because you can prefix the OID with "uri:oid:" and get a valid URN, the temptation will be to do this because it's cheaper and it eases conversion. However, it increases the costs for the community as a whole. + * OIDs are not human readable which makes errors easier and debugging harder * OIDs cannot be resolved, which removes a helpful tool for implementers trying to discover what a code means or an identifier refers to - * Most of the world understands the concept of an identifier. Few understand OIDs. Using OIDs means that you incur a permanent learning curve for your - specification - * If FHIR has defined a standard URL for a code system/identifier type, you have no choice but to use the HL7 code - the v3 OID isn't allowed - * The NamingSystem resource exists to allow simple translation - + * Most of the world understands the concept of an identifier. Few understand OIDs. Using OIDs means that you incur a permanent learning curve for your specification + * If FHIR has defined a standard URL for a code system/identifier type, you have no choice but to use the HL7 code - the v3 OID isn't allowed +* The NamingSystem resource exists to allow simple translation ### Examples - * Include examples that showcase all key parts of the IG * Include comments in your examples (this means authoring should be done in XML) * At least one example should highlight every must-support element and every extension defined within the IG - ### Extensions - -* Before defining a new extension: - * Consider whether anything in core could be used - * Look at existing core and IG extensions - * Consult with the responsible work group and chat.fhir.org - * If a new extension is needed, consider if it can be made generic enough that it could be used in other spaces and would be appropriate to register as an HL7 'core' extension +* Before defining a new extension: +* Consider whether anything in core could be used + * Look at existing core and IG extensions + * Consult with the responsible work group and chat.fhir.org +* If a new extension is needed, consider if it can be made generic enough that it could be used in other spaces and would be appropriate to register as an HL7 'core' extension * Create extensions nested inside the elements they apply to rather than at the root - ### General - -* Keep in mind that you might well not always be the primary author of the IG, so ensure all relevant source material is under source control and that -content is organized and named intuitively. Artifacts need to be in 'standard' formats. -* Even for closed projects, IGs should be developed in consultation with the open community - * Ask questions and share what you're up to on chat.fhir.org so you're aware of other work you can leverage/align with and so you can take advantage of the - knowledge of the broader community - * Seek engagement from the relevant work group. (Remember, they're going to have to endorse your IG's design approach before it can get to higher maturity - levels or normative – you don't want to have to make significant design changes late in the process.) -* Copy and paste the text of your IGs into MS Word or an equivalent tool to do full grammar and spell checking on the content +* Keep in mind that you might well not always be the primary author of the IG, so ensure all relevant source material is under source control and that content is organized and named intuitively. Artifacts need to be in 'standard' formats. +* Even for closed projects, IGs should be developed in consultation with the open community +* Ask questions and share what you're up to on chat.fhir.org so you're aware of other work you can leverage/align with and so you can take advantage of the knowledge of the broader community +* Seek engagement from the relevant work group. (Remember, they're going to have to endorse your IG's design approach before it can get to higher maturity levels or normative – you don't want to have to make significant design changes late in the process.) +* Copy and paste the text of your IGs into MS Word or an equivalent tool to do full grammar and spell checking on the content or use the spell checking features in your favorite text editor on the source. diff --git a/input/pagecontent/using-templates.xml b/input/pagecontent/using-templates.xml index ec3642f..5e2d84c 100644 --- a/input/pagecontent/using-templates.xml +++ b/input/pagecontent/using-templates.xml @@ -13,7 +13,7 @@ The result is a set of HTML pages that, together, provide a human-readable (and navigable) description of the IG's rules and contents.

- This section of the implementation guide is broken into two sub-sections. The first describes how to author an implementation guide that leverages one + This section of the implementation guide is broken into two sub-sections. The first describes how to author an implementation guide that leverages one of the standard templates. The second provides a walkthrough of the pages within the rendered implementation guide.

@@ -21,23 +21,168 @@

Authoring Templates

The process of authoring implementation guides is an iterative sequence of steps where artifacts are first created and edited and then the "publication - " process is run (or the "IG is 'built'") to produce a rendered view of the content as well as a set of feedback on the IG's quality, such as whether + " process is run (or the "IG is 'built'") to produce a rendered view of the content as well as a set of feedback on the IG's quality, such as whether the artifacts and examples validate correctly, whether links resolve, etc.

- After reviewing the rendered content and/or quality feedback, the IG author goes back to the editing process until they are comfortable with the + After reviewing the rendered content and/or quality feedback, the IG author goes back to the editing process until they are comfortable with the content, it which point the content generated by the publication process can be distributed or posted for use by the target community.

-

Directory Structure

+

Directory Structure (file tree)

- The content used by (and produced by) the publication process is organized into a set of directories. The template depends on the source content - being organized into a specific set of source folders. The temporary work products and final results of the publication process will also be put + The content used by (and produced by) the publication process is organized into a set of directories. The template depends on the source content + being organized into a specific set of source folders. The temporary work products and final results of the publication process will also be put into a standard named set of folders.

- The base directory structure for the IG publisher is as follows: + The base directory structure for the IG publisher before invoking the build to import the standard template will look something like this: +

+ +~~~ +. +├── LICENSE +├── README.md +├── _genonce.bat +├── _updatePublisher.bat +├── ig.ini +├── input +│   ├── howto.xml +│   ├── ignoreWarnings.txt +│   ├── includes +│   │   └── menu.xml +│   │   ├── ... +│   ├── pagecontent +│   │   ├── index.xml +│   │   ├── guidance.xml +│   │   ├── fhir-artifact.xml +│   │   ├── security.xml +│   │   ├── examples.xml +│   │   ├── downloads.xml +│   └── resources +│   ├── StructureDefinition-123.xml +│   ├── CodeSystem-123.xml +│   ├── CapabilityStatement-123.xml +│   ├── ConceptMap-123.xml +│   ├── OperationDefinition-123.xml +│ ├── SearchParameter-123.xml +│   ├── StructureMap-123.xml +│   └── ValueSet-123.xml +└── input-cache + ├── schemas-r5 + │   ├── fhir-single.xsd + │   ├── fhir-xhtml.xsd + │   ├── xml.xsd + │   └── xmldsig-core-schema.xsd + └── txcache + ├── ... + +~~~ + +

+ The directory structure after invoking the build, importing the standard template, and completing the build will look something like this:

+ + +~~~ +. +├── LICENSE +├── README.md +├── _genonce.bat +├── _updatePublisher.bat +├── ig.ini +├── input +│   ├── howto.xml +│   ├── ignoreWarnings.txt +│   ├── includes +│   │   └── menu.xml +│   │   ├── ... +│   ├── pagecontent +│   │   ├── index.xml +│   │   ├── guidance.xml +│   │   ├── fhir-artifact.xml +│   │   ├── security.xml +│   │   ├── examples.xml +│   │   ├── downloads.xml +│   └── resources +│   ├── StructureDefinition-123.xml +│   ├── CodeSystem-123.xml +│   ├── CapabilityStatement-123.xml +│   ├── ConceptMap-123.xml +│   ├── OperationDefinition-123.xml +│ ├── SearchParameter-123.xml +│   ├── StructureMap-123.xml +│   └── ValueSet-123.xml +├── input-cache +│ ├── schemas-r5 +│ │   ├── fhir-single.xsd +│ │   ├── fhir-xhtml.xsd +│ │   ├── xml.xsd +│ │   └── xmldsig-core-schema.xsd +│ └── txcache +│ ├── ... +│ +├── output +│   ├── ImplementationGuide-hl7.fhir.uv.howto.json +│   ├── ImplementationGuide-hl7.fhir.uv.howto.ttl +│   ├── ImplementationGuide-hl7.fhir.uv.howto.xml +│   ├── artifacts.html +│   ├── assets +.... +├── publish.sh +├── temp +... +│   └── qa +... +└── template + ├── README.md + ├── cache.ini + ├── config + │   └── _config.yml + ├── config.json + ├── content + │   ├── assets + │   │   ├── css + │   │   │   ├── bootstrap-fhir.css + │   │   │   ├── ... + │   │   ├── fonts + │   │   │   ├── glyphiconshalflings-regular.eot + │   │   │   ├── ... + │   │   ├── ico + │   │   │   ├── apple-touch-icon-114-precomposed.png + │   │   │   ├── ... + │   │   ├── images + │   │   │   ├── fhir-logo-www.png + │   │   │   ├── ... + │   │   └── js + │   │   ├── anchor.min.js + │   │   ├── ... + │   └── jquery.js + ├── includes + │   ├── fragment-pagebegin.html + │   ├── ... + ├── layouts + │   ├── default.html + │   ├── fhir-artifact.html + │   ├── ... + ├── onGenerate-ig-updated.xml + ├── onGenerate-ig-working.1.xml + ├── onGenerate-ig-working.json + ├── onGenerate-ig-working.xml + ├── onLoad-ig-updated.xml + ├── onLoad-ig-working.json + ├── onLoad-ig-working.xml + ├── onLoad-validation-checkPublisher.json + ├── onLoad-validation.json + ├── package + │   └── package.json + ├── scripts + │   ├── ant.xml + │   ├── ... + └── var + └── lib +~~~ + @@ -50,41 +195,41 @@ - - - - - @@ -92,11 +237,74 @@

Authors may include additional folders at the root level, but they will be ignored by the publication process.

+ + +
[root]/input

- The contents of the temp and template folder are not described here as only those who author and maintain Implementation Guide templates will need + The files that define the content of the IG, as well as those that guide the publication process are all found in this folder. The key contents + are as follows: +

+
[root]

- The root folder can be anywhere in the user's directory structure. It does need to be a folder where the user has free permission to create + The root folder can be anywhere in the user's directory structure. It does need to be a folder where the user has free permission to create and edit files without additional administrative privileges.

- In addition to containing the folders below, this folder contains a number of files related to the execution of the publication process and + In addition to containing the folders below, this folder contains a number of files related to the execution of the publication process and that support the automated execution of the process on continuous integration build environments.

[root]/inputFolder where all source files are maintained. This is the only folder that needs to exist for a 'new' project. The contents of this folder + Folder where all source files are maintained. This is the only folder that needs to exist for a 'new' project. The contents of this folder should generally be managed under source control. (E.g. Git)
[root]/input-cacheContains downloaded and/or generated files that are typically retained across multiple runs of the publisher. Some of the contents of this + Contains downloaded and/or generated files that are typically retained across multiple runs of the publisher. Some of the contents of this folder will typically also be managed under source control for performance reasons. (Further discussion below.)
[root]/outputThis contains the results of the publication process. The content in this folder is a set of static web pages and other artifacts that are + This contains the results of the publication process. The content in this folder is a set of static web pages and other artifacts that are intended to be posted/shared with those who need to read/use the implementation guide.
[root]/tempContains files produced as part of the publication process. The contents of this folder are wiped and re-generated each time the publication - process is run. They are retained after the publication run for diagnostic/debugging purposes in the event of issues with the publication + Contains files produced as part of the publication process. The contents of this folder are wiped and re-generated each time the publication + process is run. They are retained after the publication run for diagnostic/debugging purposes in the event of issues with the publication process. However, the content can be freely deleted to make extra space
[root]/templateThis contains files retrieved from the template repository that determine how source files are modified as part of the publication process - and what the rendered view of different artifacts will look like, including color scheme , formatting, navigation, etc. Like the temp folder, - it is regenerated for each run of the publication process and is only retained for diagnostic/debugging purposes. It can be deleted to free + This contains files retrieved from the template repository that determine how source files are modified as part of the publication process + and what the rendered view of different artifacts will look like, including color scheme , formatting, navigation, etc. Like the temp folder, + it is regenerated for each run of the publication process and is only retained for diagnostic/debugging purposes. It can be deleted to free space.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
File / FolderDescription
[ig-id].[xml | json]This is the Implementation Guide resource. It defines key resource metadata, including the base table of contents for the IG. + Specific requirements for the id and contents of this resource when used with the HL7 template are found below
ignoreWarnings.txtThis file can be populated with any QA warning and information messages that should be ignored by the publication process. See + QA for more details
[resource folder(s)] +

+ There are several folders that can be used to contain resource content. In some cases, none of the folders will be present (because the + IG doesn't define any resources). In other cases, many will be present. The choice of which folders to use (and what to put in them) is + driven by author convenience. Some authors will prefer to shove all resources into the 'resources' folder. Others will prefer to split + contents apart based on the type of artifact. This will be particularly common when different users are expected to maintain different types + of artifacts. No checking is done about which artifact types are allowed in each folder. However, to minimize confusion, only artifacts + that are 'appropriate' based on the name of the folder should go in that folder. +

+

+ The potential folder names supported by the template are: +

+
    +
  • capabilities (for CapabilityStatements/Conformance resources)
    • +
  • examples
    • +
  • extensions
    • +
  • models (for logical models)
    • +
  • operations
    • +
  • profiles
    • +
  • resources (for anything/everything)
    • +
  • vocabulary (for code systems & value sets)
    • +
+
[page folder(s)]
+ + +

+ The contents of the temp and template folder are not described here as only those who author and maintain Implementation Guide templates will need to concern themselves with the contents of those locations. The remaining directories are discussed in more detail below.

- +
[root]

@@ -117,8 +325,8 @@

This key file has two key parameters:

  • "ig" indicates the path to the file containing the implementation guide XML or JSON file. (Typically this will be in the 'input' folder.)
    • -
  • "template" specifies the id, URL or local filepath of the IG template to use as part of the publication process. The - 'id' approach can only be used if the template is 'trusted' by the IG Publisher and is managed in FHIR.org's continuous integration build +
  • "template" specifies the id, URL or local filepath of the IG template to use as part of the publication process. The + 'id' approach can only be used if the template is 'trusted' by the IG Publisher and is managed in FHIR.org's continuous integration build (CI-build) environment
@@ -126,18 +334,18 @@ _updatePublisher[.bat | .sh] This process retrieves the current version of the HL7 IG Publisher. It must be run before the publication process can be launched. - The IG Publisher changes on a regular basis as enhancements are made and bugs are fixed. A warning will appear in the publication output + The IG Publisher changes on a regular basis as enhancements are made and bugs are fixed. A warning will appear in the publication output if the version of the publisher used is out of date. A severely out-of-date publisher may occasionally cause the build process to fail. (So the first step in any publication failure is to make sure you're running with the latest publisher.) _genonce[.bat | .sh] - This initiates the publication process. Launching the .bat file (Windows) or .sh file (Unix/Mac) will launch HL7's IGPublisher program and + This initiates the publication process. Launching the .bat file (Windows) or .sh file (Unix/Mac) will launch HL7's IGPublisher program and build/publish the IG one time. _gencontinuous[.bat | .sh] - This initiates the publication process. Launching the .bat file (Windows) or .sh file (Unix/Mac) will launch HL7's IGPublisher program in + This initiates the publication process. Launching the .bat file (Windows) or .sh file (Unix/Mac) will launch HL7's IGPublisher program in 'continuous' mode. See Invoking the IG Publisher. @@ -148,9 +356,9 @@

- HL7 international and many FHIR.org projects make use of Github as a source control environment. For those projects, the following additional files + HL7 international and many FHIR.org projects make use of Github as a source control environment. For those projects, the following additional files will likely be in your [root] folder: -

+

@@ -165,8 +373,8 @@ - @@ -180,66 +388,6 @@
LICENSEA standard file used by Github to indicate what open-source license applies to the contents of the repository. For implementation guides - published by HL7 International (including accelerator projects such as Da Vinci that use the HL7 ballot process), this must refer to HL7's + A standard file used by Github to indicate what open-source license applies to the contents of the repository. For implementation guides + published by HL7 International (including accelerator projects such as Da Vinci that use the HL7 ballot process), this must refer to HL7's FHIR license and the CC0 license.
- -
[root]/input
-

- The files that define the content of the IG, as well as those that guide the publication process are all found in this folder. The key contents - are as follows: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
File / FolderDescription
[ig-id].[xml | json]This is the Implementation Guide resource. It defines key resource metadata, including the base table of contents for the IG. - Specific requirements for the id and contents of this resource when used with the HL7 template are found below
ignoreWarnings.txtThis file can be populated with any QA warning and information messages that should be ignored by the publication process. See - QA for more details
[resource folder(s)] -

- There are several folders that can be used to contain resource content. In some cases, none of the folders will be present (because the - IG doesn't define any resources). In other cases, many will be present. The choice of which folders to use (and what to put in them) is - driven by author convenience. Some authors will prefer to shove all resources into the 'resources' folder. Others will prefer to split - contents apart based on the type of artifact. This will be particularly common when different users are expected to maintain different types - of artifacts. No checking is done about which artifact types are allowed in each folder. However, to minimize confusion, only artifacts - that are 'appropriate' based on the name of the folder should go in that folder. -

-

- The potential folder names supported by the template are: -

-
    -
  • capabilities (for CapabilityStatements/Conformance resources)
    • -
  • examples
    • -
  • extensions
    • -
  • models (for logical models)
    • -
  • operations
    • -
  • profiles
    • -
  • resources (for anything/everything)
    • -
  • vocabulary (for code systems & value sets)
    • -
-
[page folder(s)]
Key files @@ -256,4 +404,4 @@ Extensions Value Sets Examples and other resoruces - \ No newline at end of file + diff --git a/publish.sh b/publish.sh new file mode 100644 index 0000000..8a4a2b8 --- /dev/null +++ b/publish.sh @@ -0,0 +1,67 @@ +#!/bin/bash +# exit when any command fails +set -e +while getopts ds:twopl option +do + case "${option}" + in + t) NA='N/A';; + w) WATCH=1;; + o) PUB=1;; + p) UPDATE=1;; + l) LOAD_TEMPLATE='ig.ini';; + esac +done +echo "=================================================================" +echo === Publish $SOURCE IG!!! $(date -u) === +echo see 'local workflow.md' file for how to use +echo "Optional Parameters" +echo '-t parameter for no terminology server (run faster and offline)= ' $NA +echo '-w parameter for using watch on igpublisher from source default is off = ' $WATCH +echo '-o parameter for running previous version of the igpublisher= ' $PUB +echo '-p parameter for downloading latest version of the igpublisher from source = ' $UPDATE +echo '-l parameter for downloading HL7 ig template from source = ' $LOAD_TEMPLATE +echo ' current directory =' $PWD +echo "=================================================================" +echo getting rid of .DS_Store files since they gum up the igpublisher.... +find . -name '.DS_Store' -type f -delete +sleep 1 +# git status +if [[ $UPDATE ]]; then +echo "========================================================================" +echo "Downloading most recent publisher to:" +echo ~/Downloads/org.hl7.fhir.igpublisher.jar +echo "... it's ~100 MB, so this may take a bit" +echo "========================================================================" +mv ~/Downloads/org.hl7.fhir.igpublisher.jar ~/Downloads/org.hl7.fhir.igpublisher-old.jar +curl -L https://github.com/FHIR/latest-ig-publisher/raw/master/org.hl7.fhir.publisher.jar -o ~/Downloads/org.hl7.fhir.igpublisher.jar +echo "=========================== Done ====================================" +sleep 3 +fi + +template=$PWD/template +if [[ $LOAD_TEMPLATE ]]; then +template=hl7.fhir.template +fi +echo "=================================================================" +echo load the hl7 template by setting $PWD/ig.ini template = $template +echo "=================================================================" +sed -i'.bak' -e "s|^template = .*|template = ${template}|" $PWD/ig.ini + +path=~/Downloads/org.hl7.fhir.igpublisher.jar +if [[ $PUB ]]; then +path=~/Downloads/org.hl7.fhir.igpublisher-old.jar +fi + +if [[ $WATCH ]]; then + echo "=================================================================" + echo ===run most recent version of the igpublisher with watch on === + echo "=================================================================" + java -jar ${path} -ig ig.ini -watch -tx $NA +else + echo "=================================================================" + echo ===run igpublisher just once \(no watch option\)=== + echo "=================================================================" + echo java -jar ${path} -ig ig.ini -tx $NA + java -jar ${path} -ig ig.ini -tx $NA +fi From dedcb022222143364a8171d8bf36d35a3d87eda1 Mon Sep 17 00:00:00 2001 From: Healthedata1 Date: Wed, 16 Oct 2019 17:55:45 -0700 Subject: [PATCH 2/2] add file trees to using-templates, grid style to tables,edits and markdown formating to best-practices.md --- ig.ini | 4 ++-- ig.ini.bak | 13 +++++++++++++ input/pagecontent/using-templates.xml | 16 ++++++++-------- publish.sh | 2 +- 4 files changed, 24 insertions(+), 11 deletions(-) create mode 100644 ig.ini.bak diff --git a/ig.ini b/ig.ini index ff36b31..c572e62 100644 --- a/ig.ini +++ b/ig.ini @@ -1,6 +1,6 @@ [IG] ig = input/howto.xml -template = hl7.fhir.template +template = /Users/ehaas/Documents/FHIR/FHIR-IG-Guidance/template usage-stats-opt-out = false copyrightyear = 2019+ license = CC0-1.0 @@ -10,4 +10,4 @@ fhirspec = http://build.fhir.org/ #excludexml = Yes #excludejson = Yes #excludettl = Yes -#excludeMaps = Yes \ No newline at end of file +#excludeMaps = Yes diff --git a/ig.ini.bak b/ig.ini.bak new file mode 100644 index 0000000..c572e62 --- /dev/null +++ b/ig.ini.bak @@ -0,0 +1,13 @@ +[IG] +ig = input/howto.xml +template = /Users/ehaas/Documents/FHIR/FHIR-IG-Guidance/template +usage-stats-opt-out = false +copyrightyear = 2019+ +license = CC0-1.0 +version = 0.1.0 +ballotstatus = CI Build +fhirspec = http://build.fhir.org/ +#excludexml = Yes +#excludejson = Yes +#excludettl = Yes +#excludeMaps = Yes diff --git a/input/pagecontent/using-templates.xml b/input/pagecontent/using-templates.xml index 5e2d84c..d55529e 100644 --- a/input/pagecontent/using-templates.xml +++ b/input/pagecontent/using-templates.xml @@ -39,7 +39,7 @@ The base directory structure for the IG publisher before invoking the build to import the standard template will look something like this:

-~~~ +
 .
 ├── LICENSE
 ├── README.md
@@ -77,14 +77,14 @@
     └── txcache
         ├── ...
 
-~~~
+

The directory structure after invoking the build, importing the standard template, and completing the build will look something like this:

-~~~ +
 .
 ├── LICENSE
 ├── README.md
@@ -181,9 +181,9 @@
     │   ├── ...
     └── var
         └── lib
-~~~
+
- +
@@ -244,7 +244,7 @@ The files that define the content of the IG, as well as those that guide the publication process are all found in this folder. The key contents are as follows:

-
Folder
+
@@ -311,7 +311,7 @@ This contains several files that drive the publication process. It may also contain additional files relating to source control or other processes. The files are listed in the order in which they're typically authored/used rather than in alphabetical order.

-
File / Folder
+
@@ -359,7 +359,7 @@ HL7 international and many FHIR.org projects make use of Github as a source control environment. For those projects, the following additional files will likely be in your [root] folder:

-
File
+
diff --git a/publish.sh b/publish.sh index 8a4a2b8..0da051c 100644 --- a/publish.sh +++ b/publish.sh @@ -14,7 +14,7 @@ do done echo "=================================================================" echo === Publish $SOURCE IG!!! $(date -u) === -echo see 'local workflow.md' file for how to use +echo to run from command line '"bash publish.sh [parameters]"' echo "Optional Parameters" echo '-t parameter for no terminology server (run faster and offline)= ' $NA echo '-w parameter for using watch on igpublisher from source default is off = ' $WATCH
File