Patient Care Meeting Minutes 4/99
Total Page：16
File Type：pdf, Size：1020Kb
PATIENT CARE MEETING MINUTES 4/99 Co-chairs: Dan Russler and Charlie Mead Secretary: Heather von Allmen
Attendees:
NAME e-mail tues weds thurs Heather von Allmen [email protected] x x x Dan Russler [email protected] x x x Charlie Mead [email protected] x x x Joyce Spindler [email protected] x David Rowed [email protected] x x x Carmela Couderc [email protected] x x Stewart Haight [email protected] x x x Marvin Lerfald [email protected] x Robin Zimmerman [email protected] x x Gail Rice [email protected] x Hoa Nguyen [email protected] x David Pimmel [email protected] x Jim Case [email protected] x x Mike Ostler [email protected] x Gunther Shadow [email protected] x Tim Brinson [email protected] x Brian Love [email protected] x Ed Hammond [email protected] x Gregg Seppala [email protected] x Andrew Wyszowski [email protected] x Jeff Blackmer Jeff_blackmer/albertawellnet@alb x ertawellnet.org Karen Eckert [email protected] x Carmela Couderc [email protected] x x Rita Barsoum [email protected] x Hetty Khan [email protected] x Barry G. Wilson [email protected] x Mike Lincoln [email protected] x Terri Johnson [email protected] x Irma Jongeneel [email protected] x Greg Thomas x
Meeting was spent covering the following: Education on Pt. Care/Orders Section of RIM Further Definition of Service_event_relationship Class for Harmonization Meeting with Vocabulary to discuss vocabulary domain and message development framework. See Vocabulary minutes for full notes Meeting with Orders to discuss merging of classes - see Orders/Observation Minutes for Notes Started to develop MIM in preparation for Add Goal message Joint meeting with Clinical Decision Support
Education:
Dan Russler provided education on RIM to attendees. Focus was on Service_event and related classes. The full presentation was posted on Patient Care listserver. This education will become a standard part of the first Patient Care session at each meeting.
Development of the MIM for Add Goal Message - Education and Analysis
Application Roles: Sender Receiver Types of roles: Declarative Imperative Interrogative
Conformance is measured by saying what application roles you conform to and what messages you use.
Trigger events are state changes in subject classes. Trigger events are documented in use cases. Use cases are realized in an interaction diagram.
Messages we are looking at: New Problem New Goal
Msg type Roles Declarative Declarer/Recipient Imperative Placer/Filler Interrogative Questioner/Answerer
Subject class: Goal class Trigger event - setting of a goal
Sending application role:
Goal Statuses: Active Cancelled Inactive Suspended Met Not Met
State Transition Diagram - Goals
Update Deactivate (remove date) Set goal Active
Reactivate (insert date) Set new - inactive Inactivate/Suspend
Message Information Model (MIM) - Set Goal:
Use case: Notify receivers of the establishment of a new goal which may be (is?) related to a specific condition, care plan, or other collection of Service_events by a specific clinician at a specific point in time for a specific patient.
Subject class: goal Trigger event: establish new goal Application role sender: Application Role receiver:
Steps in building a MIM: Identify "root class" Identify necessary related classes Check multiplicities (narrow constraints) Identify necessary attributes Check RIM definitions/constraints (narrow constraints)
Necessary Related Classes: Goal is associated w/ assessment (Primary association) Assessment is associated w/ service_event Service_event is related to Svc_reason Service_event is related to Svc_event_relationship (to relate to a condition_node) Service_event is related to Service_intent (is fulfilled by) Service_event is related to Target_participation Target_participation is related to Patient Patient is related to Person Person is related to Stakeholder Service_event is related to Active_participation Active_participation is related to Stakeholder Stakeholder is related to Person Person is related to Individual_healthcare_ practitioner Service_event is related to Master_service (delivers) Service_event is related to Financial_transaction (to bill for a goal) Service_event is related to Patient_billing_account Service_event is related to Encounter (is assigned to) Service_event is related to Clinical_document_header Service_event is related to Master_patient_service_location
Necessary Attributes: Goal:
STILL NEED TO REVIEW THESE
Discussion on Goal Attributes: Can a goal be modified? Lots of discussion related to this. Voted and decided that yes, a goal can be modified. Leave the statement in the definition.
Does a goal have to have an end date? Can it be based on some other event (do X before surgery)? Does it need an expected achievement date at all?
Do we need another attribute to describe an achievement predicate? (i.e., patient should be able to walk 20-30 feet three weeks after surgery). Can't set expected achievement date until surgery date is known. Discussion about whether goal should be a separate class or whether it can be an observation. Observation would need an additional attribute (observation mode?) that gets set to "Goal", and then use observation attributes to represent the goal attributes. Need to evaluate the current goal attributes to see if they are represented in the Observation class. If it looks the data can be represented in Observation, then we will propose the goal class be absorbed into observation.
Goal Attributes: Clinical_Observation: Comment: Classification_cd Delete, unknown why needed Current_review_status_cd Observation_status_cd Comb. use w/ lifecycle_sts_cd Only one sts cd per hierarchy Current_review_status_dttm Delete Expected_achievement_dttm Clinically_relevant_dttm Goal_list_priority_number Goal_value_cd Observation_value Life_cycle_dttm Observation_status_dttm Life_cycle_status_cd Observation_status_cd (in svc_event) Management_discipline_cd Next_review_dttm Would be a Service_intent Previous_review_dttm Would be a Service_event Review_interval_cd
Met with Orders to discuss this. Consensus was that goal and observation were different enough that it did not warrant putting them together. Goal will remain a separate class. See minutes from Order/Observations for further information.
Discussion on assigning priorities and to message the priority (making lists)
What if you have a set of things, and one person assigns authority one way and another person want to assign priorities differently. There is no way to do that in the model today.
Discussion of whether this is just another type of service_event Service event: Establish priority Service event relationship - Linked to service_event - the thing that is being prioritized The service_event Establish Priority (or create list) is associated with the stakeholder that established priority.
It is believed that service_event can support the creation of a list. See notes under Service_event_relationship work for how this was worked out.
Wednesday AM - Joint w/ Vocabulary
Stan Huff presented Message Development Framework. Info and details on this are available in vocabulary chapter. Stan's presentation will be posted with minutes from vocabulary meeting. Patient Care To Dos: Vote on representative Develop priority list for which attributes need domain specifications Develop domain specifications
Vocabulary Facilitator: Voted (5 for, 0 against) and approved Sue Henry as Vocabulary Facilitator for Patient Care
Discussion on templates and how to use them:
Need to describe the relationships between multiple Service_events. Current relationship types defined in the Service_event_relationship class are Battery, Temporal, and Judgment. Is this a place where clinical templates should be used?
Idea of clinical templates is that you model down to a point where you recognize that it no longer makes sense to model an item in the RIM. You want to model the information, but want to model it in a parameterized style. Template use should be employed where you have a developed message (i.e. ORU), and you now want to create some specializations of that message.
Development of clinical templates provides a reality check back to the RIM.
Vocabulary statement - if we can, we should use UML and OCL in the formation of clinical templates.
Version 3 Harmonization Issues:
Combining Allergy Class into Observation - see minutes from Orders/Observations Combining Service_event and Service_intent_or_order - will be worked on by group of volunteers between meetings
New Transportation Class Proposal : During analysis of Service_event and Service_intent_or_order (at January meeting), it was discovered that there were transportation attributes in these classes. The question was raised as to whether they were appropriate there, or whether they should be a separate order/event. In analyzing this, you see there are a number of things that get transported, patients, specimens, etc. The person doing the transporting is the active_participant.
Proposal is that we feel that we need a new transportation class . Patient care would be stewards of this class. We will address the details of this class in a future meeting, after seeing outcome of combining Service_event and Service_intent_or_order Voted on and approved (5 for, 0 against, 2 abstain).
Need to meet with Scheduling/referrals: Need to meet with scheduling to begin to talk about the piece missing from the model to deal with scheduling of service events. Voted to request a joint meeting with Scheduling/referrals (6 for, 0 against).
Service_event_relationship: Service_event_relationship is a "collector" class. There are three kinds of service_relationships: Sets/Lists (problem, battery), Rule based (time dependent and time independent) (care plans, protocols), and Judgments
Service_ event
Service_ Any attributes?: Start date, End Date, Event_ Relationship assignor ID relationship
List_link Conditional Judgment_ _link link Priority Types: identifies Predicate Type supports reason for subsume others?
Time Time dependent independent constraint constraint Cardinalities that are already in model are correct.
Definitions for service_event relationship proposal (please review and comment):
Service_event_relationship: (NOTE: We have a working definition of SER. That definition should (but may not) involve the concept of an instance of SER serving as a link between two instances of SE. (NOTE: we need to make sure that the multiplicities in the RIM reflect this fact, i.e. are of the form "an instance of SE links to 0-to-many instances of SER with each instance of SER in turn linking to one instance of SE). We are now defining SE as an abstract class, as well as defining the three subclasses of SER: List_link, Conditional_link, and Judgment_link. The essential difference between the various subtypes of SER are in the semantics of the links defined by the instances of the SER . Also note that an instance of SER always links exactly two instances of SE, one functioning in the role of source, and one functioning in the role of target.
List_link: The link that exists between two instances of SE which indicates simple set membership. The source SE is the set name, while the target SE is the set member. The attribute priority of the List_link class allows the set to become a list, with the value of the priority attribute specifying list order. Thus, a value of NULL for priority indicates that the source of the List_link is the "name" of the set (e.g. Chem-12) while each target of an instance of List_link will be a "member" of the set (e.g. Na, K, etc.). If an instance of List_link has a non-NULL priority value, an application may choose to display and/or process the list (i.e. the prioritized/order Set) according to application rules for interpreting the priority that a given list member has been assigned (e.g. the Work List for Nursing has the following Work Tasks listed in order of priority: 1. SE1 2. SE2, 3.SE3, etc.
Condition_link: The link that exists between two instances of SE which define a predicate between the result of the source SE and the instantiation of the target SE. Thus, a rule that says "IF the Na has a value of <130, start IV fluids ELSE redraw Na in 24 hours" would be represented as SE(Na) linked to SER (If Na < 130) linked to SE(IV fluids) AND SE(Na) linked to SER(If Na >= 130) linked to SE(Na).
Judgment_link: The link that exists between two instances of SE which define a type of judgment joining the two instances of SE (e.g. "supports," "is reason for," etc.) For example "The diagnosis of Lupus is supported by the previous observations of fever, butterfly rash and increased sed rate." Use case for creating goals, problems, and putting item on list
The use case begins when… …a list_link manager creates a new link for a specific item on …a goal declarer creates a specific list a new Goal for a specific patient Goal receiver List_link manager
Create New Goal <
…the new Goal has been communicated to the goal receiver <
…a problem declarer creates a new Problem for a specific patient Create New Problem Problem_declarer Problem_receiver …the new Problem has been communicated to the problem receiver
The use Case ends where…
State Transition Diagrams for Service_event_relationship
List_link:
Activate Create Active
Deactivate Inactive Remove Strike/Delete Conditional_link:
Fire
Activate Create Active Deactivate
Inactive
Strike/remove
Judgment_link:
Create Active Strike/Remove
List_link - battery/set SE:clinical_observation
Name: CBC
SER: list_link SER: list_link SER: list_link
Priority: null Priority: null Priority: null
SE: Clinical_obsv SE: clinical_obsv SE: clinical_obsv
Name: WBC Name: Hgb Name: Hct List_link (creating list) SE: Service_event
Nursing work list
SER: list_link SER: list_link SER: list_link
Priority: 3 priority: 1 priority: 2
SE: SE: Clin_obsv SE: Rx_treat_svc_event
Turn patient Take vital signs Give medication
Conditional_link
SE: Clinical_obsv
Serum Sodium
SER: conditional_link SER: conditional_link
< 130 >= 130
SE: direct_treatment_event SE: Clinical_obsv
Normal Saline @ Serum Sodium 150cc/hr Judgment_link Problem SE: condition_node
Date/Time
SER: judgment_link
Named by
SE: Clinical_observation
` Diagnosis: SLE
SER: judgment_link SER: Judgment_link SER: judgment_link
Supported by supported by subsumes
SE: Clinical_observation SE: Clinical_obsv SE: Clinical_obsv
Fever 101 Butterfly Rash Belly Pain
HARMONIZATION MEETING IS JUNE 22. ANY COMMENTS MUST BE IN TO DAN AND CHARLIE BY JUNE 10 IN ORDER FOR IT TO BE INCORPORATED PRIOR TO HARMONIZATION Thurs AM - Joint meeting with Clinical Decision Support
Met with Clinical Decision Support. Presented our area of the RIM to them
We extended the invitation to them to participate in the design of any classes we have that they have interest in, particularly Service_event_relationship (the conditional_link type).
If there are kinds of rules that they can't represent with the Conditional_link class, then we would support their adding additional classes.
Will meet jointly with Clinical Decision Support at next meeting (proposing to meet Friday morning)
Side discussions needing follow-up in future meetings - 1. What is gained by having class Assessment between Service_event and Goal_set. Is it an artificial class? It has no attributes. Should it be removed? Need to discuss w/ orders 2. Does a goal HAVE to be related to either a Svc_event or Svc_intent? Can it stand on it's own? Trying to decide if there needs to be a mandatory relationship/attributes when setting the goal. 3. Some discussion regarding outcomes and where this is represented in the model. 4. Orders/observations and Patient_care are pretty well under control with the exception of the scheduling piece. We need to get this piece together. Can re-pursue with them, or we can come up with a proposal and take it to them. The group of interest is Scheduling/referrals (was Inter-Enterprise group). 5. Use cases need to be written and application roles need to be defined for the messages that we need to define.