This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Example model 1 for new dynamic model

From HL7Wiki
Jump to navigation Jump to search

Introduction

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

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:

Dm e1 storyboard.gif

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
PRPA_TE412001UV02 Inpatient Encounter Appointment Scheduled an inpatient admission was scheduled
PRPA_TE412002UV02 Inpatient Encounter Appointment Revised a scheduled inpatient admission was modified prior to the admission
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
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.
PRPA_TE402009UV02 Unlink Encounters for Mother and Baby the sending system has removed the baby to mother link between two inpatient encounters.
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
PRPA_TE402011UV02 Unlink Encounters for Recipient and Donor sending system has removed the organ donor to recipient link between two inpatient encounters
PRPA_TE402012UV02 Pending Inpatient Discharge signals of a plan to discharge an inpatient when the patient has not yet left the healthcare facility.
PRPA_TE402013UV02 Pending Inpatient Discharge Canceled signals that a planned inpatient discharge was canceled
PRPA_TE402002UV02 Inpatient Encounter Revised signals that information about an inpatient encounter has changed
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.
PRPA_TE402003UV02 Inpatient Discharge an inpatient was discharged
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.
PRPA_TE402999UV02 Inpatient Encounter Nullified signals that a previously-reported inpatient admission notification was sent in error and has been nullified