Scope: What include and exclude in 3



April 2002 Minutes

Orders/Observations Worksession

Table of Contents

Attendees 2

General 4

Version 2.x Review 4

Chapter 4 Ballot Review 5

Chapter 7 Ballot Review 33

Chapter 8 Ballot Review 50

Chapter 11 Ballot Review 53

Proposal One: SPM/SAC Structure 55

Proposal Two: CQ 55

Proposal Three: CDA 57

Proposal Four: LAPOCT 58

Version 3 Review 59

Introduction 59

Background 60

Scenario for Laboratory comments provide by Patrick Mitchell-Jones: 64

Ballot Review 66

Action Items 149

Attendees

|Attend|Company/E-Mail |Mon |Mon |Tue AM |Tue PM |Wed AM |Wed PM |Thu AM |Thu PM |

|ee | |AM |PM | | | | | | |

|JM |8.8.2, 8.8.3, |8 |N |Mi |{ [MFA] } |[ {MFA} ] |format for optional and repeating is incorrect |  |  |

| |8.8.4, 8.8.5, | | | | | | | | |

| |8.8.6, 8.8.7, | | | | | | | | |

| |8.10.1, 8.11.1, | | | | | | | | |

| |8.12.1 | | | | | | | | |

|JM |8.8.2, 8.8.3, |8 |A |T |Master file ACK segment |Master File ACK segment |Capitalize F in File for consistency with other |  |  |

| |8.8.4, 8.8.5, | | | | | |fields | | |

| |8.8.6, 8.8.7 | | | | | | | | |

|JL |8.8.8.25 |8 |  |S |For tests that require a specimen, this field may |  |A technical correction needs to be applied to the |  |  |

| | | | | |contain two components in the format ^. | |data type ID. The statement allowing 2 components | | |

| | | | | | | |should be struck. Perhaps a new field Specimen | | |

| | | | | | | |Priority should be added, but it is not clear how | | |

| | | | | | | |this information would be transmitted in a request.| | |

|AK |8.8.8.25, |8 |N |Mi |  |  |The field note refers to OBR-27, Quantity/Timing, |  |  |

| |8.8.11.13 | | | | | |but should now point to TQ1 - 9 Priority. | | |

|PS |8.8.8.30 |8 |N |Mj |OM1-30 Confidentiality Code (IS) 00615 |OM1-30 Confidentiality Code (IS) 00615 |Item 615 used in ORC-28 Chapter 4.5.1.28 with DT |  |  |

| | | | | | | |CE, harmonization needed | | |

|JL |8.8.9.6 |8 |  |Q |  |  |Should subcomponent desciptions be deleted? Are |  |  |

| | | | | | | |they not adequately defined in the RFR data type? | | |

| | | | | | | |Perhaps some of this narrative needs to be added to| | |

| | | | | | | |the RFR definition. | | |

|JM |8.8.9.7 |8 |N |Mj |Note: This field is not backward compatible from |  |Why is it valid to have one field within a segment |  |  |

| | | | | |V2.5. For versions prior to V2.5, the expected | |not be backward compatiable? What is the | | |

| | | | | |format would utilize the component separator | |recommended way to implement this for a 2.5 system | | |

| | | | | |(|10^20|); however for V2.5 the format will | |communicating to another 2.5 system and 2.4 and | | |

| | | | | |utilize the sub-component separator (|10&20|). | |lower systems? | | |

|PS |8.8.11.7 |8 |N |Mj |HL7 Table 0371 |  |this table differs from Hl7 Table 0371 specified in|  |Point to Chapter 7., N = 0, A = 0 , F = 16 |

| | | | | | | |Chapter 7 Section 7.18.6, there must be some | | |

| | | | | | | |harmonisation | | |

|PS |8.8.11.7 |8 |N |Mj |OM4-7 Additive (CE) 00647 |OM4-7 Additive (CWE) 00647 |Datatype conflicts with usage in Chapter 13 Section|  |Change to CWE. |

| | | | | | | |13.4.3.27 | | |

|JM |8.12.1 |8 |N |Mi |{MFE IIM} |{MFE {IIM} } |Are we trying to convey that MFE and IIM are |  |  |

| | | | | | | |repeatable within M15 or that IIM is repeatable | | |

| | | | | | | |within the MFE construct which is also repeatable? | | |

|AK |8.12.1 |8 |N |Mj |MFN/MFK - Inventory Item Master File Message |MFN/MFK - Service Item Master File Message (Event |Current name conflicts with Inventory Item Master |  |  |

| | | | | |(Event M15) |M15) |messages being proposed by Logistics. | | |

