Example model 1 for new dynamic model

Introduction

This is an extremely simple case to get us going. It revolves around the notion of a patient being admitted to a hospital.

See here for the mapping from this example to CDL .... Example_model_1_for_new_dynamic_model_cdl

Explanation

The patient admission service is very simple - it's a straight forward pub-sub. The patient service performs the actions internally, to rules of it's own that are out of scope of this model. This model concerns the information and interactions that occur when the patient service informs other interested parties about what has happened.

Usually there are many such interested parties - at least in the tens of systems at normal hospitals. The normal set up between the systems is that the patient service drops the pub onto some relay service that then passes the notification onto multiple other systems. The other systems are not able to reject the notification - or at least, it doesn't matter if they do; the action has happened, and it's up to the other systems to accept that it has. Errors are usually referred to some tracker system that passes them onto a human for manual reconciliation.

The relay and error tracking aspects of this are generally held to be out of scope of the explicit model - they are taken as given, since there is such an extreme variety in how they are implemented.

In order to anchor the declared events in reality, the description of the system starts with a declaration of the state & transitions of the "admission" which is regarded as the "focal class" of the dynamic mode.

State Model

There is a simple state diagram:

The grayed out parts are the parts of the general state model that are not relevent for this case and can be ignored.

Text summary: an inpatient admission can either be active, completed, aborted, or nullified. Planned inpatient admissions are considered active. Although other state transitions could be imagined - even between the valid states - the committee has decided that they are not beneficial to model.

Trigger Events

The following trigger events are defined:

Code	Name	Meaning	Candidate State Transition
PRPA_TE412001UV02	Inpatient Encounter Appointment Scheduled	an inpatient admission was scheduled	EncounterAppointment-activate
PRPA_TE412002UV02	Inpatient Encounter Appointment Revised	a scheduled inpatient admission was modified prior to the admission	EncounterAppointment-revise (active only)
PRPA_TE402001UV02	Inpatient Encounter Started	a patient was admitted to an inpatient encounter. If there was an appointment for this encounter then this trigger event also implicitly changes the status of the appointment to completed	EncounterAppointment-complete EncounterEvent-activate
PRPA_TE402008UV02	Link Encounters for Mother and Baby	the sending system has linked the inpatient encounter for a baby to the inpatient encounter for the baby's mother.	ActRelationship w/update mode Added
PRPA_TE402009UV02	Unlink Encounters for Mother and Baby	the sending system has removed the baby to mother link between two inpatient encounters.	ActRelationship w/update mode Deleted
PRPA_TE402010UV02	Link Encounters for Recipient and Donor	the sending system has linked the inpatient encounter for an organ donor to the inpatient encounter for the organ recipient	ActRelationship w/update mode Added
PRPA_TE402011UV02	Unlink Encounters for Recipient and Donor	sending system has removed the organ donor to recipient link between two inpatient encounters	ActRelationship w/update mode Deleted
PRPA_TE402012UV02	Pending Inpatient Discharge	signals of a plan to discharge an inpatient when the patient has not yet left the healthcare facility.	EncounterEvent-revise (info in TE)
PRPA_TE402013UV02	Pending Inpatient Discharge Canceled	signals that a planned inpatient discharge was canceled	EncounterEvent-revise (info in TE)
PRPA_TE402002UV02	Inpatient Encounter Revised	signals that information about an inpatient encounter has changed	EncounterEvent-revise (active or complete)
PRPA_TE402004UV02	Inpatient Encounter Aborted	signals that an inpatient encounter was aborted prior to a normal discharge. Either the practitioner or the patient ended the encounter prematurely.	EncounterEvent-abort
PRPA_TE402003UV02	Inpatient Discharge	an inpatient was discharged	EncounterEvent-complete
PRPA_TE402007UV02	Inpatient Discharge Canceled	signals that a previously-reported inpatient discharge was canceled before the patient was released from the hospital. This trigger event could be either the result of an erroneously-reported inpatient discharge or because a decision was made not to discharge the patient after all.	EncounterEvent-reactivate
PRPA_TE402999UV02	Inpatient Encounter Nullified	signals that a previously-reported inpatient admission notification was sent in error and has been nullified	EncounterEvent-nullify

This raises a number of questions for me:

• why is there no trigger events for abort, reactivate, complete from null?
• [response] There are, see above
• why is there so many trigger events for revise? This suggests that something is fundamentally broken to me
• [response] trigger events describe business events that do not change the state of the focal encounter. Linking/unlinking two encounters does not change their state. A pending discharge notification does not change the state of the active encounter. Etc.
• do donor/recipient encounters need to be inpatient encounters?
• [response] The use cases given to PA had both encounters as inpatient. Obviously, the A_Encounter CMET is not actually constrained to inpatient except in the description.
• should the state machine allow for these transitions that are potentially changes in state machines at once?
• [response] Not clear what you are asking. See Inpatient Encounter Started where state transitions are asserted on two classes.
• the formal name for Inpatient Discharge Canceled says reactivate, but the narrative says that an admission moves it to complete. This is not consistent
• [response] Don't see the inconsistent language anywhere in the ballot. Where did you see this?

