Difference between revisions of "Composite Order Conceptual Spec"
(Created page with "Link back to project page Composite Order =Composite Order= =Executive Summary= *This document contains the necessary definitions, descriptions, graphics, ...") |
|||
Line 25: | Line 25: | ||
[[File:CompositeRequestActors.png]] | [[File:CompositeRequestActors.png]] | ||
− | ==Storyboards and | + | ==Storyboards and Event Flows== |
==='''Universal Storyboard - Create Composite Order=== | ==='''Universal Storyboard - Create Composite Order=== | ||
Line 47: | Line 47: | ||
results, formulates a treatment, if needed, and notifies Eve Everywoman of the results and | results, formulates a treatment, if needed, and notifies Eve Everywoman of the results and | ||
treatment. | treatment. | ||
+ | |||
+ | ==Use Cases== | ||
+ | *What is the use case? | ||
+ | *Dr Hippocrates has created order sets, by condition, for conditions which he treats. His order system communicates.... | ||
+ | *Nutrition - some orders are communicated to both the nutrition department and pharmacy (TPN). | ||
+ | *Patient on insulin | ||
===Composite Order Business Process=== | ===Composite Order Business Process=== |
Latest revision as of 06:32, 14 May 2012
Link back to project page Composite Order
Contents
- 1 Composite Order
- 2 Executive Summary
- 3 Business Model Conceptual Artifacts
- 4 Information Model Conceptual Artifacts
- 5 Solution Specification
Composite Order
Executive Summary
- This document contains the necessary definitions, descriptions, graphics, and artifacts relevant to the implementation of an electronic request for healthcare services between an ordering provider and fulfilling service providers.
Business Model Conceptual Artifacts
Business Context
- The composite order domain comprises the models, messages, and other artifacts that are needed to support messaging related to sending multiple requests for healthcare services in one exchange.
Business Function
For this specification, the business function at its most basic is about ordering (requesting a healthcare service) and the fulfillment of that request by filling entities.
Basic business process use case bubble diagram
The following bubble diagram describes the ordering business process.
Conceptual Roles
Storyboards and Event Flows
Universal Storyboard - Create Composite Order
Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic and is seen by Dr. Patricia Primary. Eve reports a history of Anemia and recent, excessive tiredness. Dr. Primary enters a request to check the iron levels in Eve’s blood into her care system. Dr. Primary’s care system then sends the test requests to the lab system at the Good Health Hospital’s Laboratory service. Eve receives a paper order requisition that serves as a reminder, provides instructions for where to find the collection center, and also details preparation instructions for the patient to follow (no food or drink from midnight until collection time on the day of collection). Later that week Eve presents herself at the Lab Collection Center. The lab looks up and finds the order for her testing in the lab system. The appropriate blood samples are extracted, their containers labeled, and the sample information added to the information in the lab system. The lab performs the analysis on the specimen(s), adds the results to the lab system, and sends the results to Dr. Primary’s care system reported as final. Dr. Primary reviews the results, formulates a treatment, if needed, and notifies Eve Everywoman of the results and treatment.
Use Cases
- What is the use case?
- Dr Hippocrates has created order sets, by condition, for conditions which he treats. His order system communicates....
- Nutrition - some orders are communicated to both the nutrition department and pharmacy (TPN).
- Patient on insulin
Composite Order Business Process
For Laboratory Diagnostics (specimen testing), the following illustrates high-level business functions:
- Diagnostic (or Public Health) Specimen-based Laboratory work requested for a subject (patient, animal, environmental location, etc)
- Specimen collected from subject
- Specimen accessioned by lab (i.e., enters lab testing process)
- Specimen processed into testable samples
- Samples tested by lab
- Results from lab testing obtained, interpreted, and approved/authorized
- Results returned to requester
- Requester determines next steps and course of action
Business Process Assumptions
While the above list shows the performed steps in a basic lab ordering/fulfillment process, each of these steps may be performed by different actors/roles in any one specific process; for example, a Clinician, Laboratory Technician (e.g., phlebotomist), Investigation Team Member, the Subject (patient), or a person responsible for a Subject may collect the specimen. In addition, the steps may be performed at different locations; specimens may be collected at the point of care, at the subject's location (e.g., at a patient's home, "in the field", etc), in the testing lab, or at a specimen collection organization. The steps may also be performed in different order or not performed at all under given, specific conditions - a specimen may not require any processing prior to being tested or a specimen is assigned an accession number prior to being collected if it is being collected in the lab. Finally, the involvement of an electronic system to capture the information and facilitate the business process is not assumed in the above steps and may not be present depending upon the conditions under which each step is performed.
Event Flows
Below is the event flow for Create Laboratory Order which defines the necessary activities, decisions, and information exchange points. The Laboratory Order Repository needed for the 3rd storyboard above is handled via an alternate flow and is not represeted in the diagram below.
Next is the event flow for Revise Laboratory Order. Note that any revision is a 'request to modify'. Depending on the situation, the performing laboratory may reject the revision.
ISSUE: Is modifying the composite order allowed?
Information Model Conceptual Artifacts
Conceptual Information Model
Comment: Provide links to the Analysis Information Model for the domain
The following classes were derived from the storyboards and use cases.
Conceptual Data Types Model
Conceptual State Model
There are a couple of different types of state models. The first is representing the status of the whole business process. The states are represented as statuses which correlate to Key activities on the event flow. The second are a set of state models, one for each Key information object, defining the appropriate statuses for each object.
For the business process state machine:
We can derive the following request object states and transitions from the above storyboards:
As you can see, the request object has a status for when the fulfiller asserts the request is fulfilled, but the request has not yet evaluated that assertion (called fulfillment resolution). There are also the two other, expected, request statuses: active and complete. In the simplest request use cases, the request only takes one of these states. We can derive the following fulfillment object states and transitions from the storyboard:
Again the status, this time for fulfillment, is restricted in this simplest use case to null and resulted.
Lastly for this simple use case, we can derive the following result object states and transitions from the storyboard:
In this use case, only the completed state is important for interoperability.
Concept Domains
- ActStatus
- LaboratoryOrderableTestCode
- LaboratoryQualitativeResultCode
- DocumentTypeCode
Solution Specification
Scenario #1 - Create Lab Order
Overview
Business Scenario
The event flow for a simple lab order is shown below
File:Create Laboratory Order Activity Diagram.png
Contract Roles and Agents
The commissioning and responsible parties involved in this process include:
Specification Reference | Commissioning System Role | Responsible System Role | Operation |
---|---|---|---|
Order Requestor (Placer in v2) | Order Request Manager | createRequest | |
Order Request Manager | Fulfillment Manager | createRequest | |
add | add | add |
Computational Viewpoint
The following sequence diagram depicts the interactions that support the above event flow
Service Dependencies
Comment: Describe any dependencies of the process being specified
The parties supporting this process are the Order Request Manager and Fulfillment Manager, depicted below
Implemented Patterns
Comment: Indicate the any patterns that apply to this process specification
Contractual Semantics and Issues
Conformance Statements
Comment: define the conformance criteria for this specification