|JM |8.12.2 |8 |N |Mi |  |  |IIM-15 should be listed as repeating (as per the |  |  |

| | | | | | | |definition). | | |

|JM |8.12.2.1 |8 |A |T |The identifying key value. Must match MFE-4 - |. The identifying key value must match MFE-4 - |  |  |  |

| | | | | |Primary Key value - MFE. |Primary Key value. | | | |

|PS |8.12.2.1 |8 |N |Mj |IIM-1 Primary Key Value - IIM (CE) 01798 |IIM-1 Primary Key Value - IIM (CE) 01798 |Item 1798 used as "CON-23 Non-Subject Consenter |  |  |

| | | | | | | |Reason" in chapter 9.9.4.23 Harmonization needed | | |

|JM |8.12.2.4 |8 |A |T |Expiration date does not always have a “day” |  |  |  |  |

| | | | | |component; therefore, such a date may be | | | | |

| | | | | |transmitted as YYYYMM. | | | | |

|JM |8.12.2.9 |8 |A |T |Definition: This field specifies the unit for |Definition: This field specifies the unit for |Code should be Cost for IIM-10 |  |  |

| | | | | |IIM-8 Inventory Received Quantity and IIM-10 |IIM-8 Inventory Received Quantity and IIM-10 | | | |

| | | | | |Inventory Received Item Code. |Inventory Received Item Cost. | | | |

|JM |8.12.2.9 |8 |A |T |Inventory Received Quantity unit |Inventory Received Quantity Unit |"u" in unit should be capitalized |  |  |

|JM |8.12.2.13 |8 |A |T | Inventory on hand quantity unit |Inventory on Hand Quantity Unit |capitalization needed |  |  |

|JM |8.12.2.13 |8 |N |Mi |  |Definition: This field specifies the unit for |Definition for IIM-13 is missing |  |  |

| | | | | | |IIM-12 Inventory on Hand Quantity. | | | |

|PS |8.12.2.15 |8 |N |Mj |IIM-15 Procedure Code Modifier (CE) 01812 |IIM-15 Procedure Code Modifier (CE) 01316 |Item No. 1802 allready used in ERR-2 Error Location|  |  |

| | | | | | | |in chapter 2.15.5.2 -use Item No. 1316 instead | | |

| | | | | | | |(OBR-45 Procedure code modifier). Harmonizatio n | | |

| | | | | | | |needed | | |

|FO |8 + 9 |  |N |Mj |  |  |01798: IIM-1 and CON-23 use same data element ID! |  |  |

|FO |8 + 2 |  |N |Mj |  |  |01812: ERR-2 and IIM-15 use the same data element |  |  |

| | | | | | | |ID | | |

Chapter 11 Ballot Review

We were not able to address any Chapter 11 ballot items during the worksession.

Name General Comment

JM - Joan Miller

FO - Frank Oemig

RH - Richard Harding

JL - Joann Larson

AK - Austin Kreisler

|ID # |Section |Ch. |Vte |Type |Existing |Proposed |Comments |

| | | | | |Wording |Wording | |

| | | | | | | | |

|11 |205 |RFR |O |Y | |Nnnn |Critical Reference Range for Ordinal and Continuous |

| | | | | | | |Observations |

| | | | | | | | |

8.8.4.78.8.9.7 OM2-7 Critical Range for Ordinal and Continuous Observations (CMRFRNR) 00632

Components: ^

Definition: Retained for backward compatibility, in version 2.5 and later refer to field OM2-11 Critical Reference Range for Ordinal and Continuous Observations.

This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18 - Nature of Service/Test/Observation) with numeric results. When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6 - Reference (Normal) Range - Ordinal and Continuous Observations).

Note: Since, in versions prior to version 2.5, the data types of OM2-6 and OM2-7 are different and preclude implementations from adhering to the last sentence of the definition: “… should be recorded here in the same format as the normal range ….” This resulted the deprecation of this field in favor of OM2-11 in version 2.5.

Note: This field is not backward compatible from V2.5. For versions prior to V2.5, the expected format would utilize the component separator (|10^20|); however for V2.5 the format will utilize the sub-component separator (|10&20|).

8.8.9.11 OM2-11 Critical Reference Range for Ordinal and Continuous Observations (RFR) nnnnn

Definition: This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18 - Nature of Service/Test/Observation) with numeric results. When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6 - Reference (Normal) Range - Ordinal and Continuous Observations).

