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

Obligation Discussion - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions


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 PairingSourceSourceManagerManagerDBDBConsumer 1Consumer 1DBDBConsumer 2Consumer 2DBDBBroadcastingsend Patient Datastore Patient datareturn responsesend Patient Datastore Patient datareturn responsesend Patient Datastore Patient datareturn responseend Broadcasting

Pairing 2: Specific Workflow

one:one PairingOrder PlacerOrder PlacerDB PlacerDB PlacerOrder FillerOrder FillerDB FillerDB FillerFiller EngineFiller EngineCreate 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 PairingSource 1Source 1Source 2Source 2Source 3Source 3CollectorCollectorDBDBData 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 BCollectorCollectorActor CActor CActor DActor DRegistrationregister Patientmap identifierstore Patient dataprint datareturn responseRegistrationregister Patientmap identifierstore Patient dataprint datareturn responseDiagnosissubmit diagnosisstore diagnosisreturn responseDiagnosissubmit diagnosisstore diagnosisreturn response


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


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)