Crafting this site has been one of the most fun-filled experiences I've had in the past 2 years. Through this blog post, I intend to give you a glimpse of my journey making a static website.
You might have noticed that this site is hosted on Github Pages, but things were different in 2016 when I had no clue what Github was. For a noob who had no experience in [ Git, HTML, CSS, Javascript ], Wordpress came as a savior. Within two hours or so my first website was up and running. It was later the next day that I realized the speed and ease of use came at a major cost, not only was the site unintuitive but managing it was an ordeal.
It was in 2018, when I was again determined to create my site. After a brief stint with Jekyll ( which gave me the old Wordpress vibes ), I decided it was time to start experimenting. I had the following objectives in my mind:
With the above principles, I hosted the site on Github Pages but it was far from perfect. One of the most important aspects of web design is accessibility. With monospace as the default font, text inside <pre> tags, and no use of viewport property the site was inaccessible.
The following months went into creating a blog section and making the site more accessible. I also added a native dark mode and syntax highlighting for my blogs ( both in JS ). From my experience, three things have to be taken care of when using JS on the web - is the site accessible without it, does it seriously affect performance and lastly does it violate user's privacy. A lot of web developers feel that screen readers, no-JS users, and text-based browsers are not worth supporting, while I hold a contradicting opinion, I strongly believe every page should fail gracefully. A brilliant discussion discussing the pros and cons of supporting no-JS has been conducted on Stack Exchange.
My priorities for this site have drastically changed since 2019. Today I use a custom Markdown-to-HTML parser to write these blog posts. Producing quality content, making the site accessible to all devices out there and complementing all that with a clean UI are the only objectives I am aiming at.
Finally, I would like to end the blog post with a collection of web design and internet-architecture related links you might find interesting:


Levels of stress and depression rose steadily in the United States as the coronavirus pandemic worsened, researchers reported Friday. Their study of more than 6,500 people shows conflicting messages on news and social media may have worsened people’s stress, the researchers reported in the journal Science Advances.
Read moreEuropean countries announced new coronavirus restrictions Friday, one day after the World Health Organization warned infections have started to spread again across the continent at “alarming rates.”
Read moreSome people who become ill with the coronavirus develop neurological symptoms. Scientists are struggling to understand why.
Read more


I am currently a student at New York University majoring in Computer Science and Mathematics (2020). I am interested in working in Data Science. I have experience working in Data Science, Data Architecture, Software Engineering, and Full-Stack Development.
GPA: 3.4/4.0
ACT: 33/36
SAT Math II: 800
I enjoy most of my time playing sports with my friends. I enjoy playing and competing in soccer, water-skiing, and padel. I also love puzzles and am a big fan of brainteasers.
I spend a large amount of my free time exploring the latest technology advancements in the machine-learning and mathematics. I am an avid self-learner and am constantly taking online courses such as CS50 (2013).
[CS50 was the first class I ever took online. Through CS50, I discovered my passion.]
I have developed these projects for hackathons, school projects, and personal use. Missing project links will be added upon graduation or after NDAs expire.