Starting with version 2.5, this field replaces OM2-7 and employs the Reference Range (RFR) data type in order to support the same capabilities of OM2-6 - Reference (Normal) Range - Ordinal and Continuous Observations

Make sure that the item number is brand new!

We accepted the proposal with 16 in Favor, 0 Abstain, and 0 Against.

Proposal Three: CDA

7.2 PURPOSE

If the observation being reported meets one or more of the following criteria, then the content would qualify as a medical document management message (MDM) rather than an observation message (ORU). The reader is referred to the MDM message type in Chapter 9.

• Documents/reports where the whole requires a signature or authentication as part of the message.

• Documents/reports that require succession management to reflect the evolution of both document addenda and replacement documents. Succession management is described in Chapter 9.

• Documents/reports where the Sender wants to indicate the availability of the report for use in patient care using the availability status present in the TXA segment, as described in Chapter 9.

Additional considerations that may affect the appropriateness of using an MDM message:

• Documents/reports where the whole requires a signature as part of the message. While the ORU message does not support the inclusion of signature or authentication, some document content forms support these requirements. Of particular note, CDA documents provide for the inclusion of originator/signature. Thus, if a CDA document requires a signature but does not require succession management or report availability (as described above), then an ORU message may be appropriate. However, if the CDA document requires succession management or report availability, then an MDM message is required.

• Documents/reports where the whole requires authentication as part of the message. As described for signatures, authentication may exist within the document content form. Again, CDA documents provide for the identification of an authenticator. Thus if a CDA document does not require succession management or report availability, then an ORU message may be appropriate. If succession management or report availability are necessary, then an MDM message is required.

• Documents/reports where the content as a whole requires special confidentiality protection using the confidentiality status present in the TXA segment, as described in Chapter 9.

• Documents/reports where document storage status is useful for archival and purging purposes using the storage status present in the TXA segment, as described in Chapter 9.

Using these criteria, the following examples of documents/reports would typically qualify as medical document management (MDM) messages. Note that as clinical content, the following documents/reports typically require succession management and/or report availability and thus would require an MDM message even if the payload utilizes CDA.

• History and Physical

• Consultation reports

• Discharge summaries

• Surgical/anatomic pathology reports

• Diagnostic imaging reports

• Cardio-diagnostic reports

• Operative reports

• As an international example, microbiology reports may include clinical interpretation and require authentication. This may not be the case in all jurisdictions, but is an example that the use or requirement of MDM messages may be influenced by local considerations.

7.2.2.5 Clinical Document Architecture (CDA):

The Health Level 7 specification for encoding and encapsulating clinical documents. (actual text reference will be supplied)

Proposal Four: LAPOCT

Chapter 13 ballot feedback was reviewed by LAPOCT SIG. We agreed to endorse their efforts with 14 in Favor, 0 Against, and 0 Abstain.

Version 3 Review

We reviewed V3 ballot feedback on Tuesday, Wednesday, and Thursday with Medication Information SIG and LAPOCT SIG.

Introduction

We started our discussions with a review of how to make the V3 ballot ‘passable’. There is a June/July target for next Committee level ballot.

Various key questions had been raised through the ballot process specific to OO and in general:

• What are we trying to achieve?

• What are the core issues?

• How much does the number of Application Roles matter?

• Does loosely/tightly coupled matter?

• How do the layers of understanding get built around the RIM down to the actual messaging?

Some of these are being addressed in MnM context to get a consistent approach across all areas, e.g., application roles and coupling.

We reviewed whether to use the following three objectives as we evaluate ballot responses with this diagram:

[pic]

1. We need to reduce ambiguity of structural choices. There should be only one way to send a particular message. Need to clarify optionality; any variations should be clearly defined as to why they exist and when they are used.

2. We need to increase the understanding of the process of message communication and how the various artifacts taken from the RIM work together. Need to comfortable with the base patterns and the definitions that go with them.

3. Application roles vary; there is always going to have question of how much data to send in any situation. There is discussion of whether “how much data to be sent” in any particular message, especially in given examples, should be part of the normative ballot for the standard.

The following priorities/categories were derived from these objectives to organize ballot feedback:

1. Reduce ambiguity of structural choices; increase consistency

2. Create layers of understanding

3. Clarify optionality and pre-requisites on including structures

Can then feed this clearly back to MnM.

There was group discussion of this, and general agreement of how to take this forward. There was definite agreement of need to increase understanding of the message development process from the RIM, documentation of decisions and definitions.

