Orders PDD - About



Orders Model & Terminology

Introduction

This document will describe the design of the Clinical Models and Terminology content for Orders. The Order models[1] are used to store data captured as Clinician Orders by the Physician Order Entry Application.

1 Purpose

This document describes the design, creation and meaning of the Order models and Terminology content for supporting the models.

2 Scope

This document describes in detail the Order models and also the specific components for the Order models. It does not cover the generic components such as Observed, Verified, etc. These should be covered in separate documentation and while central to CDL, they are not central to the meaning of the Order models. Some of the terminology is dependent on the structure and content of externally imported pharmacy data (such as FDB). This being the case the final structure and content of terminology domains (value sets) is yet to be determined.

References

The following table lists other documents associated with the Orders models and Terminology.

|Document |Link |

|OrderTypeBreakdown.xlsx |

| |roject/Documentation/PDD%20Documentation/OrderTypeBreakdown.xlsx |

|OrderModelDiagrams.vsd |

| |roject/Documentation/PDD%20Documentation/OrderModelDiagrams.vsd |

|Orders Model.pptx |

| |roject/Documentation/PDD%20Documentation/Orders%20Model.pptx |

Definitions, Acronyms and Abbreviations

|Term |Definition |

| | |

| | |

Design Convention

The clinical model and Terminology content documentation is intended to capture the knowledge of the design and the creation of the Orders models and Terminology content. The design of the models is represented with the outline of the model and explained with design decisions and considerations.

Design Overview

1 Orders Models

The main requirements on the design of the current Orders models are from the Intermountain Physician Order Entry Application. The goal is to support both the data storage and retrieval for the new Order Application into the Qualibria CDR. The primary sources for information to construct this model are from Keith Larsen and Joey Coyle. Keith has made detailed study of existing orders structures and is the primary designer of the new orders system.

2 Orders Terminology

In addition to the Terminology which enables the Orders models, such as the Terminology for the CE types, the keys, the domain constraints and etc., external source for medications order will be utilized. The current plan is to use First Data Bank (FDB ) as a primary source for medication order terminology, although the details about such utilization have not yet materialized.

3 Orders Model Structural Overview

[pic]

Figure 1 Order Model General Structure

1 Order Container:

This topmost node refers to the order in its entirety. An order is characterized by a single defined action, intervention, or diagnostic, in a single domain, that the clinician desires for the patient. This single desired action can have multiple sub-parts, but is not scoped to include multiple orders in a protocol or order set. The qualifiers at this level are qualifiers to all the Order segments within the Order Container.

The Order Container node serves as a container for multiple Orders in the traditional sense. In the vast majority of orders, such a container would be unnecessary as most orders are not complex. Most order systems fail, however, by their inability to express complex orders.

2 Order:

The Order segments (there can be more than one) represent orders within the Order Container and are linked to the Order Container by a relationship between them. An example is an alternating infusion order where the alternating infusion bottles are each defined in separate Order segments and the relationship between the infusion bottle Order segment is defined in the Order Relationship qualifier of the Order Container structure.

In the vast majority of orders, there will only be one Order segment.

3 Order Item:

Each Order segment can have one or more Order Item segments. Using the previous example of medication infusions, each infusion bottle can contain multiple medications.

In the vast majority of orders, there will be only one Order Item segment within an Order segment.

4 General Model Usage

The general orders model is abstract, i.e., it cannot be instantiated itself. Its purpose is to create a parent structure for all orders. Children, or subtypes, of the order structure will be created from the Order Container structure through a pseudo-restriction process. That is, the Order Container structure defined herein is a superset of all qualifiers. In CDL, qualifiers are restricted by changing the allowed value of the cardinality attribute of an item within the allow range of cardinality defined in the general orders model. The qualifiers are not actually removed with this technique; they are ignored or not ignored, based on the value of the cardinality of the item.

[pic]

Figure 2 : The instantiable children, or subtypes, of the general orders model.

1 Qualifiers per subtype

1 See Orders Type Breakdown reference spreadsheet for better detail.

[pic]

Figure 3: Qualifiers that have been “restricted” out for each child or order subtype

Order Container glossary of objects.

1 OrderName: Name of the Order Container. This was added so that the entire container could have a usable name for retrieval.

2 RelatedOrder (Removed): Contains references to related orders. These related orders can be of the following types: ParentOrder, ChildOrder, SubsequentOrder or PreviousOrder. These orders are generated at order creation time. They are not created after or independently. See Semantic Links Section.

