Obligation Discussion
0.5.1 - Working Draft to present the Concept Ideas and Background Details (FO)

Obligation Discussion, published by . This guide is not an authorized publication; it is the continuous build for version 0.5.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/frankoemig/obligation/ and changes regularly. See the Directory of published versions

Pairing

This page discusses different ways of pairing creators and consumers.

Example Pairings (Workflows)

For further explanations lets discuss some example pairings of creators and consumers. The actor icon should denote the actors for which obligations are to be defined:

  • one:many: broadcast
  • one:one: workflow
  • many:one: data collection

Pairing 1: Patient Data broadcast

Using the most common data broadcast messaging which is used to realize the ADT workflow is to send messages from a single source to multiple targets. All those have different interest in the data, and therefore have different requirements concerning the content. As a result, the source has to combine and fulfill all requirements from all targets:

many:one Pairingmany:one PairingSourceManagerConsumer 1Consumer 2SourceManagerDBConsumer 1DBConsumer 2DBSourceSourceManagerManagerDBDBConsumer 1Consumer 1DBDBConsumer 2Consumer 2DBDBSourceManagerConsumer 1Consumer 2Broadcastingsend Patient Datastore Patient datareturn responsesend Patient Datastore Patient datareturn responsesend Patient Datastore Patient datareturn responseend Broadcasting

Pairing 2: Specific Workflow

one:one Pairingone:one PairingOrder PlacerOrder PlacerDB PlacerDB PlacerDB PlacerOrder FillerOrder FillerDB FillerDB FillerDB FillerOrder PlacerDB PlacerOrder FillerDB FillerFiller EngineOrder PlacerOrder PlacerDB PlacerDB PlacerOrder FillerOrder FillerDB FillerDB FillerFiller EngineFiller EngineOrder PlacerOrder PlacerDB PlacerDB PlacerDB PlacerOrder FillerOrder FillerDB FillerDB FillerDB FillerCreate Orderget datadatasend create orderstore orderreturn filler idreturn filler idstore filler idresponseUpdate Order Statusupdate statusstore statusresponsesend status updatestore statusresponsesend responsestore process statusresponseSend Order Results

Pairing 3: Data Collection (General)

In a data collection scenario, a single consumer collects data from multiple sources, thereby providing a maximum of what can be accepted, whereas each source only has to fulfill the minimum set of requirements:

many:one Pairingmany:one PairingCollectorCollectorCollectorSource 1Source 2Source 3CollectorDBSource 1Source 1Source 2Source 2Source 3Source 3CollectorCollectorDBDBCollectorCollectorCollectorData Submissionsubmit datastore dataresponsesubmit datastore dataresponsesubmit datastore dataresponse
Pairing 3b: Registration + Data Submission (Specific)

In a normal registration workflow, or order entry is a 1:1 relationship between sender and recipient. But for registration processes it is a many:one relationship:

Submitter ASubmitter ASubmitter BSubmitter BCollectorCollectorCollectorCollectorSubmitter ASubmitter BCollectorActor CActor DSubmitter ASubmitter ASubmitter BSubmitter BCollectorCollectorActor CActor CActor DActor DSubmitter ASubmitter ASubmitter BSubmitter BCollectorCollectorCollectorCollectorRegistrationregister Patientmap identifierstore Patient dataprint datareturn responseRegistrationregister Patientmap identifierstore Patient dataprint datareturn responseDiagnosissubmit diagnosisstore diagnosisreturn responseDiagnosissubmit diagnosisstore diagnosisreturn response

Constraints

What set of constraints are to added for the different pairings?

Pairing Creator Consumer Comment
one:many maxium (=superset)   creator collects requirements that drives communication
one:one exact exact everything that does not match is lost
many:one minimum maximum consumer defines the minimum and maximum of what is considered

Consequences

What are the take-awqays or Consequences that results from the aforementioned considerations:

  • In most use cases only some (few) actors are needed
  • each actor will normally have only a few (1-3) obligations (functional requirements + bound/referenced data)
  • Data can be referenced for different activities (eg. Store + print) for same actor
    • Higher requirement level wins (SHALL store + MAY print => SHALL)
  • Abstract actor can involve direction-specific actors
    • Manager => consumer + response provider (with same or different data)