We need to focus on simple repeatable patterns. Objective is to provide messages that support real world business practices (i.e. care of patients!).

We agreed to go through the Health and Clinical Management section ballot comments that relate to O&O (lab and pharmacy), to assign one of the three priorities/categories described above first, and then to facilitate the resolution process starting with those marked a priority/category of 1, then 2, and finally 3.

Background

We reviewed an explanation of the following Artifacts in the Message Development Process of HL7 Version 3 on Tuesday:

Messages

A Message contains information about subject classes. An Act is a subject class, and an order is an act. Acts can go through state changes.

In the laboratory domain, the ‘order’ or ‘observation’ is the core act and is the focal class. This decision to have the act rather than the patient as the focal class of the message was taken because it is the order that changes state through its lifecycle, but the patient does not, and the message is really about the order rather than the patient that the order is for. All patient information is contained within the Patient CMET.

Trigger Events (TE)

These follow the Business Processes of the domain area. A Trigger Event causes an Interaction.

A Trigger Event is associated with a state change of the focal class of a message; for example in the “Activate an Order” message, the “order” is the focal class, and any change of state of that order would require a Trigger Event.

Interactions (IN)

These have Application Roles (a sender and a receiver), a single Trigger Event, a single Message Type and a Receiver Responsibility (optional). Each interaction is associated with an HMD.

Application Roles (AR)

These will go in pairs, with a description of the role of the sending application, and a description of the role of the receiving application.

Message Types (MT)

This defines the information content of the particular message.

Hierarchical Message Description

This is a walk through of an R-MIM; when there is more than one path through a particular R-MIM, there will be a number of HMDs related to a particular R-MIM.

Refined Message Information Model - R-MIM

This is a cut down version of the D-MIM. There are more constraints and cloned classes than in the D-MIM. It has a single entry point, which is where to start to make a message.

One R-MIM may be used for a number of similar pattern messages. There has to at least one RMIM for each HMD; but more than one HMD can relate to a single RMIM.

Domain Message Information Model - D-MIM

Each domain has its own D-MIM. The D-MIM contains a representation of everything to be used in the messages used within the domain. It contains cloned classes (classes with additional constraints) from the main RIM.

V3 Ballot Evaluation

To evaluate whether the V3 Ballot addresses the messaging needs of the practice of healthcare (business processes) within a particular domain, the process should be to evaluate:

The use cases and storyboards – are all the scenarios covered?

What trigger events exist in the domain, and how do these relate to the state transitions?

What interactions exist, and are these appropriate for the business processes?

What message types exist, and do these contain the correct information?

The R-MIM and D-MIM are part of the structural/development process, providing the foundation for the message artefacts and their relationships together. They do not have to be completely analysed in order to evaluate whether the ballot package contains the necessary messages to support the business processes of the domain.

[pic]

Infrastructure Controlled Event Wrapper HMD and Lab D-MIM (MW)

Issue: There is a risk of overlap/confusion between these two.

Discussion: (GS) Aim is to try to disambiguate the participants in the Controlled Event Wrapper. For example: In a “Cancel Order” transaction there is a need to distinguish all the different participants – the person who made the order, the person who cancelled it etc.

Resolution: Need to add documentation to explain the difference between the participations in Act Relationships on the focal class (the order/intent/event – where to start the walk of the HMD) versus those of the control event.

Sensitivity Panel Results Communication (VL)

The need to update the storyboards for Microbiology is accepted.

“Grouping” of Observations into Profiles eg “Full Blood Count”(DH)

The structure can do this, as discussed in recent MnM meetings.

The next ballot must show examples and normative text to explain this. (Vote: 13 in Favor, 0 Against,and 1 Abstain)

There is a recursive relationship managed by Act Relationship_Component:

[pic]

[pic]

It is now clear (from the MnM discussions) that there is the ability to apply restrictions at different points within the Act Relationship_Component recursion using profiles.

There was discussion of the various identifiers for the individual events and their relationships to each other at each level. The “cd* 1:1” means that an identifier is required to be sent if it exists, but it is not mandatory.

Representation of “headings” and Contextual Inferences that can safely be derived from them? (DH)

Deferred, but discussion of comments followed.

Are headings “Comments”?

Have established how to do ‘batteries’; how can one put a ‘heading’ on that battery?

Can put text (txt attribute) from the responsible person into the observation event.

Is it possible to have a comment without identifying the commenter? If so, does it go in the “txt attribute” - yes.