Interactions

The following interactions are defined:

Interaction	Name	Trigger Event	Payload	Desc
PRPA_IN412001UV02	Inpatient Admission Scheduled	PRPA_TE412001UV02	PRPA_MT412001UV02	In inpatient scheduling system sends this notification when an inpatient admission is scheduled. The payload is a complete inpatient appointment record with related acts and participations.
PRPA_IN412002UV02	Scheduled Inpatient Admission Revised	PRPA_TE412002UV02	PRPA_MT412001UV02	An inpatient scheduling system sends this notification when a scheduled inpatient admission is revised before the encounter has started. The payload is a complete inpatient appointment record with related acts and participations.
PRPA_IN402001UV02	Inpatient Encounter Started	PRPA_TE402001UV02	PRPA_MT402001UV02	An inpatient encounter informer sends this notification when a patient is admitted to an inpatient encounter. The payload is a complete inpatient encounter record with related acts and participations.
PRPA_IN402002UV02	Inpatient Encounter Revised	PRPA_TE402002UV02	PRPA_MT402002UV02	An inpatient encounter informer sends this notification when information about an inpatient encounter changes (except for changes to Attending Practitioner, Patient Location and Responsible Organization participations that cause separate interactions). The payload is a complete inpatient encounter record with related acts and participations.
PRPA_IN402008UV02	Encounters for Baby and Mother Linked	PRPA_TE402008UV02	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after the inpatient encounter for a newborn baby is linked to the inpatient encounter for the baby's mother for care and billing purposes. A separate interaction is defined for each type of encounter link because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. They payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "added".
PRPA_IN402010UV02	Encounters for Donor and Recipient Linked	PRPA_TE402010UV02	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after the inpatient encounter for an organ donor is linked to the inpatient encounter for the organ recipient for care and billing purposes. A separate interaction is defined for each type of encounter link because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. The payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "added".
PRPA_IN402013UV02	Pending Inpatient Discharge Canceled	PRPA_TE402013UV02	PRPA_MT402002UV02	A user initiates a notification that a previously reported pending inpatient discharge notification is being canceled. The payload contains a snapshot of the encounter following the action.
PRPA_IN402012UV02	Inpatient Discharge Pending	PRPA_TE402012UV02	PRPA_MT402002UV02	A user initiates a notification that an inpatient will soon be discharged. The payload is a Revised Inpatient Encounter message type. In this notification interaction the encounter remains in the event mood and the statusCode remains active. However, discharge-related attributes and associations, if valued, have the following interpretations...
PRPA_IN402009UV02	Encounters for Baby and Mother Unlinked	PRPA_TE402009UV02	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after an erroneous link between the inpatient encounter for a newborn baby and the inpatient encounter for the baby's mother was deleted. A separate interaction is defined for each type of encounter unlink because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. The payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "delete".
PRPA_IN402011UV02	Encounters for Donor and Recipient Unlinked	PRPA_TE402011UV02	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after an erroneous link between the inpatient encounter for an organ donor and the inpatient encounter for the organ recipient was deleted. A separate interaction is defined for each type of encounter unlink because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. The payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "deleted".
PRPA_IN402004UV02	Inpatient Encounter Aborted	PRPA_TE402004UV02	PRPA_MT402004UV02	An inpatient encounter informer sends this notification after an inpatient encounter is aborted prior to completion. This could have been result of action by either the practitioner or the patient. The payload contains information about the end of the encounter and the reason the encounter was aborted.
PRPA_IN402003UV02	Inpatient Encounter Completed	PRPA_TE402003UV02	PRPA_MT402003UV02	An inpatient encounter informer sends this notification after an inpatient is discharged. The payload contains encounter attributes and associations that can be changed by encounter completion.
PRPA_IN402007UV02	Inpatient Discharge Canceled	PRPA_TE402007UV02	PRPA_MT402001UV02	An inpatient encounter informer sends this notification after a previously reported inpatient discharge action is canceled. The payload contains a snapshot of the restored inpatient encounter.
PRPA_IN402006UV02	Inpatient Encounter Nullified	PRPA_TE402999UV02	COMT_MT001103UV	This notification occurs after a previously reported Inpatient Encounter Started interaction is nullified.

notes:

• 1:1 relationship between trigger events and interactions. Don't know whether the division is more useful in other domains
• so see next table

Summary of Dynamic Model