3 OrderRelationship: This field is not related to the RelatedOrder field above. This field defines whether the order as a whole is: “Simple”, “Or”, “Alternating”, “Then”, or “Complex”. The default is “Simple”. The purpose of this model is to simplify implementation, instead of dealing with the complexity of implementing a string expression. For example, if the order model is “Or”, then the relationship among all the orders in this order container is OR.

If the clinician wants to get more complex, then the string choice is used for storage of the relationship string created by the clinician (e.g. "(A and B) or C"). For this reason the string alternate choice has been explicitly exposed in the model.

5 OrderNumber (Removed): This is the order number generated by the Orders Service (the orders application). It is unique across all patient encounters, patients, and facilities within the enterprise. This was removed because the system is handling this id number automatically. If an ID is necessary then use ExternalOrderNumber.

6 ExternalOrderNumber: This is the order number or numbers generated by a non-ECIS system. The purpose is to have a cross map between the OrderNumber and any number of ExternalOrderNumbers in associated contexts. One order may have multiple order numbers. "Context" refers to the particular system that generated the order number. Since the datatype is II, it is presumed at this point that the “root” of II is sufficient to contain the system information of the external order number.

This field goes beyond the HL7 specification for “sender” and “receiver” systems; any number of systems can be applied and directionality is not required.

The existence of this field should not create the assumption that this orders model is “interface ready.” The current purpose of this orders model is to provide a structure for a provider order entry application.

9 OriginationMode: The mode the order was received (telephone, electronic, verbal, or written).