Glossary |
||||
|
||||
|
Last Published: 09/29/2005 10:16 PM HL7® Version 3 Standard, © 2005 Health Level Seven®, Inc. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off |
||||
|
|
||||
Table of Contents1.1 A
1.2 B
1.3 C
1.4 D
1.5 E
1.6 F
1.7 G
1.8 H
1.9 I
1.10 J
1.11 K
1.12 L
1.13 M
1.14 N
1.15 O
1.16 P
1.17 Q
1.18 R
1.19 S
1.20 T
1.21 U
1.22 V
1.23 W
1.24 X
1.25 Y
1.26 Z
|
||||
1 |
Alphabetic Index |
|||
1.1 |
A |
|||
| Account Defined in Account and Billing: A Billing Account is an accumulator of financial and administrative information for the main purpose of supporting claims and reimbursement. Secondarily, the billing account may contribute significant information to cost accounting and financial decision support systems. A billing account is simply that entity that captures the elements reflecting the cost and price of services provided and supplies consumed for a healthcare activity. The focus for which an account accumulates information will vary. (For example: In a realm where billing is based on periodically collecting financial transactions for a patient, the accumulator might be the patient.) A billing account might also include links to insurance and benefit information, and relevant responsible parties. Adjudication Defined in Claims & Reimbursement: A process by which an adjudicator identifies edit errors and/or determines payment intent based on insurance policy rules for submitted invoices. Adjudication Response Defined in Claims & Reimbursement: See term Adjudication Results instead. Adjudication Response Time Defined in Claims & Reimbursement: The elapsed time between the electronic submission of the claim for adjudication and the receipt of the adjudication results. Adjudication Results Defined in Claims & Reimbursement: A response by the Adjudicator to the Provider identifying edit errors and/or adjudication results for invoices (by Product Service Line Item) that have been paid in full, partially paid (adjusted) or not paid and reasons for adjustment and non-payment. Adjudicator Defined in Claims & Reimbursement: The organization that interprets insurance policy rules through an adjudication process and makes a determination on how much money should be paid for a particular invoice .An Adjudicator typically acts on behalf of an Insurance Carrier. AHRQ Defined in Public Health Reporting: Agency for Healthcare Research and Quality Alert No Text Defined in Claims & Reimbursement: The set of information that describes the details about potential problems or warnings associated with an Act. This is used for drug utilization review findings such as drug interactions. This may include among other things - alert code, type of alert, severity and reason alert was issued( including drug and supply information). No text representation is provided. Allowed Benefit Defined in Claims & Reimbursement: A good or service that is a benefit under the patient's instance of insurance. Analysis Region Defined in Regulated Studies: The analysis region defines an area in time upon which algorithms performed some analysis. The analysis may be for the derivation of a median beat, and/or interpretation statements, global measurements, etc. If the rhythm waveforms are long enough to require (local) analysis in multiple places, a region will define each. annotation Core Glossary: A note following a Domain Message Information Model (D-MIM) diagram that explains the D-MIM or the modeling behind the D-MIM. ANSI Core Glossary: American National Standards Institute application Core Glossary: A software program or set of related programs that provide some useful healthcare capability or functionality. application role Core Glossary: An abstraction that expresses a portion of the messaging behaviour of an information system. artifact Core Glossary: Any deliverable resulting from the discovery, analysis, and design activities leading to the creation of message specifications. Assignment of Benefits Defined in Claims & Reimbursement: The formal transfer of the right to certain benefit payments by a plan member to a third-party. association Core Glossary: A reference from one class to another class or to itself, or a connection between two objects (instances of classes). For more information refer to the Relationships section of the V3 Guide. association compositionCore Glossary: See composite aggregation association role name Core Glossary: A name for each end of an association. The name is a short verb phrase depicting the role of the class at the opposite end of the association from the perspective of the class adjacent to the role. Attachment Healthcare Invoice Defined in Claims & Reimbursement: Additional supporting material attached to a NeCST message such as a form, report or image. Attachment Reference Identifier Defined in Claims & Reimbursement: A unique number (made up of form number and Network Application ID) that uniquely identifies the Health Document that is attached to the Healthcare Invoice. attribute Core Glossary: An abstraction of a particular aspect of a class. Attributes become the data values that are passed in HL7 messages. For more information refer to the Attributes section of the V3 Guide. attribute typeCore Glossary: A classifier for the meaning of an attribute. In HL7 V3, attribute type is indicated by a suffix added to the attribute name. Authorization Defined in Claims & Reimbursement: A communication process betweenthe Provider and Adjudicator regarding (pre)-approval for payment of a service. Authorization is an Adjudicator's commitment to pay for a service even though an Adjudicator may or may not reserve monies for the pre-approved amount. Typically, Authorizations are processed automatically by the Payor's adjudication engine. (Return to glossary index) |
||||
1.2 |
B |
|||
| bag Core Glossary: A form of collection whose members are unordered, and need not be unique. Benefit Coverage Defined in Claims & Reimbursement: A description of the benefits provided by an individual's benefit plan. Benefit Group Defined in Claims & Reimbursement: A collection of related healthcare providers and/or organizations and/or type of service, usually based on provider specialty, that negotiate fee schedules/payment contracts with Insurance Carriers, e.g. Pharmacy, Preferred Accommodation, Chiropractors. Benefit Groups are used in Financial Management, Claims and Reimbursement (FICR) to classify Messages, Application Roles and Interactions that are allowed for that group. Billable Act Defined in Claims & Reimbursement: An invoice attachment that provides additional details on the claim. Billable Invoice Items Defined in Claims & Reimbursement: One or more billable services performed or products supplied by a Provider. Billable Line Item Defined in Claims & Reimbursement: A single billable unit for a product, e.g. product cost, tax, etc. or service, e.g. office visit. blank Core Glossary: One of the allowed values for conformance requirements. Blank means that conformance for this element is to be negotiated on a site-specific basis. Business Arrangement Identifier (BAI) Defined in Claims & Reimbursement: Identifier assigned to represent the business arrangement (or contract) between a Payee and Provider. (Return to glossary index) |
||||
1.3 |
C |
|||
| cardinality Core Glossary: Property of a data element (the number of times a data element may repeat within an individual occurrence of an object view) or column in the Hierarchical Message Description (the minimum and maximum number of occurrences of the message element). Carrier Defined in Claims & Reimbursement: An organization that etablishes insurance policies, determines eligibility and benefits under those insurance policies, and underwrites payments for products and/or services provided to a beneficiary (person or organization). A Carrier may retain a TPA (Third Party Administrator) insurance carrier to perform some or all invoice validation, adjudication and payment. This may also be known as the insurance company or public insurance carrier. Character DataCore Glossary: Text in a particular coding (e.g., ASCII), as distinguished from binary data. choice Core Glossary: A message construct that includes alternative portions of the message. For a choice due to specialization, the sender picks one of the alternatives and sends it along with a flag. choice due to specialization Core Glossary: A choice that arises when a Hierarchical Message Description includes (a) an object view which is associated with a class that is a superclass of two or more object views, or (b) an object view which is a superclass of one or more object views and may itself be instantiated. Under this circumstance different message instances may contain different object views. The choice structure is used to accommodate the alternatives. class Core Glossary: An abstraction of a thing or concept in a particular application domain. For more information refer to the Classes section of the V3 Guide. classifier attributeCore Glossary: An attribute used in generalization hierarchies to indicate which of the specializations is the focus of the class . For more information refer to the Attributes section of the V3 Guide. Clinical Product Billable ActDefined in Claims & Reimbursement: The set of information to describe the provision of healthcare goods/products for a patient's care that is billed in an invoice. This may include among other things - date of service, goods/product specification (including UPC code, serial number, manufacturer, packaging, warranty) provider, location from and delivery to location. Clinical Service Billable Act Defined in Claims & Reimbursement: The set of information to describe the patient care or other activity performed by a provider that is billed in an invoice. This may include among other things - date of service, healthcare provider, location and diagnosis. It may also include information about the maintenance of a healthcare product (wheelchair). clone Core Glossary: A class from the Reference Information Model (RIM) that has been used in a specialized context and whose name differs from the RIM class from which it was replicated. This makes it possible to represent specialized uses of more general classes to support the needs of messaging. CMET Core Glossary: See Common Message Element Type. CMET Message Information Model Core Glossary: A form of Refined Message Information Model (R-MIM) constructed to represent the totality of concepts embodied in the individual R-MIMs needed to support the definition of HL7's Common Message Element Types. C-MIM Core Glossary: See CMET Message Information Model. coded attribute Core Glossary: An attribute in the Reference Information Model (RIM) with a base data type of CD, CE, CS, or CV. coding strength Core Glossary: An extensibility qualifier that specifies whether or not a code set can be expanded to meet local implementation needs. coding system Core Glossary: A scheme for representing concepts using (usually) short concept identifiers to denote the concepts that are members of the system; defines a set of unique concept codes. Examples of coding systems are ICD-9, LOINC and SNOMED. Co-insurance Defined in Claims & Reimbursement: A set percentage of any claim cost payable by plan members after any deductible has been paid collection Core Glossary: An aggregation of similar objects. The forms of collection used by HL7 are set , bag, and list. Objects which may be found in collections include data types and message element types. common message element type (CMET) Core Glossary: A message type in a Hierarchical Message Description (HMD) that may be included by reference in other HMD's. For more information refer to the Common Message Element Types section of the V3 Guide. composite aggregationCore Glossary: A type of association between objects, indicating a whole-part relationship. composite data type Core Glossary: A data type assigned to a message element type that contains one or more components, each of which is represented by an assigned data type. composite message element type Core Glossary: A message element type that contains subordinate heterogeneous message types. Compound Defined in Claims & Reimbursement: Generally an extemporaneous mixture that has been prepared by the pharmacist based on a prescription from a prescriber. concept identifier Core Glossary: A unique identification assigned to a concept by the HL7 organization. conformance claim Core Glossary: A specification written by HL7 to precisely define the behavior of an application with respect to its HL7 interfaces, and which may be designated functional or technical. A functional conformance claim is simply a statement that an application conforms to a particular application role. A technical conformance claim (also referred to as a Technical Statements of Performance Criteria) defines the behavior of an application in some other sense than the messages it sends or receives. This may include the Implementation Technology Specifications that it supports, the use of specific optional protocols or character sets, or many other behaviors. conformance claim set Core Glossary: A list of the identifiers of specific HL7 conformance claims, used by a sponsor to describe the conformance of its application. conformance requirement Core Glossary: A column in the Hierarchical Message Description (HMD) that designates whether the system must communicate an attribute's value if a value is available. Allowed values are required (must be included), not required (may be left out) or not permitted (may never be included.) Items listed as not required in the HL7 specification must be declared by a vendor as either required or not permitted when a conformance claim is asserted for that message type. connection Core Glossary: In an information model, a specified relationship between two classes . constraint Core Glossary: Narrowing down of the possible values for an attribute; a suggestion of legal values for an attribute (by indicating the data type that applies, by restriction of the data type, or by definition of the domain of an attribute as a subset of the domain of its data type). May also include providing restrictions on data types. A constraint imposed on an association may limit the cardinality of the association or alter the navigability of the association (direction in which the association can be navigated). A Refined Message Information Model (R-MIM) class may be constrained by choosing a subset of its Reference Information Model (RIM) properties (i.e., classes and attributes) or by cloning, in which the class’ name is changed. For more information refer to the Constraints section of the V3 Guide. contact CMETDefined in Common Message Element Types: A CMET variant that provides sufficient information to allow the object identified to be contacted. This is likely to have the content of identified and confirmable plus telephone number. control event wrapper Core Glossary: A wrapper that contains domain specific administrative information related to the "controlled event" which is being communicated as a messaging interaction. The control event wrapper is used only in messages that convey status, or in commands for logical operations being coordinated between applications (e.g., the coordination of query specification/query response interactions). Co-ordination of Benefits Defined in Claims & Reimbursement: Refers to the co-ordination of payment of an invoice or invoice line item that may be payable by more than oneAdjudictor. Co-pay Defined in Claims & Reimbursement: The portion of a claim that is apportioned to the patient, often as a percentage of the total value of the claim. coupling Core Glossary: 1. An interaction between systems or between properties of a system. Core Glossary: 2. With regard to application roles , refers to whether or not additional information about the subject classes participating in a message may be commonly available to system components outside of the specific message. Coverage Extension Defined in Claims & Reimbursement: A form of Authorization where the Provider requests payment approval for extension of a Person's benefit coverage. Typically, Coverage Extensions require manual or human intervention and decision by the Adjudicator. Synonymous with Prior Approval. (Return to glossary index) |
||||
1.4 |
D |
|||
| data type Core Glossary: The structural format of the data carried in an attribute. It may constrain the set of values an attribute may assume. For more information refer to the Data Types section of the V3 Guide. DeductibleDefined in Claims & Reimbursement: The dollar amount for which the plan beneficiary must pay before any remaining eligible expenses are reimbursed under the plan. This is usually calculated on an annual basis. default value Core Glossary: In HL7 messages, the value for an attribute that is to be used by message receivers if no value is given. Deferred Adjudication Defined in Claims & Reimbursement: Adjudication of a claim that does not occur in real time i.e. the request for payment is responded to with a simple "acknowledgment of receipt" message. The final adjudication and transmission of adjudication results will occur at a later time as determined by the adjudicator's system. Demographic Information Defined in Claims & Reimbursement: Relates to the patient's name, address, date of birth, etc. Diagnosis Defined in Claims & Reimbursement: Identification of disease or condition by a practitioner by means of a Persons symptoms, diagnostic tests, etc. Diagnosis Code Defined in Claims & Reimbursement: A coding scheme (e.g., ICD-10CA/CCI) used to indicate diagnosis. DIN Defined in Claims & Reimbursement: The Drug Identification Number assigned to a specific medication by Health Canada. distal class Core Glossary: From the perspective of a class in an information model, it is the class at the opposite end of an association between the two. D-MIM Core Glossary: See Domain Message Information Model. domain Core Glossary: 1. A particular area of interest. For example, the domain for HL7 is healthcare. Core Glossary: 2. The set of possible values of a data type , attribute, or data type component. See also vocabulary domain . Core Glossary: 3. A special interest group within HL7, such as Pharmacy, Laboratory, or Patient Administration. domain expert Core Glossary: An individual who is knowledgeable about the concepts in a particular problem area within the healthcare arena and/or is experienced with using or providing the functionality of that area. Domain Message Information Model Core Glossary: A form of Refined Message Information Model (R-MIM) constructed to represent the totality of concepts embodied in the individual R-MIMs needed to support the communication requirements of a particular HL7 domain. For more information refer to the Information Model section of the V3 Guide. domain nameCore Glossary: The name assigned to a vocabulary domain. domain specification Core Glossary: The specification of a vocabulary domain. Drug Interactions Defined in Claims & Reimbursement: An interaction, usually adverse, between two or more medications being taken by the individual. Drug Utilization Review Defined in Claims & Reimbursement: A review of the medication regimen of an individual, either prospective (concurrent) or retrospective (past). Duplicate Therapy Defined in Claims & Reimbursement: The provision of the same or a similar medication for an individual for the same purpose. (Return to glossary index) |
||||
1.5 |
E |
|||
| e-Claim Defined in Claims & Reimbursement: An invoice for health related good(s) and/or service(s) transmitted for payment in an electronic format. Electronic Health Record (EHR) Defined in Claims & Reimbursement: An electronic representation of an individual's health record, either in a single data repository or in separate linked repositories. Eligibility (for benefits coverage) Defined in Claims & Reimbursement: A Person meets the criteria for benefits coverage. Benefits coverage is determined by the Insurance Carrier and may be delegated to an Adjudicator. Eligibility for benefits does not necessarily imply a specific service or good will be covered for payment. Eligibility with one insurance carrier does not imply eligibility with another insurance carrier. EnrolmentDefined in Claims & Reimbursement: The process of registering with an insurer to obtain benefits coverage. entry point Core Glossary: The point at which a Common Message Element Type (CMET) is inserted into a Refined Message Information Model (R-MIM). event Core Glossary: 1. A stimulus that causes a noteworthy change in the state of an object, or a signal that invokes the behavior of an object. See also trigger event. Core Glossary: 2. A vocabulary domain value for Mood. Explanation of Benefits (EOB) Defined in Claims & Reimbursement: Identifies paid amount, adjudication results and informational items for n Invoice Grouping. The Provider may forward EOB details from a Primary Payor unaltered toa Secondary Adjudicator for co-ordination of benefits. extensibility qualifier Core Glossary: A vocabulary domain qualifier used in a domain specification, which indicates whether or not the existing vocabulary domain can be extended with additional values. There are two possible values: CNE (coded, no extension) and CWE (coded with extension). For more information refer to the Vocabulary Domain Qualifiers section of the V3 Guide. Extensible Markup LanguageCore Glossary: A meta-language that defines a syntax used to define other domain -specific, semantic, structured markup languages. Based on SGML (Standard Generalized Markup Language), it consists of a set of rules for defining semantic tags used to mark up the content of documents. Abbreviated as XML. (Return to glossary index) |
||||
1.6 |
F |
|||
| FDA Defined in Public Health Reporting: Food and Drug Administration Form Defined in Claims & Reimbursement: Structured document with content, transmission, display and storage requirements identified in a standard. Formulary Defined in Claims & Reimbursement: The list of medications that are a benefit for an individual or a defined group. function point Core Glossary: Any function, user transaction, or other interaction or event in the sponsor’s application which, when it occurs, does or may correspond to an HL7 trigger event. Used to describe the conformance of an information system with the HL7 standard. (Return to glossary index) |
||||
1.7 |
G |
|||
| generalization Core Glossary: An association between two classes, referred to as superclass and subclass, in which the subclass is derived from the superclass. The subclass inherits all properties from the superclass, including attributes, relationships, and states, but also adds new ones to extend the capabilities of the parent class. Essentially, a specialization from the point-of-view of the subclass. For more information refer to the Relationships section of the V3 Guide. generalization hierarchyCore Glossary: All superclasses and subclasses with a common root superclass. Global Product Identification Number (EAN, UCC, GPIN) Defined in Claims & Reimbursement: A globally unique identifier assigned to a product Goods Defined in Claims & Reimbursement: A durable or consumable product provided to a Person including equipment, food and furniture. Splint, wheelchair, prosthetic and custom table are examples of goods. Goods Service Defined in Claims & Reimbursement: A service provided to a Good (for a Person) such as wheelchair repair, hearing aid repair or prosthesis repair. graphical expression Core Glossary: A visual representation of a model that uses graphic symbols to represent the components of the model and the relationships that exist between those components. grid view Core Glossary: A complete view of the message type definition, which, due to its size, is presented in a scrollable format. Group Service Defined in Claims & Reimbursement: Provision of a service(s) to a group of individuals. (Return to glossary index) |
||||
1.8 |
H |
|||
| Health Document Defined in Claims & Reimbursement: A form, report or image that substantiates the authorization, adjudication and subsequent payment of a Healthcare Invoice. A Health Document can be submitted manually or electronically. When submitted electronically, it can be submitted with a Healthcare Invoice or separately from the Healthcare Invoice. Health Goods Provider Defined in Claims & Reimbursement: A party that provides medical and support goods to a Person. Health Service Defined in Claims & Reimbursement: A health care service such as diagnosis, treatment or intervention performed for a person. Health Service Provider Defined in Claims & Reimbursement: See term Provider instead. Healthcare Claim Defined in Claims & Reimbursement: An invoice for health related good(s) and/or service(s) transmitted for payment. See also invoice. Healthcare Good Defined in Claims & Reimbursement: A product that is supplied from a healthcare provider and that is/ may be a benefit of an individual's benefit plan e.g. wheelchair, syringes. Healthcare Invoice Defined in Claims & Reimbursement: See term Invoice instead. Healthcare Provider Defined in Claims & Reimbursement: See term Provider instead. Hierarchical Message Description Core Glossary: A specification of the exact fields of a message and their grouping, sequence, optionality, and cardinality. This specification contains message types for one or more interactions, or that represent one or more common message element types. This is the primary normative structure for HL7 messages. HMD Core Glossary: See Hierarchical Message Description. HTML Core Glossary: Hypertext Markup Language, a specification of the W3C that provides markup of documents for display in a web browser (Return to glossary index) |
||||
1.9 |
I |
|||
| identified CMET Defined in Common Message Element Types: A CMET variant that is a proper subset of universal and is intended to provide sufficient information to identify the object(s) modeled by the CMET. This variant is only suitable for use within TIGHTLY COUPLED SYSTEMS ONLY. This variant provides ONLY the ID (and code where applicable) and Name. Other variants may not be substituted at runtime. identified-confirmable CMET Defined in Common Message Element Types: A CMET variant that extends the identified variant by adding just sufficient additional information to allow the identity of object modeled to be confirmed by a number of corroborating items of data; for instance a patient's date of birth and current address. identifier attribute Core Glossary: An attribute used to identify an instance of a class. For more information refer to the Attributes section of the V3 Guide. implementation technologyCore Glossary: A technology selected for use in encoding and sending HL7 messages. For example, XML is being used as an implementation technology for Version 3. Implementation Technology Specification Core Glossary: A specification that describes how HL7 messages are sent using a specific implementation technology . It includes, but is not limited to, specifications of the method of encoding the messages, rules for the establishment of connections and transmission timing and procedures for dealing with errors. For more information refer to the Implementation Technology Specifications section of the V3 Guide. Implied ConsentDefined in Claims & Reimbursement: Consent for an activity that is inferred by a prior activity and not a result of a discussion i.e. supplying a healthcare provider with a benefit card implied the provider should transmit claims for payment where possible. inclusion Core Glossary: The specification in the Hierarchical Message Description indicating whether an element of a message type may be null in some message instances. Contrast this with conformance. Information Invoice Defined in Claims & Reimbursement: An invoice that is for information purposes only. Used in situations where a non fee for service funding method is used but details on the products/services provided is still required. information model Core Glossary: A structured specification, expressed graphically and/or narratively, of the information requirements of a domain. An information model describes the classes of information required and the properties of those classes, including attributes, relationships, and states. Examples in HL7 are the Domain Reference Information Model, Reference Information Model, and Refined Message Information Model. For more information refer to the Information Model section of the V3 Guide. inheritanceCore Glossary: In a generalization relationship, the subclass inherits all properties from the superclass, including attributes, relationships, and states, unless otherwise specified. instance Core Glossary: A case or an occurrence. For example, an instance of a class is an object. Insurance Carrier Defined in Claims & Reimbursement: See term Carrier instead. interaction Core Glossary: A single, one-way information flow that supports a communication requirement expressed in a scenario. interaction diagram Core Glossary: A graphical representation of communications between application roles. An interaction diagram may also be referred to as a ladder diagram, sequence diagram, or storyboard diagram. interaction list Core Glossary: A list of the interactions that appear in an interaction diagram. interaction model Core Glossary: A specification of the responsibilities of message senders and receivers. interaction narrative Core Glossary: A narrative description of each interaction contained in an interaction list . internal data type Core Glossary: An HL7 data type defined to support the definition of other data types, but which may not be assigned as the type for a data field itself. Invoice Defined in Claims & Reimbursement: A request initiated by a Provider, on behalf of a plan member (insured), for payment for services rendered and/or goods provided. Stated another way, an Invoice is a request by a plan member to a plan administrator (Adjudicator) for payment of a benefit covered by the benefit plan. Can be synonymous with Fee for Service Claim, Claim, and Bill. An invoice can be submitted for any payment modalities (e.g., fee for service, sessional, group, contract and/or block services). Invoice ElementDefined in Claims & Reimbursement: A single billable item, made up of an identifiable code (e.g. office visit, wheel chair) and pricing for that billable item. For example, it can be used to specify 4 wheel chairs @ $250 per wheel chair. Invoice Elements may be specified in a hierarchy to fully specify the item being invoiced. That is, it includes a grouping variant as well as a detail variant (the detail variant contains the detailed pricing information). For example, a group Invoice Element may contain 2 detail Invoice Elements, one for the good and one for the associated taxes. Therefore, the group Invoice Element would represent the amount for the good and taxes. Invoice Element Detail Defined in Claims & Reimbursement: The information contained in a Healthcare Invoice such as quantity, unit and cost, authorization, service location and comment information. Synonymous with fee-item. Invoice Element Group Defined in Claims & Reimbursement: A grouping of Invoice Element Details. For example, a group represents all of the costing elements that make up a drug cost (e.g. drug cost + markup). Invoice Element Grouping Defined in Claims & Reimbursement: A collection of Invoice Elements that make up a package of items that need to be adjudicated together. For example, a drug dispense, with Invoice Elements (costing elements) for the drug cost, markup and professional fees. An Invoice Grouping has a root Invoice Element Group, with multiple Invoice Element Details and Invoice Element Groups. ITS Core Glossary: See Implementation Technology Specification. (Return to glossary index) |
||||
1.10 |
J |
|||
| joint state Core Glossary: A summarization of multiple partial states in a state machine. (Return to glossary index) |
||||
1.11 |
K |
|||
1.12 |
L |
|||
| ladder diagram Core Glossary: See interaction diagram. life cycle Core Glossary: See state machine. LIFO Core Glossary: Last in-first out. See push-down stack. list Core Glossary: A form of collection whose members are ordered, and need not be unique. literary expression Core Glossary: A representation of a model in text. The literary expression seeks to balance the need for a rigorous, unambiguous description of the model with the need for a rendition that can be easily read and interpreted by individuals who understand the general concepts underlying object-oriented models, but who may not be schooled in formal model definition languages. LOINC Core Glossary: Logical Observations, Identifiers, Names, and Codes loosely coupled Core Glossary: Loosely coupled application roles do not assume that common information about the subject classes participating in a message is available to system components outside of the specific message. (Return to glossary index) |
||||
1.13 |
M |
|||
| mandatory Core Glossary: If an attribute is designated as mandatory, all message elements which make use of this attribute must contain a non-null value or they must have a default that is not null. This requirement is indicated in the "mandatory" column in the Hierarchical Message Description. mandatory association Core Glossary: An association with a multiplicity minimum greater than zero on one end. A fully mandatory association is one with a multiplicity minimum greater than zero on both ends. markup Core Glossary: Computer-processible annotations within a document. Markup encodes a description of a document’s storage layout and logical structure. In the context of HL7 V3, markup syntax is according to the XML Recommendation. Master Files Core Glossary: Common lookup tables used by one or more application systems. MDF Core Glossary: See Message Development Framework. Median Beat Annotations Defined in Regulated Studies: Just like annotations on the rhythm data, annotations can be made on the median beat. Fudicial markings related to the measurements specified by the trial protocol can be made globally (on all leads) or locally (on some leads). Episode annotations (such as arrhythmias, ST elevation episodes, etc.) would not be made on the median beat (for obvious reasons). Refer to examples from rhythm waveforms annotations. Median Beat Waveforms Defined in Regulated Studies: Computer algorithms can derive a representative beat from a series of beats having the same morphology (same focus, etc.). Sometimes a trial protocol will specify the usage of a "median beat" for taking measurements. If a median beat is used, and the rhythm data from which it is derived is wanted by the FDA, the median beat is related to the rhythm waveforms via an analysis region. The median is typically composed of as many leads as the rhythm waveforms from which it was derived. The relative time represents time within the representative cycle, not time relative to the beginning of the rhythm waveforms. message Core Glossary: A package of information communicated from one application to another. See also message type and message instance. Message Development Framework Core Glossary: The collection of models, methods, and tools that comprise the methodology for specifying HL7 Version 3 messages. This framework is used by the developers of the HL7 standards. message element Core Glossary: A unit of structure within a message type. message element type Core Glossary: A portion of a message type that describes one of the elements of the message. message instance Core Glossary: A message, populated with data values, and formatted for a specific transmission based on a particular message type. message payload Core Glossary: Data carried in a message. message type Core Glossary: A set of rules for constructing a message given a specific set of instance data. As such, it also serves as a guide for parsing a message to recover the instance data. meta-model Core Glossary: A model used to specify other models. For example, the meta-model for a relational database system might specify elements of type ‘Table’, ‘Record’, and ‘Field.’. methodology Core Glossary: Methods or rules followed in a particular discipline. MIME Core Glossary: Multipurpose Internet Mail Extensions (MIME, RFC 2046) minimal CMET minimal CMET Defined in Common Message Element Types: A CMET variant that provides more than identified, but not as much as universal. There are not expected to be many of these. model Core Glossary: A representation of a domain that uses abstraction to express the relevant concepts. In HL7, the model consists of a collection of schema and other documentation. multiplicity Core Glossary: 1. In the information model, multiplicity is a specification of the minimum and maximum number of objects from each class that can participate in an association. Multiplicity is specified for each end of the association. Core Glossary: 2. In the Hierarchical Message Description (HMD), multiplicity depicts the minimum and maximum number of occurrences of a message element expression in a collection. (Return to glossary index) |
||||
1.14 |
N |
|||
| navigability Core Glossary: Direction in which an association can be navigated (either one way or both ways). not permitted Core Glossary: One of the allowed values in conformance requirements. Abbreviated as NP, it means that the message element is never sent for that message type. NPSA Defined in Public Health Reporting: National Patient Safety Agency (UK) null Core Glossary: A value for a data element which indicates the absence of data. A number of “flavors” of null are possible and are enumerated in the domain NullFlavor. (Return to glossary index) |
||||
1.15 |
O |
|||
| object Core Glossary: An instance of a class. A part of an information system containing a collection of related data (in the form of attributes) and procedures (methods) for operating on that data. For more information refer to the Classes section of the V3 Guide. object identifierCore Glossary: A scheme to provide globally unique identifiers. This object identifier (OID) scheme is an ISO standard (ISO 8824:1990), and has been adopted as a CSA standard (Z243.110). object identity Core Glossary: The feature that the existence of an object is independent of any values associated with the object. object-based Core Glossary: Any method, language, or system that supports object identity, classification, and encapsulation. An object-based system does not support specialization . Ada is an example of an object-based implementation language. obsolescent message type Core Glossary: A message type that has been marked for deletion in a future version of HL7. obsolete message type Core Glossary: A message type, previously declared obsolescent, that has been removed or replaced in a particular version of HL7. OID Core Glossary: See object identifier. optional Core Glossary: See inclusion. (Return to glossary index) |
||||
1.16 |
P |
|||
| partial state Core Glossary: Part of a state machine. A state machine may have multiple partial states effective at the same time; the multiple partial states can be summarized to one joint state of the state machine. Patient Defined in Claims & Reimbursement: Person, in the role of patient for a particular situation. For example, this person is a patient at the hospital, but this person is not a patient at this time. See also Person. Patient Pays Portion Defined in Claims & Reimbursement: The amount of a claim that is the responsibility of the patient. Patient Safety Defined in Public Health Reporting: See term Patient Safety Incident instead. Patient Safety Incident Defined in Public Health Reporting: See term Patient Safety instead. Payee Defined in Claims & Reimbursement: A Person or organization that receives payment for Goods provided and/or Services rendered or receives payment on behalf of one or more Providers. As well, a Payee may be a Person who has directly paid the Provider for the Goods provided and/or Services rendered and is being reimbursed by the Adjudicator. In some cases, a Payee may be the same as the Provider. Payment Defined in Claims & Reimbursement: A cheque or Electronic Funds Transfer (EFT) issued to a Payee. Payment Advice Defined in Claims & Reimbursement: The payment details for adjudicated Invoices and non-Invoice adjustments which correspond to an actual payment either by cheque or electronic funds transfer. Payment Intent Defined in Claims & Reimbursement: Based on the adjudicated results of an invoice, Payment Intent is the details of the items and amounts the Adjudicator intends to pay. This is not a record of payment but rather an intention to pay which may be more or less than what was requested in the invoice. Payment Reconciliation Defined in Claims & Reimbursement: The process of comparing what has been paid versus what was expected to be paid. Payment Request Defined in Claims & Reimbursement: See term Invoice instead. Payor Defined in Claims & Reimbursement: A Payor is the organization who is responisble for the payment. This is typically the name on the cheque. Also known as the Plan Sponsor. Note that this may be a different organization than the Carrier (insurance carrier) and Adjudicator. Payor AdjustmentsDefined in Claims & Reimbursement: Adjustments made by the Payor to the billed amount as a result of items such as deductibles or professional dues. Can also be referred to as adjustments to Payee. Person Defined in Claims & Reimbursement: Individual person, who can assume multiple roles over time. For example, a person may be a patient for a period of time at a hospital or a provider on a different occasion. Pharmacy Dispense Billable Act Defined in Claims & Reimbursement: The set of information to describe the dispensing of a drug to a patient that is billed in an invoice. This may include among other things - date of service, drug supplied (specification, quantity, days supply), prescription and prescriber, number of refills, alerts and pharmacy. Pre-Determination Defined in Claims & Reimbursement: The submission of a 'mock' Healthcare Invoice to a Payor to determine the extent to which an Adjudicator will reimburse for the goods or services. A Provider may use this to compare alternate treatments to determine least cost alternative for the patient. predicate reference Core Glossary: In the Hierarchical Message Description, a message element that is referred to in the predicate defining the conditional presence of another message element. Preferred Accommodation Benefits Defined in Claims & Reimbursement: Benefits covering special healthcare lodging requirements. This includes private or semi-private hospital accommodation. Preferred Accommodation Billable Act Defined in Claims & Reimbursement: The set of information to describe the patient's premium hospital accommodation that is billed in an invoice. This may include among other things - date range of occupation, location, accommodation requested and available, reason for accommodation and requestor. Prescription Defined in Claims & Reimbursement: An order from a recognized prescriber for a health care good or service. Primary Payor Defined in Claims & Reimbursement: The Payor that is responsible for payment of a Healthcare Invoice. primitive data type Core Glossary: A data type that is defined as a single entity, and whose full semantic is contained in its definition. primitive message element type Core Glossary: A message element type that contains a single datum, with no subordinate components. Examples include String and Number. Prior Approval Defined in Claims & Reimbursement: See term Coverage Extension instead. Procedure Defined in Claims & Reimbursement: In the context of a Health Care procedure this is the details identifying the service or procedure that was actually provided to a Person such as the procedure code, duration of procedure, time procedure took place and Provider who performed the procedure. Product/Service Code Defined in Claims & Reimbursement: The code used to identify what service is being billed. Synonymous with fee-code. Professional Fee Defined in Claims & Reimbursement: In health care, the fee charged by the health care provider for the provision of a service. In pharmacy, this often refers to the fee charged for the dispensing of a medication. property Core Glossary: 1. Any attribute, association, method, or state model defined for a class or object. Core Glossary: 2. In a Hierarchical Message Description (HMD), the column that states the name of the class, attribute or association role name as it appears in the Reference Information Model (RIM). Provider Defined in Claims & Reimbursement: An individual who delivers a health service to a person or animal e.g., doctor, nurse, pharmacist, technician, etc. Provider Adjustments Defined in Claims & Reimbursement: Changes to the billable amount as a result of items such as taxes, mark-ups, surcharges or discounts. PS:GIN Defined in Public Health Reporting: See term PS:RUM instead. PS:RUM Defined in Public Health Reporting: See term PS:GIN instead. push-down stack Core Glossary: Also known as a “last in-first out” (LIFO) list, a list maintained by a Technical Committee as it analyses the Refined Message Information Model (R-MIM) and builds a Hierarchical Message Description, in which the last class added is always the first class removed. (A metaphoric reference to the spring-loaded plate carriers used in institutional dining halls, where the new plates added to the top of the stack push down the earlier plates, so the newest plate is taken off the stack first). (Return to glossary index) |
||||
1.17 |
Q |
|||
| (Return to glossary index) | ||||
1.18 |
R |
|||
| Re-Adjudication (of an invoice) Defined in Claims & Reimbursement: Process whereby a Provider can request a re-adjudication of an invoice that has been partially paid by a Payor. A TE660101 message can be used to perform this function or alternatively, the original invoice can be cancelled and a new invoice submitted to the same Payor. realm Core Glossary: A vocabulary domain qualifier used in a domain specification, which allows the vocabulary domain of a coded attribute to be specialized according to the geographical, organizational, or political environment where the HL7 standard is being used. For more information refer to the Vocabulary Domain Qualifiers section of the V3 Guide. ReceiverDefined in Claims & Reimbursement: The application fulfilling the Receiving Application role in an interaction receiver responsibility Core Glossary: An obligation on an application role that receives an interactionas defined in the interaction model. Reciprocal Healthcare Invoice Defined in Claims & Reimbursement: A request for payment of Service rendered and/or Goods provided by a Provider in one province to a Person who is insured by a different province. Reciprocal invoices are based on agreements between the provinces, except Quebec and only apply to Physician related claims. recursion Core Glossary: An association that leads from a class directly or indirectly back to that class. Reference Information Model Core Glossary: The HL7 information model from which all other information models (e.g., R-MIMs) and messages are derived. For more information refer to the Information Model section of the V3 Guide. Refined Message Information ModelCore Glossary: An information structure that represents the requirements for a set of messages. A constrained subset of the Reference Information Model (RIM) which may contain additional classes that are cloned from RIM classes. Contains those classes, attributes, associations, and data types that are needed to support one or more Hierarchical Message Descriptions (HMD). A single message can be shown as a particular pathway through the classes within an R-MIM. For more information refer to the Information Model section of the V3 Guide. Region SpecificationDefined in Regulated Studies: There are 2 basic types of regions: a fully specified region and a partially specified one. The fully specified region is one where each dimension within the Observation Series to be included in the region has a boundary defined. For example, if an episode of ST elevation is observed in leads V4 and V5, a fully specified region would contain 3 boundaries: one for time, one for V4, and one for V5. The boundary in time would be specified with an interval in time (IVL<PQ>). The boundaries on V4 and V5 would be infinite intervals (the entire range of voltages for both leads are to be included in the region for ST elevation). A partially specified region assumes all dimensions in the Observation Series are included in the region except for the boundaries specified. For example, if a global QRS onset is observed, only a boundary for time is required. All the other dimensions (leads) would be included in the partially specified region. Request for Payment Defined in Claims & Reimbursement: See term Invoice instead. Requester Defined in Claims & Reimbursement: An organization or person on whose behalf a request message for authorization, information, etc. is submitted. required Core Glossary: One of the allowed values in conformance requirements. Abbreviated as R, it means that the message elements must appear every time that particular message type is used for an interaction. If the data is available, the element must carry the data, otherwise a blank may be sent. responsibility Core Glossary: An action required of the receiver of a message. Rhythm Waveform Annotations Defined in Regulated Studies: Some annotations will be specific to areas in time but will apply to all the leads. For example, the presence of an arrhythmia, or a period of time where the patient was performing some activity that affects the ECG. Pacer spikes and perhaps beat locations are also indicated as points or areas in time. Fudicial markings made by superimposing all the leads would also fall into this category. * Rhythm annotation example * Patient activity example * Pacer spikes example * Beat location example * Beat classification example * Global fudicial markings example Other annotations will be specific to areas in time AND one or more leads. Annotations falling into this category include fudicial markings for beat measurements made on particular leads, lead-specific episodes such as ST elevation, etc. * Fudicial markings example * Isoelectric example * ST elevation example Rhythm Waveforms Defined in Regulated Studies: These are the waveforms directly collected from the subject and used for clinical trial research. If measurements were taken from these, annotations should show the fudicial markings for those measurements. The specific set of fudicial markings is specified by the trial protocol. If the waveforms have been enhanced to facilitate the measurement process, control variables should indicate what enhancements were made. For example, filtering, etc. RIM Core Glossary: See Reference Information Model. R-MIM Core Glossary: See Refined Message Information Model. R-MIM diagram Core Glossary: A diagrammatic representation of a Refined Message Information Model (R-MIM). Possible formats include UML and the HL7 R-MIM graphic format. role Core Glossary: 1. A function or position. Core Glossary: 2. A Reference Information Modelclass that defines the competency of an Entity class. Each role is played by one Entity (the Entity that is in the role) and is usually scoped by another. Core Glossary: 3. In UML, each end of an association is designated as a role to reflect the function that class plays in the association. role name Core Glossary: See association role name. root class Core Glossary: The class on which a message is based. Usually the root class for a family of messages is either the subject class or the class that will be first represented in the set of messages to be built. RootInvoiceElement Defined in Claims & Reimbursement: An Invoice Element at the top level (root) of the hierarchy of billable items that form part of an Invoice. Relationships for insurance, service target (e.g. patient), incident, EOBs (explanation of benefits) submitted for downstream payors (to support Coordination of Benefits) and attachments are made to the RootInvoiceElement. The information thus supplied applies to each individual Invoice Element (billable item) associated to the RootInvoiceElement. (Return to glossary index) |
||||
1.19 |
S |
|||
| scenario Core Glossary: A statement of relevant events from the problem domain, defined as a sequence of interactions. The scenario provides one set of interactions that the modeling committee expects will typically occur in the domain. Usually, a sequence diagram is constructed to show a group of interactions for a single scenario. Each scenario is displayed as a subset of the interaction model. schema Core Glossary: 1. A diagrammatic presentation, a structured framework, or a plan. Core Glossary: 2. A set of requirements that need to be met in order for a document or set of data to be a valid expression within the context of a particular grammar. For example, XML Schema is a specification in SGML of the structure of a document or set of data. schema view Core Glossary: A link to the schema used to validate XML messages that conform to a particular message type. scope Core Glossary: 1. A definition of the range or extent of a project undertaken by a Technical Committee. Core Glossary: 2. A means of constraining a role (ie. a role is “scoped by” an entity). Secondary Payor Defined in Claims & Reimbursement: The Payor that is responsible for payment of a Healthcare Invoice if the Primary Payor does not pay. section Core Glossary: In the HL7 V3 Guide, a method of grouping related information into domains. These domains include Infrastructure Management, Administrative Management, and Health & Clinical Management. Semantic Core Glossary: In the context of a technical specification, semantic refers to the meaning of something as distinct from its exchange representation. Syntax can change without affecting semantics. Sender Defined in Claims & Reimbursement: The application fulfilling the Sending Application role in an interaction sequence diagram Core Glossary: See interaction diagram . Service Defined in Claims & Reimbursement: A consultation, diagnosis, treatment or intervention performed for a Person and/or other activity performed for a Person. Includes health, goods and support services. Service Bureau Defined in Claims & Reimbursement: An agent retained by a Provider to assemble and submit Healthcare Invoices and receive validation and adjudication results. Service Relationship Defined in Claims & Reimbursement: A defined relationship or association between a Provider and Payee or Person and Payee that defines the financial and/or contract terms and conditions. Sessional Invoice Defined in Claims & Reimbursement: An invoice for services provided on a sessional basis, e.g., 4 hours in an operating theatre. set Core Glossary: A form of collection which contains an unordered list of unique elements of a single type. SGML Core Glossary: Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected SNOMED Core Glossary: Systematized Nomenclature of Medicine SOFA Defined in Claims & Reimbursement: This acronym is for Statement Of Financial Activity. This is a category of interactions that facilitate the exchange of detailed and summarized financial information between an Invoice Requestor and Adjudication Manager. It includes Payment Advices, summarized counts and amounts for processed invoices as well as details of individual counts and amounts over a specified period of time specialization Core Glossary: An association between two classes (designated superclass and subclass), in which the subclass is derived from the superclass. The subclass inherits all properties from the superclass, including attributes, relationships, and states, but also adds new ones to extend the capabilities of the superclass. specification Core Glossary: A detailed description of the required characteristics of a product. sponsor (of an application) Core Glossary: In the context of conformance claims , the vendor, in-house developer, or provider of public domain software for a healthcare information system. state Core Glossary: A named condition of a classinstance ( object) that can be tested by examination of the instance's attributes and associations. For more information refer to the Dynamic Behavior section of the V3 Guide. state attributeCore Glossary: An attribute describing the current state of an object. For more information refer to the Attributes section of the V3 Guide. state diagramCore Glossary: A graphical representation of a state transition model showing states as vertices (nodes) and state transitions as directed arcs (arrows) between the nodes. state flag Core Glossary: A discrete value of a single enumerated domain of partial states. State flags are included in a state attribute in a message instance that indicates the joint state of an object. state machine Core Glossary: A description of the life cycle for instances of a class, defined by a state transition model. state transition Core Glossary: A change in the state of an object, as a result of a change in its attributes or associations. For more information refer to the Dynamic Behavior section of the V3 Guide. state transition modelCore Glossary: A graphical representation of the life cycle of a class. The model depicts all of the relevant states of a class, and the valid transitions from state to state. steward committee Core Glossary: The Technical Committee within HL7 which has primary responsibility for specifying properties for a class in the Reference Information Model (RIM). The steward committee must be consulted on any proposed changes to the properties of classes under its stewardship. stewardship representative Core Glossary: An individual member of the steward committee, authorized by the committee to speak on behalf of the committee, and to represent the interests of the steward committee. storyboard Core Glossary: A narrative of relevant events defined using interaction diagramsor use cases. The storyboard provides one set of interactions that the modeling committee expects will typically occur in the domain. storyboard diagram Core Glossary: See interaction diagram. structural attribute Core Glossary: An attribute whose coded values are needed to fully interpret the class with which it is associated. stylesheet Core Glossary: A file that describes how to display an XML document of a given type subclass Core Glossary: A class that is the specialization of another class (superclass). subject area Core Glossary: A convenient aggregation of modelclasses used to partition large models into manageable subsets. subject class Core Glossary: A class that a Technical Committee designates as the central focus of a collection of messages. sub-section Core Glossary: In the HL7 V3 Guide, a section within a major section. sub-state Core Glossary: An identifiable state of a class that has a more specific definition than, and is entirely encompassed within the scope of, its super-state. superclass Core Glossary: A class that is the generalization of one or more other classes (subclasses). super-state Core Glossary: A state of a class that encompasses two or more independent sub-states. Supporting Documentation Defined in Claims & Reimbursement: Forms, Reports, Attachments submitted by Third Parties (e.g., Employer) to a Payor that may be applicable to a Healthcare Invoice. Submission not included in scope of NeCST. surface form (of a concept) Core Glossary: A code value or textual description that represents a concept identified by an HL7 concept identifier. There may be many different surface forms associated with a single concept identifier. system Core Glossary: 1. An end user application. Core Glossary: 2. In HL7, a group of messages that work together. (Return to glossary index) |
||||
1.20 |
T |
|||
| table view Core Glossary: An expression of the Hierarchical Message Description (HMD) common and message type definition condensed in size to fit on a printed page. Third Party Administrator (TPA) Defined in Claims & Reimbursement: A TPA is an organization retained by a Payor to receive and apply Payor rules, validate Healthcare Invoices and issue payments on behalf of the Payor. tightly coupled Core Glossary: Tightly coupled application roles assume that common information about the subject classes participating in a message is available to system components outside of the specific message. Time Charge Defined in Claims & Reimbursement: An extra time charge in addition to the professional fee that may be charged by a pharmacist when preparing a compound. TPA/Payor Defined in Claims & Reimbursement: A label used to refer to processes that may be performed by either a TPA or Payor. For example, in some circumstances a Payor may both administer a Healthcare Invoice and authorize benefits, while in other circumstances a Payor may act as a TPA for another Payor. transaction Core Glossary: A complete set of messages for a particular trigger event, e.g., a message and a response. transport wrapper Core Glossary: A wrapper that contains information needed by a sending application or message handling service to route the message payload to the designated receiver. All HL7 V3 messages must have an appropriately configured transport wrapper. trigger event Core Glossary: An event which, when recorded or recognized by an application, indicates the need for an information flow to one or more other applications, resulting in one or more interactions. Types of Annotation to Region Relationships Defined in Regulated Studies: There are some annotation codes that can mean slightly different things depending on the context. For example, the annotation "Atrial Fibrillation (AFib)" could mean two different things when related to a region: "The subject was in AFib here.", or "The subject experienced an episode of AFib from here to there." There are 2 act relationships in HL7 to distinguish between these two types of annotations. The "has support" relationship is the more general one to be used for "there is AFib here" types of annotations. The "has bounded support" relationship can be used to declare the boundaries of the annotation, "there is a (bounded) episode of AFib here." (Return to glossary index) |
||||
1.21 |
U |
|||
| UML Core Glossary: See Unified Modeling Language. Unified Modeling Language Core Glossary: A language for the creation of domainmodels. UML was created in order to unify several well-known object-oriented modeling methodologies, including those of Booch, Rumbaugh, Jacobson, and others. union message Core Glossary: A message type that contains the elements of several message structures drawn from the same Hierarchical Message Description. A union message includes all the message elements that must be sent from one application role to all other application roles in response to a trigger event. universal CMET Defined in Common Message Element Types: A CMET variant that includes all attributes and associations present in the R-MIM. Any of non-mandatory and non-required attributes and/or associations may be present or absent, as permitted in the cardinality constraints. Up-charge Defined in Claims & Reimbursement: A percentage that may be added to the cost of a product when calculating the cost of a claim. user Core Glossary: In the context of conformance claims, the organization that uses an application. This is frequently the buyer but in some cases the user and sponsor organizations may be parts of the same organization, or otherwise have a business relationship other then vendor-buyer. (Return to glossary index) |
||||
1.22 |
V |
|||
| V3 Guide Core Glossary: A companion to the V3 Standard which contains the methodological information an HL7 member needs to understand the V3 standard. Valid Document Core Glossary: A document which meets all of the validity constraints in the XML Specification value set Core Glossary: A vocabulary domain that has been constrained to a particular realm and coding system. Vision Product Billable Act Defined in Claims & Reimbursement: The set of information to describe the dispensing of a vision care product to a patient that is billed in an invoice. This may include among other things - date of service, vision care product specification, prescription and prescriber, performer, location and diagnosis. vocabulary Core Glossary: The set of valid values for a coded attribute or field. For more information refer to the Vocabulary section of the V3 Guide. vocabulary domainCore Glossary: The set of all concepts that can be taken as valid values in an instance of a coded attribute or field; a constraint applicable to code values. For more information refer to the Vocabulary Domains section of the V3 Guide. vocabulary domain qualifierCore Glossary: Part of a vocabulary domain specification. The two existing qualifiers are extensibility and realm. For more information refer to the Vocabulary Domain Qualifiers section of the V3 Guide. vocabulary domain specificationCore Glossary: A column in the Hierarchical Message Description that specifies the vocabulary domain associated with a coded attribute. (Return to glossary index) |
||||
1.23 |
W |
|||
| W3C Core Glossary: The World Wide Web Consortium, an international industry consortium W3C Schema Core Glossary: The three-part schema specification issued by the W3C
Waveform Encoding Defined in Regulated Studies: The rhythm waveforms are encoded as an Observation Series in HL7. The series contains one or more Correlated Observation Sequences ("correlation" for short). Each correlation encodes the leads that were sampled together and correlated with the same relative time points. If all 12 leads were sampled together (assuming a 12-lead ECG), only one correlation is required. This correlation would contain a sequence for relative time and 12 sequences for the 12 different leads. If time was evenly sampled (as it usually is), a GLIST<> is used for generating the sequence of time points from a few parameters. The lead sequences would use the SLIST<> for encoding the voltages. The SLIST<> can factor out a common offset and scale factor (if the raw integer A/D values encoded). The offset and scale factor can be used for converting the stored values to real physical quantities. If a 12-lead ECG is recorded on a device that only samples 3 leads at a time, for example, the Observation Series would contain 4 correlations. Each correlation would encode the leads that were sampled together. Each correlation would contain one sequence for time relative to the beginning of the recording, and 3 sequences for the 3 leads sampled. If the device has a few more channels and records one or more rhythm leads during the whole recording, the rhythm leads would appear in each correlation as well. Well-formed document Core Glossary: A document which meets all of the well-formedness constraints in the XML Specification wrapper Core Glossary: The control or envelope information in which the message payload resides. See transport wrapper and control event wrapper . (Return to glossary index) |
||||
1.24 |
X |
|||
| XHTML Core Glossary: XHTML 1.0. A Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26-January-2000, revised 1 August 2002 XML Core Glossary: See Extensible Markup Language. XML Declaration Core Glossary: An XML document consists of a prolog, root document element, and other objects. A data object is an XML document if it is well-formed, as defined in the XML specification. XSL Core Glossary: Extensible Style Language, a specification of the W3C An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary. XSLT Core Glossary: XSL transformation language, a specification of the W3C A language for transforming XML documents into other XML documents. (Return to glossary index) |
||||
1.25 |
Y |
|||
1.26 |
Z |


