Difference between revisions of "ART Scenario Editor"

Line 1: Line 1:
 
<!--{{Underconstruction}}-->
 
<!--{{Underconstruction}}-->
== Introduction ==
+
{{:ART_Scenario_Introduction}}
Scenarios are a container for transaction groups and transactions and will typically represent a health care use case, e.g. a Medication Prescription or a Radiology Examination. With that, scenarios/transaction provide the usage context as starting communicating without knowing why is not suitable.
 
 
 
Transaction groups contain Transactions. There are two categories of transactions.
 
 
 
Category 1: The pair of "initial" and "back" used in the messaging paradigm where an initial information transfer evokes a response message in terms of an acknowledgement or in a query/response environment. This transaction typically has a sender and a receiver interacting.
 
 
 
[[File:ScenarioEditor-transaction1.jpg|750px]]
 
 
 
Category 2: The "stationary" transaction that is a self-referencing transaction for example to create a document. This interaction typically has a "sender" only, that is more a creator of the document. Sending and receiving aspects are not part of this category of transaction and handled separately.
 
 
 
[[File:ScenarioEditor-transaction2.jpg|750px]]
 
 
 
Transactions represent a (sub)set of concepts from a dataset and add cardinality, conformance and possible conditions to them so they reflect the use case demands appropriately. A transaction typically has a reference to a representing template, that is the technical representation of the transaction and its underlying concepts.
 
 
 
[[File:ScenarioEditor-transaction3.jpg|750px]]
 
  
 
== Creating a scenario ==
 
== Creating a scenario ==

Revision as of 12:53, 8 July 2020

Introduction

Scenarios are a container for transaction groups and transactions and will typically represent a health care use case, e.g. a Medication Prescription or a Radiology Examination. With that, scenarios/transaction provide the usage context as starting communicating without knowing why is not suitable.

Transaction groups contain Transactions. There are two categories of transactions.

Category 1: The pair of "initial" and "back" used in the messaging paradigm where an initial information transfer evokes a response message in terms of an acknowledgement or in a query/response environment. This transaction typically has a sender and a receiver interacting.

ScenarioEditor-transaction1.jpg

Category 2: The "stationary" transaction that is a self-referencing transaction for example to create a document. This interaction typically has a "sender" only, that is more a creator of the document. Sending and receiving aspects are not part of this category of transaction and handled separately.

ScenarioEditor-transaction2.jpg

Transactions represent a (sub)set of concepts from a dataset and add cardinality, conformance and possible conditions to them so they reflect the use case demands appropriately. A transaction typically has a reference to a representing template, that is the technical representation of the transaction and its underlying concepts.

ScenarioEditor-transaction3.jpg

Creating a scenario

This documentation describes setting up scenarios from scratch, so there are no actors or scenarios present when starting.

Add Actors

Open the Actors tab. Add Actors by clicking on the plus sign (1).

ScenarioEditor-actor.jpg

Enter a name for the Actor (2), choose the type of actor: Person, Organization or Device (3). Click on the small plus under "Description" to add a description for this Actor.

Finally save the Actors by clicking Save (4) or cancel the edit by clicking Cancel.

Add Scenario and Transaction Group

Next create a Scenario by opening the Scenarios tab and clicking on the plus sign (1).

ScenarioEditor-scenario.jpg

Click on the Scenario in the navigation area (2) and edit the name of the Scenario (3). Then click on the Transaction Group (4) and edit the name of the Transaction Group as well (5).

Finally hit the Save button (6) or cancel the edit by clicking Cancel.

Add a Transaction of Type "stationary" (e.g. CDA documents)

Click on the Transaction in the navigation area and edit the name (2). Select as type "Stationary" (3) because a CDA document is always a stationary transaction (the sending action´city is a different thing). In addition you need to label a transaction (4). This is a business name (only letters and digits are allowed).

Information.svg The Transaction label is also used for the name of the resulting schematron file. For example, if the label is "vitsig2017" your schematron file would be named "projectprefix-vitsig2017.sch".

ScenarioEditor-transactionstationary.jpg

As stationary transaction do not have a "back" flow of information (as the acknowledgement in messages) click on the "back" transaction (5, e.g. Response) and click on the red cross (6) to delete this unused transaction.

Add a Transaction of Type "initial" and "back" (e.g. messages)

ScenarioEditor-transactionback.jpg

ScenarioEditor-transactioninitial.jpg

Assign a Representing Template

To assign a Representing Template to a Transaction, click on the respective Transaction and edit it. Right to the bottom you will find the "Template" with a pen to assign (or change) the Representing Template. By clicking on the edit pen you will get a list of all templates of your project. Choose the appropriate Representing Template (e.g. a CDA document level template, a message template) and click on the Save button.

ScenarioEditor-representingtemplate.jpg

Editing the concepts of a transaction

ScenarioEditor-transaction4.jpg

Form parameters

The scenarios form, as most other forms, supports parametrization.

/decor-scenarios--[prefix]?id=[scenario/transaction id]&effectiveDate=[scenario/transaction effective date]&datasetId=[dataset id]&datasetEffectiveDate=[dataset effective date]&conceptId=[concept id]&conceptEffectiveDate=[concept effective date]
Parameter Description Since
prefix Project prefix always
id Switches to the project scenario or transaction with this id. Format: OID always
effectiveDate Switches to the project scenario or transaction with this effective date. Format: yyyy-mm-ddThh:mm:ss. Works only in combination with param id always
datasetId Filters the list of scenarios/transaction to those that binds the project dataset with this id. Format: OID always
datasetEffectiveDate Filters the list of scenarios/transaction to those that binds the project dataset with this effectiveDate. Format: yyyy-mm-ddThh:mm:ss. art v1.5
conceptId Selects the dataset concept with this id in the selected transaction. Format: OID. Param only works if the param id points to a transaction that binds the dataset that contains this concept. always
conceptEffectiveDate Selects the dataset concept with this effective date in the selected transaction. Format: yyyy-mm-ddThh:mm:ss. Works only in combination with param conceptId always
actorId Selects the actor with this id in the list of actors. Format: OID. Setting this param assumes param section=actors always
section Switches to the requested section. Options
  • scenarios (default if actorId is not used) - switches to the tab Scenarios
  • actors (default if param actorId is used) - switches to the tab Actors
art v1.5.3

Locking

ART uses item level locking to prevent multiple users form editing the same item. When an item is edited this item and all children and parents of this item are locked. Locks are released when the changes are saved or the action is cancelled, when navigating away from the page a warning is displayed:

Page-leave-message.png

Navigating away from the page without saving the changes or cancelling the edit will leave the lock in place. If the same user attempts to edit the item at a later time the lock will be cleared automatically, if another user attempts to edit the item a message is displayed that the item is locked:

Scenario-lock-message.png

It is possible to break the lock at this time, be sure that no other user is actually working on this item before breaking a lock. Project administrators can access an overview of all locks for the project on the Status tab of the Project Information page:

Scenario-project-locks.png

Individual locks can be cleared here and all locks for a particular user can also be cleared here. The Status tab on the DECOR administration page shows the locks for all projects:

Scenario-decor-locks.png

Individual locks can be cleared here and all locks for a particular user can also be cleared here.