10 OrderStatus: The purpose of this qualifier is to support workflow. The terminology domain for this qualifier is the same across all orders, but may be a constrained domain in each subtype (e.g., the workflow on a lab order may be different from the workflow for medication orders. Need to get HL7's State Diagrams for orders to inform values for this domain. (Version 3) Order being a kind of act therefore the values are: new, active, completed, held, cancelled, aborted, suspended, nullified or obsolete. In addition, a "normal" state is defined in HL7 to encompass all states of an act, but excludes "nullified" and "obsolete" which represent unusual terminal states for the life-cycle.

11 EditFormId: Used to link back an order instance with the form to collect/edit the information.

12 ProcessType: This links the order to a specific order fulfillment process. For example, the ProcessType of “Chemotherapy” would have a specific order fulfillment process including work lists, notification routings, etc. The ProcessType domain will be set up by each customer site as well as the mappings between specific orders and the ProcessTypes.

13 ReadingRequest: For imaging if we want another group to read the exam. The purpose of the field is to route the order for documentation. The choices for this field are governed by contract.

14 StartCondition: The expression of the start condition of the order. The conditions (coded, string or date/time) governing the starting of the parent order container. (See section: How conditions work)

15 HoldCondition: The expression of the hold condition of this order. The conditions, if met, that will place the order on hold. The vast majority of order will not use this item. (See section: How conditions work)

16 StopCondition: The conditions (coded, string or date/time) governing the stopping of the parent order container. This condition is optional; e.g., the future discontinuation of the order is not known at order time - the order will be discontinued manually by the clinician when they determine that the order is no longer needed. (See section: How conditions work)

17 CollectionPriority: This is fulfillment priority used primarily by lab. It is the urgency for which an order must be fulfilled. Order Priority was move to the Order level from the order container level, recognizing that each segment of an order may have its own priority. For a lab draw, however, we can predict that a single collection will occur for each item in the lab order and so the collection is governed by the item with the highest priority.

18 OrderJustification: Order Justification lists any required items to explain the "why's" of the order. This is not a semantic link because the justification is made at the time of the order by the practitioner and alterable only by the practitioner. Billing may use this justification, but billing cannot create this justification. Any justification created in the billing use cases will need to be of a different structure. Current values for the key domain are: Diagnosis, Signs and Symptoms, and Health Issue. The action in the application will occur something like this: A practitioner may choose justification from a list or from the problem list of the patient. If the practitioner chooses a problem from a list then the application will ask: do you want to add this to the patient's problem list? If yes then the problem will be create in a model structure, if no then the Ecid for the Health Issue will be stored. Because the Health Issue domain is not sub categorized we perform the categorization of the health issue via the key domain chosen. The "otherwise error" line exists because this model is meant for application use and should have an expectation of what is allowed. See Semantic Links Section.

19 OrderedForProtocol: The protocol used to generate the order. For example, if a pneumonia protocol says to do a CBC at a given condition, then the value for this field would be “pneumonia protocol”.

20 ReportResultsTo: This model captures the target person/organization which will receive the report on the orders outcome.

21 RequestedFindings: This is used in radiology or lab (micro) to ask for a specific thing within the order to make note of or determine. For example, an x-ray with a note to the radiologist specifically requesting he determine the current size of a lesion.

22 OrderSetId: If the order was placed through use of an order set, this is the identifier of the order set.

23 LabelInstruction: Patient instructions that will appear on the label of an ambulatory medication. These are usually provided as part of a medication database. Example, "Give with food".

24 ProviderInstruction: This field contains the ordering provider's instructions to the patient or the provider administering the drug or treatment. This is called "Directions" in Centricity Pharmacy which creates an English translation of the dose and frequency which then can be added to or changed by the pharmacist. (HL7 definition, RXE-7)

25 SpecialHandling: Built to accommodate special conditions in execution of the order. Particularly in radiology type orders or other type of orders where transportation of the patient is necessary. Some examples of values could be: diabetes, fractures(s), fragile skin, isolation, no special handling, nurse to assist, etc...

26 AdministrationInstruction: This field contains the pharmacy or treatment supplier's provider-generated special instructions to the provider dispensing or administering the order. This is called "MARnotes" in Centricity Pharmacy and is displayed on the MAR, not to the patient. This should be visible to all clinicians, but not to the patient. (RXE-21 definition

27 OrderComment: A comment or a list of comments for this whole order.

28 SessionID: Numeric identifier identifying the order session. This is used while the provider is making the order. It allows the provider to leave an ordering session either intentionally or through time out and then return to the session later to complete the ordering process. This number has no use after the ordering process is completed and, therefore, can be deleted at that point.

29 OrderCalculationData: This model is used to store the data used to calculate the order. This is done to meet the legal requirement to retrace the thought process of the order. Values for the domain will be Weight, Height, Body Surface Area or Serum Creatinine. Some clarification needs to be drawn as to why this item should not be a reference to stored data:

1 This should not affect data mining efforts because it is not technically a true patient value. We are not capturing "patient weight" - we are capturing "the weight used to calculate the order."

2 This weight may or may not truly reflect the patient's own weight, but be a reasoned amount necessary to create the proper dose. And so to create a store "weight" instance based on data used here could actually corrupt the true meaning of "weight", by throwing in a new nuance of weight "weight estimated for purposed of medication or order.

30 PerformingLocation: The location where an order is to be performed. This is not to record where a procedure actually occurred.

31 PerformingDateTime: The date and time of appointment information after a procedure has been scheduled. This may be completed by the ordering provider, if known; otherwise the scheduling note may be used.

32 SchedulingNote: Contains a note from the office to a scheduler outlining the patient's preference for the appointment.

33 Discontinued (attribution): This holds the Who/When/Why/Where information about when/if the order was discontinued.

34 CounterSigned (attribution): This holds the Who/When/Why/Where information about when/if the order was counter signed.

35 Ordered (attribution): This holds the Who/When/Why/Where information about when/if the order was ordered.

36 PutOnHold (attribution): This holds the Who/When/Why/Where information about when/if the order was put on hold.

37 TakeOffHold (attribution): This holds the Who/When/Why/Where information about when/if the order was taken off hold.

Order segment Glossary of qualifiers

For data types and structures not specifically referenced, see the actual models and CDL reference guide:

2 ActionVerb: For ambulatory med orders ("Take", "Apply", etc.). The primary action of administration directed at the patient.

3 OrderSpecialRequirement: Order Special Requirements is to record any special procedures or requirements for the order, i.e., sedation for radiology orders, CVM Neg for blood products, etc.

4 OrderPriority: This is the priority of the overall order; e.g., "STAT".

5 RouteMethodDevice: Route or method of this order, e.g. IV, oral, chew, etc.

6 SIG Text: Signature Text. This is for ambulatory meds to ensure the signature goes all the way into the receiving system.

7 TotalVolume: This is the total volume of the order segment; i.e., it is the sum of all the contributing volumes of the Order Item segments. This applies to continuous infusions and intermittent infusions.

8 Frequency: This container can hold multiple frequency definitions for the Order. The implied relationship between these is "AND". Frequency can be absent if the PRNInd is set, otherwise, there must be at least one frequency.

1 Frequency Glossary of items

2 Expression: Used in this case to connect two expression term ids together. In this case it will connect two or more frequency items together. “A and B or C”, etc.

3 FrequencyItem: A container to hold the detail of each frequency used in the order.

1 DailyDoseCount: Data type integer. For example, if TID is the CodedFrequency, then the daily dose count is 3. This is set by the CEM Orders Service from data stored with the CodedFrequency definitions. The purpose is to support decision support activities. If this is based on a variable frequency, it is the maximum expected doses in a 24-hour period.

2 Expression Term ID: An id assigned by the application to identify a particular sub structure. This is used to identify a specific FrequencyItem if there are more than 1 FrequencyItems. This is used in the Expression.

3 CodedFrequency: Specific named Frequency; e.g., BID, TID, etc. If PeriodicFrequency… is instantiated, the value of this field will be "every" or "q=". In that case, it is not clear whether choosing "every" as the frequency causes the collection of PeriodicFrequency.. or if collection of PeriodicFrequencyLowerLimit causes an automatic set of this field to "every".

4 PeriodicFrequencyLowerLimit: E.g. q4h, q6h. If q4h, then put "q" for the CodedFrequency and "4h" in PeriodicFrequencyLowerLimit. For ranges (e.g., "q 4 to 6 hours"), use both the LowerLimit and the UpperLimit. For a single value (e.g., "q 4 hours"), put into the LowerLimit.

5 PeriodicFrequencyUpperLimit:

6 AdministrationTime: Actual administration times during a single day for which the order is desired to be executed.

7 AdministrationDays: This container holds the modifiers to the daily schedule defined in fields above. If this is used, one and only one of the five sub-fields below is filled (i.e., "choice of" set).

1 DaysOfWeek: Coded days of the week; e.g., "Monday", "Tuesday", etc.

2 DaysOfMonth: Specific and repeating day of the month; e.g., if it is desired to give the dose the second day of each or specified month, then the value would be "2".

3 Date:

4 DaysOnOff: Number of days on and then days off

5 DayToEvent: The number of days related to an event as the frequency of administration.

9 PRNInd: This can be used as a modifier of the Frequency content or instead of the Frequency content. It states that the order is on an "as needed" basis. The give condition was separated out of this structure because it was recognized that something can be PRN with or without conditions and that an order may have “give” conditions without being PRN.

10 AdministrationPeriod: Time over which the administration should take place. Used in piggyback medication orders; such as in "infuse over 30 minutes".

11 StartCondition: The conditions (coded, string or date/time) governing the starting of this Order. If there is just one Order, then this information is stored in the Order Container node. See StartCondition in the Order Container glossary section.

12 StopCondition: The conditions (coded, string or date/time) governing the stopping of this Order. If there is just one Order, then this information is stored in the Order Container node. See StopCondition in the Order Container glossary section.

13 DispenseQuantity: Dispensing information used for ambulatory medications.

14 Refills: Number of refills for ambulatory medication orders only.

15 SpecimenDescription: This is a set of codes describing the specimen, body part, side, consistency, color, etc. Generally used for lab type orders.

16 CollectionMethod: Includes "clean catch", etc., for urine. How the specimen for lab type orders is collected.

17 TransportMode: Used by radiology to specify the method of moving the patient to radiology for the ordered diagnostic exam.

18 WhoCollects: For lab orders, the class of people responsible to collect specimens; e.g., "lab collects" or "floor collection". In HL7, this field is referred as SpecimenActionCode (OBR-11).

19 BodyLocation: Formerly AdminSite. Used for medications as the site of administration; for example, right arm.

20 Device: The type of device ordered for use to administer the medication. For example, Ensure is ordered, by PEC tube, to be administered by infusion pump as the device.

21 DirectionsForDosingRange: Comment field; triggered by range in frequency and/or in dose

22 RateContainer: Contains Volume Rate, Special Rate, Titration and PCA pump. These items are contained here for widget support.

1 Rate Container Glossary of items

1 Volume Rate: A volume rate. This applies to Intermittent Infusions and Continuous Infusions. This may be entered directly by the user or it can be calculated from a dosage rate. Dosage rates are stored in the Order Item with the specific medication. The system then calculates this volume rate.

2 Special Rate: Also a volume rate.

3 Titration: The action of increasing and/or decreasing a medication rate based on conditions and within narrowed parameters.

1 Titration Action: Increase, Decrease or Titrate

2 Starting Rate: A volume rate to begin the order.

3 IncrementalChangeLower: A volume rate of change. If there is not an upper change populated then the item is not a range and this field reflects the change allowed. If an upper change is populated then this field is the lower end of the range.

4 IncrementalChangeUpper: A volume rate of change. This is upper end of the range for which a titration is allowed.

5 Interval: Required time increment between changes.

6 MaxRate: A volume rate expressing the maximum dosage allowed.

7 GiveCondition: A qualifier that explains the conditions upon which the titration is to be executed. It has a similar structure to start condition or stop condition.

4 PCA Pump: Captures information regarding PCA Pump Orders.

1 Basal Rate: A volume rate that describes the start or baseline rate of the PCA medication delivery.

2 Bolus: Allowed amount allowed for nurse to give above and beyond regular programmed amount; Needs an amount with units and a frequency.

3 Lock out interval: The time between delivered doses where no medication is available.

4 Dose per push: The amount delivered to the patient upon pressing the delivery button.

23 Order Item segment Glossary of qualifiers

For data types and structures not specifically referenced, see the actual models and CDL reference guide:

2 Formulation: Form of this orderable item. It is a coded data. E.g. tablet, capsule, liquid, etc. This is a decomposition of the medication order. It is de-composed to support decision support.

3 IvComponentType: Indicates whether this is an additive or a base solution. This is part of the HL 7 definition.

4 ActiveIngredient: Structure containing an active ingredient for this medication and its strength. The active ingredient of this orderable item. Can be at least one ingredient or multiple ingredients.

1 CalculatedDoseMax: This is a service-generated field for decision support. The dose is calculated from the OrderedDose and Ingredient Strength fields. For example:OrderedDose of 2 tablet, each tablet is 400mg Strength, the calculated dose is 800mg. This is always calculated from the maximum of either the OrderedDoseLowerLimit and OrderedDoseUpperLimit.

2 Strength: The strength of the ingredient from the First DataBank tables as the service decomposes the medication orderable concept. Concentrations will be normalized to a single unit for concentrations; e.g., if FDB has 10mgm/5ml, this would be represented as quantity 2 and units "mgm/ml".

1 DiscreteStrength: The strength units separated out. For the above example it would be: 10 mgm.

2 DiscreteVolume: The volume units separated out. For the above example it would be: 5 ml.

3 AlternateDiscreteStrength: Occasionally manufacturers give an alternate strength for medications. This is typically the salted vs. nonsalted concentrations. This separates out those alternate strength units.

4 DiscreteTime: if the above example had a temporal component, such as per day as in a sustained release patch, that part of the strength would be recorded here: 24 hours, 1 second, etc.

5 AggregateStrength: The original text of the strength.

5 FilledSubstance: The medication that is used to actually fill the order. It may be different from what was ordered.

1 Formulation: Form of the substance what is actually being filled. It is a coded data. E.g. tablet, capsule, liquid, etc.

2 UsualRoute: The usual route of this form. The information of usual route comes from the First Data Bank. It is a coded data.

3 Strength: The strength of this filled substance. (See Active Ingredient: Strength above for structural detail)

4 Quantity: The amount being actually filled.

5 ActiveIngredient: Structure containing an active ingredient for this medication and its strength. Used in the filled substance to express exactly what was filled.

6 InactiveIngredient: Structure containing an inactive ingredient for this medication and its strength. It has the same structure as Active Ingredient, only it is labeled for Inactive Ingredients. This is present in the filled substance structure only because inactive ingredients don’t exist until an actual product is chosen.

6 SubstitutionStatus: Whether this order can be substituted by a generic brand or must be dispensed as written. This is used in ambulatory medication orders. This qualifier may be used in acute care if the physician resolves to a particular product because of its inactive ingredients.

7 OrderedDosageContainer: A container created for widget support. Holds various dosage information.

1 Ordered Dosage Container glossary of qualifiers

For data types and structures not specifically referenced, see the actual models and CDL reference guide:

1 SpecialDoseLowerLimit: This is the user-entered dose of this order item when it is based on patient parameters; e.g., either weight or body surface area. The dose in this field will be used to then calculate the OrderedDose fields. There is an associated SpecialDoseUpperLimit to accommodate a scale or dosage range. Most medication orders have just one ordered dose. In these cases, ONLY the SpecialDoseLowerLimit is filled in.

2 SpecialDoseUpperLimit: See SpecialDoseLowerLimit.

3 OrderedDoseLowerLimit: This is the user-entered dose of this order item. It can be in terms of strength, physical dispensing forms, or unrelated to either. Example: if the orderable item is Motrin, the ordered dose could be 400 mg or 1 tab. Second example: Garamycin 0.3% Opthal Solution. There is an associated OrderedDoseUpperLimit to accommodate a scale or dosage range. Most medication orders have just one ordered dose. In these cases, ONLY the OrderedDoseLowerLimit is filled in.

4 OrderedDoseUpperLimit: See OrderedDoseLowerLimit.

5 MaximumCumulativeDose: This qualifier fills the need of a maximum daily or total dose to represent things such as, Maximum of 10 mg/day or Maximum of 10 mg (total implied). This is different than ordered dose upper limit because ordered dose upper limit describes the maximum that can be given in a single dose; this describes a total maximum either within a certain time period or through the duration of the order. The units in this model can specify the increment.

6 MaxDailyDose: This qualifier fills the need of a maximum daily dose to represent things such as, Maximum of 10 mg/day. This is different than ordered dose upper limit because ordered dose upper limit describes the maximum that can be given in a single dose; this describes a total maximum within a 24 hour period.

Semantic Links

1 Order Container Relation Link:

A link which associates an Order Container with one or many of its children. Used to link corollary orders to their parent.

2 Order Container Derivative Link:

A link which associates an Order Container with one or many of its children. Used to link orders that are created via renew or modifying another order. Method to link the orders through time.

3 Order Justification Link:

A link which associates an Order Container with one or many health issues existing in the patient record. The model allows justification to occur to a health issue without it being a formal item in the patient record, hence the qualifier in the Order Container object with a similar name.

Explanation of Expression/Condition structures

Expression and condition structures when present in a statement or component will both be present together. The condition structure will contain the information about a rule or rules governing the statement, and the expression can then be used to chain the rules together using the expression term id in logical phrases such as “this OR that”, “this AND that”, etc. The condition structure, besides containing the expression term id has coded data that states the rule. The rule can be further qualified by a Condition Variable usually used with an operator, such that the triple “RULE operator VARIABLE” is formed. In real terms this would be FIO2 (RULE) < (operator) 89(Variable) where the expression term id would be set to A. The expression structure would be empty at this point unless I added another rule O2 (RULE) < (operator) 5 l/m (Variable) where the expression term id would be set to B. I could then create a text string that contains the expression term ids and their relationship together: “A AND B”.

Instantiation Examples (See OrderModelDiagrams.vsd for better quality of diagrams)

1 Example One

2 Example Two

[pic]

1 Results in Four Orders:

1 Order One

[pic]

2 Order Two

[pic]

3 Order Three

[pic]

4 Order Four

[pic]

Order Container Raw Model

partial model OrderContainer is statement {

  key domain(OrderContainer_KEY_VALUESET_ECID);

  item Order order card(1-M);

  qualifier OrderName orderName card(0..1);

  qualifier OrderRelationship orderablesRelationship card(1);

  qualifier ExternalOrderNumber externalOrderNumber card(0-M);

  qualifier OriginationMode originationMode card(1);

  qualifier OrderStatus orderStatus card(0..1);

  qualifier ProcessType processType card(0..1);

  qualifier StartCondition startCondition card(0..1);

  qualifier HoldCondition holdCondition card(0..1);

  qualifier StopCondition stopCondition card(0..1);

  qualifier CollectionPriority collectionPriority card(0..1);

  qualifier OrderJustification orderJustification card(0-M);

  qualifier OrderedForProtocol orderedForProtocol card(0..1);

  qualifier ReportResultsTo reportResultsTo card(0-M);

  qualifier RequestedFindings requestedFindings card(0-M);

  qualifier ReadingRequest readingRequest card(0-1);

  qualifier EditFormId editFormId card(1);

  qualifier OrderSetId orderSetId card(0..1);

  qualifier LabelInstruction labelInstruction card(0-M);

  qualifier ProviderInstruction providerInstruction card(0-M);

  qualifier SpecialHandling specialHandling card(0-M);

  qualifier AdministrationInstruction administrationInstruction card(0-M);

  qualifier OrderComment orderComment card(0-M);

  qualifier SessionId sessionId card(0..1);

  qualifier OrderCalculationData orderCalculationData card(0..M);

  qualifier PerformingLocation performingLocation card(0..1);

  qualifier PerformingDateTime performingDateTime card(0..1);

  qualifier SchedulingNote schedulingNote card(0..1);

  attribution Discontinued discontinued card(0..1);

  attribution CounterSigned counterSigned card(0-M);

  attribution Ordered ordered card(1);

  attribution PutOnHold putOnHold card(0-M);

  attribution TakeOffHold takeOffHold card(0-M);

  constraint discontinued.providerLocation.card (0);

  constraint counterSigned.providerLocation.card (0);

  constraint putOnHold.providerLocation.card (0);

  constraint takeOffHold.providerLocation.card (0);

  constraint ordered.providerLocation.card (0);

}

Order Raw Model

model Order is component {

  key code(Order_KEY_ECID);

  item OrderItem orderItem card(1-M);

  qualifier DirectionsForRangeDosing directionsForRangeDosing card(0-1);

  qualifier ActionVerb actionVerb card(0-1);

  qualifier SigText sigText card(0..1);

  qualifier OrderSpecialRequirement orderSpecialRequirement card(0-M);

  qualifier OrderPriority orderPriority card(0..1);

  qualifier RouteMethodDevice routeMethodDevice card(0..1);

  qualifier TotalVolume totalVolume card(0..1);

  qualifier RateContainer rateContainer card(0..1);

  qualifier Frequency frequency card(0..1);

  qualifier PRNInd prnInd card(0..1);

  qualifier AdministrationPeriod administrationPeriod card(0..1);

  qualifier StartCondition startCondition card(0..1);

  qualifier StopCondition stopCondition card(0..1);

  qualifier DispenseQuantity dispenseQuantity card(0..1);

  qualifier Refills refills card(0..1);

  qualifier SpecimenDescription specimenDescription card(0..1);

  qualifier CollectionMethod collectionMethod card(0..1);

  qualifier TransportMode transportMode card(0..1);

  qualifier WhoCollects whoCollects card(0..1);

  qualifier BodyLocation bodyLocation card(0..1);

  qualifier Device device card(0..1);

  qualifier ExpressionTermId expressionTermId card(0..1);

}

Order Item Raw Model

model OrderItem is component {

  key code(OrderItem_KEY_ECID);

  data CD code.card(0..1) code.domain(OrderItem_VALUESET_ECID);

  qualifier Formulation formulation card(0..1);

  qualifier OrderedDosageContainer orderedDosageContainer card(0..1);

  qualifier IvComponentType ivComponentType card(0..1);

  qualifier ActiveIngredient activeIngredient card(0-M);

  qualifier FilledSubstance filledSubstance card(0-M);

  qualifier SubstitutionStatus substitutionStatus card(0..1);

}

Order Subtype Raw Model

model OrderMedAmb restricts OrderContainer {

  key code(OrderMedAmb_KEY_ECID);

  constraint collectionPriority.card (0);

  constraint readingRequest.card (0);

  constraint order.orderPriority.card (0);

  constraint order.totalVolume.card (0);

  constraint order.administrationPeriod.card (0);

  constraint order.specimenDescription.card (0);

  constraint order.collectionMethod.card (0);

  constraint order.transportMode.card (0);

  constraint order.whoCollects.card (0);

  constraint order.bodyLocation.card (0);

  constraint order.device.card (0);

  constraint order.rateContainer.card (0);

  constraint order.orderItem.ivComponentType.card (0);

  constraint order.routeMethodDevice.card (1);

  constraint order.routeMethodDevice.CD.card (1);

  constraint order.orderPriority.priorityRequirement.card (0);

  constraint order.routeMethodDevice.CD.code.domain (MedicationRoute_VALUESET_ECID);

  constraint order.routeMethodDevice.CD.code.card (1);

  constraint order.orderItem.CD.code.domain (OrderableMedication_VALUESET_ECID);

  constraint orderJustification.altOne.code.domain (MedicationJustification_VALUESET_ECID);

}

Technical Risks

Other Design Considerations

Module Orders

Revision History

|Revision Version |Date |Reason For Change |Author |

|1.0 |July 20, 2011 |Draft version |Clint Lingwall |

| | | | |

-----------------------

[1] Clinical Element Models created for the Intermountain Healthcare/GE Healthcare partnership are GE copyright material, licensed to Intermountain to share freely and publicly.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download