Text with Jack
A Dashboard by Choe Choon Ho and Wong Tiong Kiat
View Dashboard Overview In Fullscreen
Distribution of Sentiment by Words
View Barchart in Fullscreen
Word Cloud
View Word Cloud in Fullscreen
Bubble Chart
View Bubble Chart in Fullscreen
Word Tree
View Word Tree in Fullscreen
Distribution of Sentiment by Words
Word Cloud
Bubble Chart
Word Tree


Before Change
// Check for cyclic dependencies in the test name graph
visited = set()
unvisited = list(
itertools.zip_longest(test_graph.keys(), [], fillvalue=None)
)
path = []
while unvisited:
node, parent = unvisited.pop()
while path and path[-1] != parent:
After Change
// Check for cyclic dependencies in the test name graph
visited = set()
sources = set(test_graph.keys())
path = []
// Since graph may comprise multiple not connected subgraphs, we search for
// cycles starting from all possible sources
while sources:
unvisited = [(sources.pop(), None)]
while unvisited:
node, parent = unvisited.pop()
while path and path[-1] != parent:
path.pop()
adjacent = reversed(test_graph[node])
path.append(node)
for n in adjacent:
if n in path:
cycle_str = "->".join(path + [n])
raise DependencyError(
"found cyclic dependency between tests: " + cycle_str)
if n not in visited:
unvisited.append((n, node))
visited.add(node)
sources -= visited


