...
An EpisodeOfCare provides context for and is referenced from a potentially large number of resources of differing type, including CarePlan, Observation and Task to name a few. This function as context is not affected by the lifecycle of the EpisodeOfCare. There are some resources with a lifecycle somewhat linked to that of the EpisodeOfCare, such as the zero, one or more CarePlan and associated one or more ProcedureRequestServiceRequest.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
It is reasonable to suggest a natural order of lifecycle that could help the clinicians keep an overview of the general status of a Patient. This natural order would include that the EpisodeOfCare should have status active before associated CarePlan can become active and vice-versa that CarePlan should have status other than draft and active before an EpisodeOfCare can have status finished. The service providing operations for creating and maintaining EpisodeOfCare, CarePlan and ProcedureRequest ServiceRequest does not depend on nor enforce any specific order when closing an EpisodeOfCare. Such dependency, however, exists for the following automated processing functionality of the Infrastructure:
patient reminders - a periodic check of all active CarePlan and ProcedureRequest ServiceRequest to determine whether a reminder for submitting measurements should be sent to the Patient
overdue measurement submits - a periodic check of all active CarePlan and ProcedureRequest ServiceRequest whether measurements have been submitted.
...
Therefore, the process of closing an EpisodeOfCare is:
Close all ProcedureRequest ServiceRequest belonging to a CarePlan before closing the CarePlan
Close all sub-plans of a CarePlan before closing the parent CarePlan
Close all CarePlan belonging to an EpisodeOfCare before closing the EpisodeOfCare
...