What determines the reasons to use one particular structure over another? (For example Responsible Party txt versus txt attribute in observation event)

Need to add “Comments” to the O&O issues list and have some storyboards/use cases to support these. Patrick Mitchell-Jones will provide storyboard for this.

Structures are needed to unambiguously describe microbiology information, particularly the unwrapping of recursion.

Appropriateness of A_Observation_event name-value pair construct eg the Microbiology and General Medical domains (DH)

Hepatitis B - is this a test or a medical condition?

Vocabularies usually have some context information – diagnosis codes are different from test codes.

It is an appropriate construct, so will resolve this by giving examples of name-value pair constructs to show how the vocabulary codes should be used in the message (Karen will do this).

(vote: 14 in Favor, 0 Against, and 1 Abstain)

Specific State-Transition Diagrams for Each Business Object (DH)

Business object (focal class) of O&O is an order, intent or supply; these do have their own specific state transition diagram based on the Act State Transition Diagram.

It would be very helpful to describe more clearly the states in relation to orders, intents and supply. This could be done in the Introductory Section, with storyboards.

Description of Acknowledgement Modes (DH)

O&O V3 work for Receiver Responsibilities only describes the ORR type of acknowledgement. The Message Wrapper from Infrastructure Management dictates the simple ACK type.

Receiver Responsibility Review:

O&O need to review whether any specific Receiver Responsibilities have been missed (Sara). Also need to make sure that all appropriate Receiver Responsibilities are documented. Need to investigate how to indicate that no receiver responsibilities are required in a particular scenario. (Austin)

“Nullify” Trigger Event (DH)

This is essentially the same as the issue with state transitions – making the definitions clear and having examples.

Should never ‘lose’ the record of a nullified event, and cannot dictate what an application does with a nullify message.

Scenario for Laboratory comments provide by Patrick Mitchell-Jones:

Dr Door collects two specimens of blood from Mr Smith who has just been admitted to the observation ward complaining of abdominal pains. For one specimen he places an order with the laboratory for a Urea & Electrolytes, Amylase and Liver Function tests and asks to be telephoned with the results. For the second specimen places an order for protein electrophoresis. He labels the samples with the sample labels generated by the system. The order is transmitted to the laboratory and Dr Door leaves the samples on the ward to be collected by the porter and transferred to the laboratory. Unfortunately, he places them in the incorrect place.

Harry, the porter arrives on the ward on his scheduled round and picks up samples from the collection point, failing to pick up Mr Smith’s sample. He continues on his round and picks up samples from other wards and returns to the laboratory.

The laboratory accept the samples into the laboratory system using the ordering system sample number to retrieve the order details and applies a laboratory number to each (filler number).

Dr Door has had a number of emergency cases since he collected the sample and has not been telephoned with the results on Mr Smith by the time that he gets to the end of his shift. He checks on the patient, who is comfortable and not complaining of pain any more. Dr Door rings the lab to see why he hasn’t been telephoned with the results. They tell him the sample was not received. He checks the hospital system and sees that the order is still on the system but not acknowledged by the lab. He looks for the sample and finds it where he left it. He rings the porter and arranges for pick-up.

The porter picks up the sample and transports it to the laboratory.

On receipt of the sample by the laboratory, the technician notes that the samples were collected 6 hours ago and makes a comment against them ‘Sample received 6 hours after collection’.

The U&E, AMY and LFT sample is analysed, the results validated (for technical correctness) and subjected to the LIS authorisation (clinical approval) rules. These rules check for specific conditions such as reference range or delta check failure, and will hold up observations or observation batteries that meet defined criteria for manual approval. The Protein Electrophoresis is stored for the next run of electrophoresis testing. The laboratory has recently changed the analyser that carries out the LFT tests and has added a comment to the battery definition to be included on reports that advises the recipient of this. Because the Potassium is raised and the Amylase outside the normal range, all the results are held up for approval by a clinically qualified person. Only when this approval is complete can the results be made available to Dr Door. The Clinical Chemist, Sylvia Moore, checks the list of results waiting for clinical approval and reviews the results for Mr Smith. She adds a comment to the Potassium result to indicate that the potassium is raised but this may be due to the age of the sample.

On looking at the overall U&E results, she notes that the combination of the results suggests that the patient may be dehydrated and puts a comment against the battery.

The overall results of the analyses suggest pancreatitis and she adds a clinical comment that applies to all the results being released to Dr Door at that time, i.e. the U&E and LFT batteries and AMY result.