munch
Settings
Change Username/Password
Push Notifications
Notify me if my food expires within:
Never
1 hour
1 day
3 days
1 week
Logout


Compare the outputs from exiftool against exiftool.js and Gomfunkel's node-exif
| tag | exiftool | exiftool.js | Gomfunkel | Redaktor |
|---|---|---|---|---|
| AFAreaMode | Single (135 points) | - | - | - |
| AFFineTune | Off | - | - | - |
| AFFineTuneAdj | 0 | - | - | - |
| AFFineTuneIndex | n/a | - | - | - |
| AFInfo2Version | 0200 | - | - | - |
| AFPointsUsed | B11 | - | - | - |
| ActiveD-Lighting | Off | - | - | - |
| Aperture | 4.2 | - | - | - |
| AutoFocus | On | - | - | - |
| BitsPerSample | 8 | - | - | - |
| BlueBalance | 0.019562 | - | - | - |
| Brightness | Normal | - | - | - |
| CFAPattern | [Red,Green][Green,Blue] | 0,2,0,2,0,1,1,2 | - | [Red,Green][Green,Blue] |
| CircleOfConfusion | 0.011 mm | - | - | - |
| ColorBalanceVersion | 0400 | - | - | - |
| ColorComponents | 3 | - | - | - |
| ColorSpace | Uncalibrated | 65535 | 65535 | |
| ComponentsConfiguration | Y, Cb, Cr, - | Y, Cb, Cr, - | - | - |
| Compression | JPEG (old-style) | - | 6 | 6 |
| Contrast | Normal | Normal | 0 | - |
| ContrastDetectAF | Off | - | - | - |
| CreateDate | 2011:06:19 15:29:30 | 2011:06:19 15:29:30 | 2011:06:19 15:29:30 | 2011:06:19 15:29:30 |
| CropHiSpeed | Off (3904x2606 cropped to 3904x2606 at pixel 0,0) | - | - | - |
| CustomRendered | Normal | Normal | 0 | - |
| DateDisplayFormat | Y/M/D | - | - | - |
| DateTimeOriginal | 2011:06:19 15:29:30 | 2011:06:19 15:29:30 | 2011:06:19 15:29:30 | 2011:06:19 15:29:30 |
| DaylightSavings | Yes | - | - | - |
| DependentImage1EntryNumber | 0 | - | - | - |
| DependentImage2EntryNumber | 0 | - | - | - |
| DigitalZoomRatio | 1 | 1 | 1 | 1 |
| EncodingProcess | Baseline DCT, Huffman coding | - | - | - |
| ExifByteOrder | Little-endian (Intel, II) | - | - | - |
| ExifImageHeight | 2592 | 2592 | 2592 | 2592 |
| ExifImageWidth | 3872 | 3872 | 3872 | 3872 |
| ExifVersion | 0230 | 0230 | - | 2.3 |
| ExposureCompensation | 0 | - | 0 | 0 |
| ExposureDifference | 0 | - | - | - |
| ExposureMode | Auto | 0 | 0 | - |
| ExposureProgram | Aperture-priority AE | Aperture priority | 3 | - |
| ExposureTime | 1/25 | 0.04 | 0.04 | 1/25 |
| FNumber | 4.2 | 4.2 | 4.2 | 4.2 |
| FOV | 13.3 deg | - | - | - |
| FileSource | Digital Camera | DSC | - | - |
| FilterEffect | n/a | - | - | - |
| Flash | No Flash | No Flash | 0 | - |
| FlashMode | Did Not Fire | - | - | - |
| FlashpixVersion | 0100 | 0100 | - | 1 |
| FocalLength | 57.2 mm | 57.2 mm | 57.2 | - |
| FocalLength35efl | 57.2 mm (35 mm equivalent: 154.0 mm) | - | - | - |
| FocalLengthIn35mmFormat | 154 mm | - | 154 | - |
| FocusMode | AF-S | - | - | - |
| GPSVersionID | <IP_ADDRESS> | <IP_ADDRESS> | 2,3,0,0 | <IP_ADDRESS> |
| GainControl | Low gain up | Low gain up | 1 | - |
| Gamma | 2.2 | - | 2.2 | 2.2 |
| HighISONoiseReduction | Normal | - | - | - |
| HueAdjustment | None | - | - | - |
| HyperfocalDistance | 69.80 m | - | - | - |
| ISO | 800 | 800 | 800 | 800 |
| ISO2 | 800 | - | - | - |
| ISOExpansion | Off | - | - | - |
| ISOExpansion2 | Off | - | - | - |
| ImageBoundary | 0 0 3872 2592 | - | - | - |
| ImageDataSize | 0 | - | - | - |
| ImageHeight | 8 | - | - | - |
| ImageSize | 8x8 | - | - | - |
| ImageWidth | 8 | - | - | - |
| InteropIndex | R03 - DCF option file (Adobe RGB) | - | R03 | R03 |
| InteropVersion | 0100 | - | - | 1 |
| Lens | 30-110mm f/3.8-5.6 | - | - | - |
| LensDataVersion | 0400 | - | - | - |
| LensFStops | 7.67 | - | - | - |
| LensModel | 1 NIKKOR VR 30-110mm f/3.8-5.6 | - | - | - |
| LensSpec | 30-110mm f/3.8-5.6 VR [4] | - | - | - |
| LensType | VR [4] | - | - | - |
| LightSource | Unknown | 0 | - | |
| LightValue | 5.8 | - | - | - |
| MPFVersion | 0100 | - | - | - |
| MPImageFlags | Dependent child image | - | - | - |
| MPImageFormat | JPEG | - | - | - |
| MPImageLength | 955803 | - | - | - |
| MPImageStart | 5322951 | - | - | - |
| MPImageType | Large Thumbnail (full HD equivalent) | - | - | - |
| Make | NIKON CORPORATION | NIKON CORPORATION | NIKON CORPORATION | NIKON CORPORATION |
| MakerNoteVersion | 2.1 | - | - | - |
| MaxApertureValue | 4.1 | 4.1 | 4.1 | - |
| MeteringMode | Multi-segment | Pattern | 5 | - |
| Model | NIKON 1 J1 | NIKON 1 J1 | NIKON 1 J1 | NIKON 1 J1 |
| ModifyDate | 2011:07:06 21:47:33 | 2011:07:06 21:47:33 | 2011:07:06 21:47:33 | 2011:07:06 21:47:33 |
| NEFBitDepth | n/a (JPEG) | - | - | - |
| NikonCaptureVersion | OTHER | - | - | - |
| NoiseReduction | Off | - | - | - |
| NumberOfImages | 2 | - | - | - |
| Orientation | Horizontal (normal) | 1 | 1 | 1 |
| PhaseDetectAF | On (hybrid) | - | - | - |
| PictureControlAdjust | Default Settings | - | - | - |
| PictureControlBase | Standard | - | - | - |
| PictureControlName | Standard | - | - | - |
| PictureControlQuickAdjust | Normal | - | - | - |
| PictureControlVersion | 0100 | - | - | - |
| PreviewImage | (Binary data 955803 bytes) | - | - | - |
| PrimaryAFPoint | B11 | - | - | - |
| PrimaryChromaticities | 0.64 0.33 0.21 0.71 0.15 0.06 | 0.64,0.33,0.21,0.71,0.15,0.06 | 0.64,0.33,0.21,0.71,0.15,0.06 | 0.64,0.33,0.21,0.71,0.15,0.06 |
| ProgramShift | 0 | - | - | - |
| Quality | Fine | - | - | - |
| RatingPercent | 0 | - | - | - |
| RedBalance | 0.027359 | - | - | - |
| ResolutionUnit | inches | 2 | 2 | - |
| RetouchHistory | None | - | - | - |
| Saturation | Normal | Normal | 0 | - |
| ScaleFactor35efl | 2.7 | - | - | - |
| SceneCaptureType | Standard | Standard | 0 | - |
| SceneType | Directly photographed | Directly photographed | - | - |
| SensingMethod | One-chip color area | One-chip color area sensor | 2 | - |
| SerialNumber | 00000206 | 00000206 | - | - |
| Sharpness | Normal | Normal | 0 | - |
| ShootingMode | Single-Frame | - | - | - |
| ShotInfoVersion | 0400 | - | - | - |
| ShutterCount | 1343 | - | - | - |
| ShutterSpeed | 1/25 | - | - | - |
| Software | Nikon Transfer 2.2 W | Nikon Transfer 2.2 W | Nikon Transfer 2.2 W | Nikon Transfer 2.2 W |
| SubSecCreateDate | 2011:06:19 15:29:30.00 | - | - | - |
| SubSecDateTimeOriginal | 2011:06:19 15:29:30.00 | - | - | - |
| SubSecModifyDate | 2011:07:06 21:47:33.00 | - | - | - |
| SubSecTime | 00 | - | 00 | 00 |
| SubSecTimeDigitized | 00 | - | 00 | 00 |
| SubSecTimeOriginal | 00 | - | 00 | 00 |
| SubjectDistanceRange | Unknown | 0 | - | |
| ThumbnailImage | (Binary data 9501 bytes) | - | - | - |
| ThumbnailLength | 9501 | - | 9501 | 9501 |
| ThumbnailOffset | 20082 | - | 20070 | 20070 |
| Timezone | +01:00 | - | - | - |
| ToningEffect | n/a | - | - | - |
| ToningSaturation | n/a | - | - | - |
| VRInfoVersion | 0101 | - | - | - |
| VRMode | Active | - | - | - |
| VariProgram | - | - | - | |
| VibrationReduction | On | - | - | - |
| WB_RBLevels | 7.00390625 5.0078125 0.0078125 0.0078125 | - | - | - |
| WhiteBalance | Auto | Auto | 0 | - |
| WhiteBalanceFineTune | 0 0 | - | - | - |
| WhitePoint | 0.313 0.329 | 0.313,0.329 | 0.313,0.329 | 0.313,0.329 |
| XMPToolkit | XMP Core 4.1.1 | - | - | - |
| XResolution | 300 | 300 | 72 | 72 |
| YCbCrCoefficients | 0.299 0.587 0.114 | 0.299,0.587,0.114 | 0.299,0.587,0.114 | 0.299,0.587,0.114 |
| YCbCrPositioning | Centered | 1 | 1 | 1 |
| YCbCrSubSampling | YCbCr4:2:0 (2 2) | - | - | - |
| YResolution | 300 | 300 | 72 | 72 |


