Difference between revisions of "Example model 1 for new dynamic model cdl"
Line 61: | Line 61: | ||
* HL7.Name is used as the Trigger Event Name | * HL7.Name is used as the Trigger Event Name | ||
* | * | ||
+ | |||
+ | = Issues with the Mapping = | ||
+ | * How does a participant set a variable? Does it have to be free? | ||
+ | * Is the "Choice" Grouping the correct one to model which state transition (via global variables) has just been triggered? How is the choice "made"? | ||
= Interactions = | = Interactions = |
Revision as of 17:34, 9 July 2008
Contents
Introduction
This is a mapping from the example (here Example_model_1_for_new_dynamic_model) to CDL.
Explanation
The focus on this mapping is to create a repeatable trasnformation based on the ADT material only, with the intent that we could use it as a jumping off place for other types of transformations.
State Model
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 |
Mapping
Following are the mapped elements between CDL and the HL7 specification
- A Top Level ADT Notification is created that will call all other Choreographies
- HL7.Interaction is created as a CDL.Choreography (top-level choreography; 1..1)
- HL7.Name is used as the Trigger Event Name
Issues with the Mapping
- How does a participant set a variable? Does it have to be free?
- Is the "Choice" Grouping the correct one to model which state transition (via global variables) has just been triggered? How is the choice "made"?
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.