The protein results will be released later with any appropriate clinical comments that may be added.

The relationships of the comments made are:

1. Sample has a comment regarding the lateness of delivery which should be reported with all observations carried out on that sample.

2. The observation battery (LFT) has a note identifying a change of method

3. The observation battery U&E has a clinical comment indicating dehydration

4. The observation potassium (part of the U&E battery) has an observation-specific comment

5. The U&E and LFT batteries and AMY result have a clinical comment (diagnosis?) which applies to all the observations being approved at that time.

1 is satisfied by the O_SpecimenCharacteristics (Obs)

2 is satisfied by the A_Observation_event (Txt)

3 is satisfied by the A_Observation_event (Txt)

4 is satisfied by the A_Observation_event (Txt)

5 I haven’t a clue how this is handled.

Ballot Review

We were only able to address those ballot items with notes in the Disposition Comment column.

Name General Comment

DN - Dale Nelson

GD - Gary Dickinson

JM - Joan Miller

HF - Heath Frankel

MW - Mead Walker

BD - Bob Dolin

SB - Sandy Boyer

SR - Scott Robertson

VL - Virginia Lorenzi

BK - Bert Kabbes

NA - Nick Apperley

DH - Dick Harding

|  |ID # |Artifact |

|1 |How to handle comments and annotations. |Patrick Mitchell-Jones |

|2 |How to structure micro. | |

|3 |Use case for different types of name value pairs for Observations |Karen Sieber |

|4 |Need to add additional descriptions on how the state transitions apply specifically to OO. Must be tied to |Dick Harding, Austin, Gunther, Lloyd |

| |general introduction to trigger events. | |

|5 |Need to review Receiver responsibilites, to see if we missed any. |Sara Korpak |

|6 |Need to review receiver responsibilites to make sure we included all appropriate responsibilities. | |

|7 |Need to investigate how to indicate no reciever responsibilities. |Austin |

|8 |Convince Gunther of separating OCCUR vs. COMP |Austin |

|9 |Create improved description of the Replace state transition scenario |Austin |

|10 |Incorporate the principle as appropriate into the application role/hierarchy discussion |Lloyd |

|11 |Move proposal to MnM |Lloyd, Austin |

|12 |Review RIM for current terminology (replace outdated USAM terminology, e.g., service object) |Gunther, Austin |

|13 |Re-synchronize ladder diagrams with interaction model. |Lloyd, Austin |

|14 |Check with Dan Jernigan about the need for a lab intent. |Hans |

|15 |Check on fix for nullification and reactivation as well as superfuously generated wording |Lloyd, Virginia |

|16 |Submit certainty_cd to Harmonization to be added to Act |Gunther, David Markwell |

|17 |Address old approach for grouping container in Rx with new containment approach |Lloyd, Julie |

|18 |Documentation of constraints on attributes based on status codes in the RIM |Gunther, Harmonization |

|19 |Fix the machinery on how CMETs are incorporated into HMDs. |Lloyd, Dale |

|20 |Check on COMP/PERT decision |Lloyd, Gunther, Austin |

|21 |Create proposal and review with MnM/Conformance how it can be done legally |Gunther |

|22 |Review additional trigger events/interactions needs for Rx |Lloyd, Scott |

|23 |Resolve the discrepancy and come up with one construct except for cardinality |Gunther, Lloyd, Austin |

|24 |Lloyd needs to determine if the supply event R-MIM needs an id attribute. |Lloyd |

|25 |The Meds Management Sig needs to review these items |Lloyd, Scott |

|26 |Tighten up the description of the A_Observation CMET (and derrived CMET's) and change the names to |Austin |

| |Supporting_info, and create a D-MIM. | |

|27 |Synchronize the Rx/Lab approach on how to deal with A_Observation_supporting CMET, and b eef up the |Austin, Lloyd. |

| |description of how it's used vs. the same CMET in R_Patient. | |

|28 |Update Act_Status_Control_Payload D-MIM to constrain id and cd such that they cannot be changed. |Austin |

|29 |Confirm no other status codes should be included. Determine the cardinality is correct (if so, clarify with |Gunther, Austin |

| |use case the absence of a status code) | |

|30 |Forward to Publishing thoughts on improved readability and navigation. |Hans |

|31 |Clarify whether Preliminary disappeared or needs to be better documented and approach to supplementary. |Gunther, Austin, Wayne, Bob Dolin |

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

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

Google Online Preview   Download