Connect your Google Spreadsheet to {{config.SERVICE_NAME}}. Then you can use mustache templates to display your data, or post new data with a form.

<form action="{{config.API_ROOT}}/WRITE_KEY" method="POST">
<input type="text" name="Price">
<input type="text" name="Title">
<input type="text" name="Quantity">
<input type="submit" value="Send">
</form>
We're the same folks who make Brace.io, the simple way to host websites. {{config.SERVICE_NAME}} is a side project that solves a problem many of Brace.io users seem to face: incorporating dynamic data into otherwise static HTML pages.
We don't store the contents of your spreadsheet. Instead we generate two access keys that link our APIs to your spreadsheet, one for reading and one for writing. You can delete these keys at any time to revoke access.
{{config.SERVICE_NAME}} is free for 1000 API calls per spreadsheet each month. If you need more, please reach out.
Yep, for now we cap API calls to 1000 per spreadsheet for each month. If you need more, please reach out to {{config.CONTACT_EMAIL}}.
{{config.SERVICE_NAME}} is a tool made by Brace.io. To contact us send an email to {{config.CONTACT_EMAIL}} or use the form on the right.


How to update a dapp chain¶
Dapps evolve over time. And in this section, we discuss what to do in order to seamlessly update a dapp’s chain to new version.
There are 2 approaches to update a chain:
Specify different config entry points for old and new versions, or
Reference compiled configuration of old version
Project structure before update¶
For both approaches, we will use an example project with a basic ft3 structure.
We have all of our chain’s code within rell/src
folder:
rell/src
├── lib
│ ├── ft3
│ └── … (other optional libraries)
└── module.rell
And our config.template.xml
should look like the following:
<run wipe-db="true">
<nodes>
<config src="../../node-config.properties" add-signers="true" />
</nodes>
<chains>
<chain name="YOUR_CHAIN_NAME" iid="0">
<config height="0">
<app module="">
<args module="lib.ft3.core">
<!-- ... (your chain configs) -->
</args>
</app>
</config>
</chain>
</chains>
</run>
Contents
Update by specifying different entry points¶
Use this approach when you want to have a clear overview of old version’s code.
Note
An example project to demonstrate this approach is available at branch example/update-chain-keep-old-code
of develop-chromia
:
git clone https://bitbucket.org/chromawallet/develop-chromia.git
git checkout example/update-chain-keep-old-code
Restructure the code¶
As mentioned ealier, the target of this approach is to have clear overview of old code after several updates. So it might be considered good procedure to create different entry module for each chain version.
We will name each module with the current version tag, so that it will be clear what has been run in the past. After that, we will update the config.template.xml
file by adding each version configuration and the height at which the changes will become effective.
The rell structure will then look like:
rell/src
└── v0_0_1
├── lib
│ ├── ft3
│ └── … (other optional libraries)
└── module.rell
So essentially we just created a folder v0_0_1
inside src
and moved the all the previous files there.
We will need to update the config.template.xml
file to reflect this change. Note the change at <app>
and <arg>
tags:
<run wipe-db="true">
<nodes>
<config src="../../node-config.properties" add-signers="true" />
</nodes>
<chains>
<chain name="YOUR_CHAIN_NAME" iid="0">
<config height="0">
<app module="v0_0_1">
<args module="v0_0_1.lib.ft3.core">
<!-- ... (your chain configs) -->
</args>
</app>
</config>
</chain>
</chains>
</run>
Note
As a matter of information, the project’s entry path is specified under postchain/config/nodes/dev/blockchains/app/entry-file.txt.
Confirm the new configuration is working properly by starting the chain:
./postchain/bin/run-node.sh dev
Adding new codes¶
Now that we have restructured the code, we can upgrade the code. To do that we copy v0_0_1
folder and rename it v0_0_2
.
rell/src
├── v0_0_1
│ ├── lib
│ │ ├── ft3
│ │ └── … (other optional libraries)
│ └── module.rell
│
└── v0_0_2
├── lib
│ ├── ft3
│ └── … (other optional libraries)
└── module.rell
For easy testing, we can add one new query in the module.rell
file of v0_0_2
:
module;
import lf: .lib.ft3.ft3_basic_dev;
query get_version() {
return "0.0.2";
}
If everything works correctly we will not receive any response when running the module v0_0_1
but we will receive 0_0_2
when running the module v0_0_2
.
Set the migration to new module¶
To migrate to the new module, we need to update the config.template.xml
file.
We will add a new <config>
tag inside our <chain>
, and set it to be enabled at a certain (block) height
:
<run wipe-db="true">
<nodes>
<config src="../../node-config.properties" add-signers="true" />
</nodes>
<chains>
<chain name="YOUR_CHAIN_NAME" iid="0">
<config height="0">
<app module="v0_0_1">
<args module="v0_0_1.lib.ft3.core">
<!-- ... (your chain configs) -->
</args>
</app>
</config>
<config height="20">
<app module="v0_0_2">
<args module="v0_0_2.lib.ft3.core">
<!-- ... (your chain configs) -->
</args>
</app>
</config>
</chain>
</chains>
</run>
In this example, after 20 blocks the chain will change app module to v0_0_2
.
Important
Ensure that the block height for the new configuration is safely higher than current height.
Setting a block height that is lower than current height might cause problems to nodes that want to sync by re-applying all the transactions.
Test the chain¶
Start our chain with
./postchain/bin/run-node.sh dev
Recall the new query get_version()
we created earlier. We can test the chain’s version with a simple script such as:
const pcl = require('postchain-client');
const node_api_url = "http://localhost:YOUR_NODE_PORT";
// default blockchain identifier used for testing
const blockchainRID = YOUR_NODE_BRID;
const rest = pcl.restClient.createRestClient(node_api_url, blockchainRID, 5);
const gtvHash = pcl.gtv.gtvHash;
const gtx = pcl.gtxClient.createClient(
rest,
Buffer.from(blockchainRID, 'hex'),
[] );
const gtv = pcl.gtv;
const gtxU = pcl.gtx;
( async () => {
try {
const version = await gtx.query("get_version", {});
} catch (e) {
console.log("New version not yet implemented");
} finally {
if(version) {
console.log(`New version running: ${version}`)
}
}
})();
We can monitor the blockchain by linking it to the Explorer :
At block 20 we will start getting a result back from the chain. It will return something like:
POST URL http://localhost:7743/query/A54320E7D063AB94513467806FE800A1B95B26BF65C4F11D30C5D65859E4025C
0.0.2
Update by referencing old configuration¶
The second approach that can be used is to specify previous compiled configurations in the config tag.
Use this approach if you want cleaner code structure.
Note
An example project to demonstrate this approach is available at branch feature/CCD210-update-chain-tutorial
of develop-chromia
:
git clone https://bitbucket.org/chromawallet/develop-chromia.git
git checkout feature/CCD210-update-chain-tutorial
What does run-node.sh do?¶
In order to discuss this approach, we must first explain what happened when you execute ./postchain/bin/run-node.sh dev
in the console.
This command does 3 things.
First it creates a target folder where the compiled blockchain configuration will be placed, something like:
mkdir -p ./postchain/runtime/nodes/dev
Then it generates the blockchain configuration by compiling the rell code with the
config.template.xml
file.
If it is a new chain (e.g. started with the -W
option), the BRID is also generated at this step. Since we are dicussing updating a chain here, we don’t want the BRID to change, so -W
option should never be called while updating.
./postchain/lib/multigen.sh ./postchain/config/nodes/dev/blockchains/app/config.template.xml -d ./rell/src -o ./postchain/runtime/nodes/dev/
It should create the following architecture inside postchain/runtime/nodes/dev
:
postchain/runtime/nodes/dev
├── blockchains
│ └── 0
│ ├── 0.gtv (creates a one file rell module)
│ ├── 0.xml (creates the configuration that will be run, also by using the just created 0.gtv)
│ └── brid.txt (just a file where is output the brid of the chain, n.b. it will remain constant nevertheless the updates)
│
├── node-config.properties
└── private.properties
Finally, it runs the new configuration with
./postchain/lib/postchain.sh run-node-auto -d ./postchain/runtime/nodes/dev
Backup old configuration¶
Compile the current code (by executing ./postchain/bin/run-node.sh dev
or only step 1 and 2 described above).
In the generated configuration folder, copy runtime/nodes/dev/0.xml
into postchain/config/nodes/dev/blockchains/app
, and rename it 0.0.1.xml
Adding new codes¶
In the previous approach, we were keeping track from a code point of view of previous versions. This time we will not do that, so we can change the current code directly without copying anything.
Let’s just add the query into the module.rell
file:
module;
import lf: .lib.ft3.ft3_basic_dev;
query get_version() {
return "0.0.2";
}
Set the migration to new module¶
Update the config.template.xml
file to config the migration.
Note that unlike the other approach, this time we don’t have to change the <app>
and <args>
tags:
<run wipe-db="true">
<nodes>
<config src="../../node-config.properties" add-signers="true" />
</nodes>
<chains>
<chain name="YOUR_CHAIN_NAME" iid="0">
<config height="0">
<gtv src="0.0.1.xml"/>
</config>
<config height="20">
<app module="">
<args module="lib.ft3.core">
<!-- ... (your chain configs) -->
</args>
</app>
</config>
</chain>
</chains>
</run>
Important
Ensure that the block height for the new configuration is safely higher than current height.
Setting a block height that is lower than current height might cause problems to nodes that want to sync by re-applying all the transactions.
Compile the new configuration and start the chain:
./postchain/bin/run-node.sh dev
We can now Test the chain as before. If we try to query for get_version()
after block 20 we will see 0.0.2
.