Name of Interaction	State Transition	Information Model	Description
Inpatient Encounter Appointment Scheduled	activate	PRPA_MT412001UV02	In inpatient scheduling system sends this notification when an inpatient admission is scheduled. The payload is a complete inpatient appointment record with related acts and participations.
Inpatient Encounter Appointment Revised	revise (active only)	PRPA_MT412001UV02	An inpatient scheduling system sends this notification when a scheduled inpatient admission is revised before the encounter has started. The payload is a complete inpatient appointment record with related acts and participations.
Inpatient Encounter Started	complete	PRPA_MT402001UV02	An inpatient encounter informer sends this notification when a patient is admitted to an inpatient encounter. The payload is a complete inpatient encounter record with related acts and participations.
Link Encounters for Mother and Baby	revise x 2	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after the inpatient encounter for a newborn baby is linked to the inpatient encounter for the baby's mother for care and billing purposes. A separate interaction is defined for each type of encounter link because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. They payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "added".
Unlink Encounters for Mother and Baby	revise x 2	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after an erroneous link between the inpatient encounter for a newborn baby and the inpatient encounter for the baby's mother was deleted. A separate interaction is defined for each type of encounter unlink because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. The payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "delete".
Link Encounters for Recipient and Donor	revise x 2	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after the inpatient encounter for an organ donor is linked to the inpatient encounter for the organ recipient for care and billing purposes. A separate interaction is defined for each type of encounter link because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. The payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "added".
Unlink Encounters for Recipient and Donor	revise x 2	PRPA_MT402008UV02	An inpatient encounter informer sends this notification after an erroneous link between the inpatient encounter for an organ donor and the inpatient encounter for the organ recipient was deleted. A separate interaction is defined for each type of encounter unlink because the same two encounters could be linked in more than one way. For example, a mother could also donate part of her liver to her newborn infant. The payload contains enough information to identify the two encounters and an associating ActRelationship with an update mode of "deleted".
Pending Inpatient Discharge	revise	PRPA_MT402002UV02	A user initiates a notification that an inpatient will soon be discharged. The payload is a Revised Inpatient Encounter message type. In this notification interaction the encounter remains in the event mood and the statusCode remains active. However, discharge-related attributes and associations, if valued, have the following interpretations...
Pending Inpatient Discharge Canceled	revise	PRPA_MT402002UV02	A user initiates a notification that a previously reported pending inpatient discharge notification is being canceled. The payload contains a snapshot of the encounter following the action.
Inpatient Encounter Revised	revise (complete only?)	PRPA_MT402002UV02	An inpatient encounter informer sends this notification when information about an inpatient encounter changes (except for changes to Attending Practitioner, Patient Location and Responsible Organization participations that cause separate interactions). The payload is a complete inpatient encounter record with related acts and participations.
Inpatient Encounter Aborted	revise?	PRPA_MT402004UV02	An inpatient encounter informer sends this notification after an inpatient encounter is aborted prior to completion. This could have been result of action by either the practitioner or the patient. The payload contains information about the end of the encounter and the reason the encounter was aborted.
Inpatient Discharge	revise?	PRPA_MT402003UV02	An inpatient encounter informer sends this notification after an inpatient is discharged. The payload contains encounter attributes and associations that can be changed by encounter completion.
Inpatient Discharge Canceled	revise?	PRPA_MT402001UV02	An inpatient encounter informer sends this notification after a previously reported inpatient discharge action is canceled. The payload contains a snapshot of the restored inpatient encounter.
Inpatient Encounter Nullified	nullify	COMT_MT001103UV	This notification occurs after a previously reported Inpatient Encounter Started interaction is nullified.

Thoughts From PA on Dynamic Model

Patient Administration TC is looking to capture and express "business" state transitions. For example, a patient encounter may first be noted as an intention, then is scheduled as an appointment, then becomes active when the patient arrives, and finally is completed when the patient is discharged. This process flow makes sense to domain experts but the RIM defines the first three as separate classes because they are in different Moods. Other business events of interest do not change the state of the focal encounter but rather reflect changes in act relationships (linking/unlinking the encounters for a mother and newborn), participations (transfer patient to a different location; change attending physician; etc.), or business events (pending discharge). Other business events do cause changes in the state of the focal encounter (active encounter is aborted prior to completion; encounter is suspended when patient takes a leave of absence and resumed when the patient returns; encounter is completed when patient is discharged). Some events relate only to the information about the encounter rather than the encounter itself (erroneous report of an encounter is nullified; encounter is reported as completed but is reactivated before the patient leaves the service delivery site). The interactions in the current publication are limited to notifications with no receiver responsibility but a more complete business model will include requests such as "admit request", "transfer request", "discharge request" that would have different moods and so would be different classes.

technical note: changing the associations of a class means revising the class.--GrahameGrieve 09:29, 6 June 2008 (CDT)

comment: let's take this in two parts: the notification model, and then the requesting model

Conclusion

This is the model, such as we have it. I don't think that the state transition model makes a useful contribution in this context. I think it's a good principle, but the core question of the relationship between a scheduled, current, and completed admission needs to be properly addressed, and I don't think this model does.

{PA response] The Inpatient Encounter messages are all Notification with no Receiver Responsibility as such they do not require much from a dynamic model. At one time we described state transitions on encounter from pending to scheduled to active to completed but we were told by MnM that EncounterIntent, EncounterAppointment and EncounterEvent are different classes so those "business" transtions can only be shown in Story Boards. The storyboards in Person (in PA) and Provider (in PM) Registries are more interesting from a Dynamic Model perspective since they use Request-Fulfill interactions. Also, with no design patterns to follow, PA and PM modeled these slightly differently placing extra burden on implementers.