My impression of DBC
Magda Ang
May 16th, 2014
Unlike many of my fellow boots, when I first heard "DevBootCamp" was really strange for me. In Mexico we don't have such things, not where I live anyway. So when my sister told me it would be a great opportunity to learn and to practice my English, my actual words were "Dev Boot what??" then she explained, sent some links, videos, etc. My answer was "Ok, I'll think about it". As soon as I started doing the research, my attitude changed and I thought "This is something I MUST do".
My first impression of DBC is that is harder than I expected. I'm spending way more than the 20hrs/week they said phase_0 would take. I believe my husband and kids are thinking about leaving me, hahaha, just kidding! But really, I need to organize myself better.
So here I am, working hard, with lots of questions, worried about having the 'impostor syndrome', and nervous that my English skills may not be good enough to succeed. On the other hand, after watching Shereef's video I feel more confident. You don't get everybody looking and pointing at you if you don't understand something, questions are even expected at DBC! I must remember that and not be ashamed. I know I can do this! DBC is more than just a learn-Ruby-in-9-weeks program, it challenges you to develop that engineering sense, to be a better version of yourself, to be humble, to be happy. I definitely see myself engaged in this type of culture!
Nervous? Yes. But I'm sure this is going to be one of the best experiences in my life. I'm looking forward to it!


#include <frame.h>
Public Member Functions | |
| Value | setSlot (const Symbol &name, const Value value) |
| Value | getSlot (const Symbol &name) |
| virtual Value | eval (Value receiver, const Array &args) |
| virtual Value | send (Value receiver, const Symbol &selector, const Array &args) |
Reimplemented in impulse::Method, impulse::runtime::Message, impulse::runtime::MulMessage, and impulse::runtime::Expression.
| Value impulse::Frame::send | ( | Value | receiver, | |
| const Symbol & | selector, | |||
| const Array & | args | |||
| ) | [inline, virtual] |