Obligation Discussion
0.4.1 - Working Draft to present the Concept Ideas and Background Details (FO)
Obligation Discussion
0.4.1 - Working Draft to present the Concept Ideas and Background Details (FO)
Obligation Discussion - Local Development build (v0.4.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
This is the 1st definition for Obligations.
| A) Base Patient Profile |
Base Patient Profile that provides the base requirements |
| A) Profile Sender Profile |
This profile has to include all mustSupport fields for a sender. |
| Obligation1Definition |
Obligation 1 Definition Description: is to be placed behind the actor: profile 0..* <- 1 actor 0..* <-> 0..* obligation |
This is a 2nd definition (as an alternative) for Obligations.
| Obligation2Definition |
Obligation 2 Definition Description: is to be placed before the actor - profile 0..* <- 1 obligation 1..* <- 1 actor |
These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.
| my other own Actor Definition2 |
my own Actor Definition2 (this time defined to test characteristics feature of FSH) |
| my own Actor Definition 1 |
my own Actor Definition 1 This puts the actor in the middle, and points to obligations |
| my own Actor Definition 2 |
my own Actor Definition 2 This puts the obligation into the middle, and takes pointers from actors. |
These define constraints on FHIR resources for systems conforming to this implementation guide.
| A) Profile Receiver Obligation Profile |
This profile includes the obligation extension to the receiver. |
| A) Profile Receiver Profile |
This profile adds the mustSupport fields for a receiver. |
| A) Profile Sender Obligation Profile |
This profile includes the obligation extension to the sender. |
| B) Super Patient Profile |
super profile that combines all requirements |
| Patient (Obligation Test) |
This profile represents the constraints applied to the Patient resource to test obligation extensions |
These define constraints on FHIR data types for systems conforming to this implementation guide.
| New Obligation Extension |
Modified Extension to handle the obligations as I would like to see it. Also allowing for my own codesystems - where necessary. |
These define sets of codes used by systems conforming to this implementation guide.
| Data Expectation ValueSet |
Valueset for data expectations |
| Obligation Alone ValueSet |
Valueset for obligations (alone) |
| Proposed Content-consumption-oriented Obligation Codes VS |
This valueset represents the proposed obligation codes for consuming the content. |
| Proposed Content-creation-oriented Obligation Codes VS |
This valueset represents the proposed obligation codes for creating the content. |
| Proposed Obligation Codes VS (active only) |
This valueset represents the proposed obligation codes that are available for use (active resp. not abstract). |
| Proposed Obligation Codes VS (complete) |
This valueset represents the proposed obligation codes. |
| Proposed Transport-oriented Obligation Codes VS |
This valueset represents the proposed obligation codes for managing transport requirements. |
| Verb ValueSet |
Conformance verbs ValueSet |
These define new code systems used by systems conforming to this implementation guide.
| Data Expectation Codes |
This is the codesystem describing exptectations for Data Handling. It has to be discussed whether these codes can become more specialised activities!? |
| Obligation Alone Codes |
This is the Obligation CodeSystem (alone) as part of the triplet. |
| Proposed Obligation Codes |
This codesystem is a proposal for obligation codes in response to Grahame’s codesystem for obligations. It represents an ontology that not only combines the other three codesystems (verb, obligation, data expectation), but also introduces some more axes/dimensions to better explain the meaning of the codes. |
| Supplementing original Obligation Codes (from Grahame, reduced text/property, but commented) |
This codesystem is a supplement to the original by providing comments and proposals. |
| Verb Codes |
This is the Verb CodeSystem as part of the triplet. |
These define transformations to convert between codes by systems conforming with this implementation guide.
| MapOriginalToProposed Mapping |
A mapping between the FHIR obligation codes, 5.0.0, and the ones proposed here. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| A) Patient 2 Example |
This patient instance is used to demonstrate how obligation extensions are used |
| Actor 1: Receiver |
Sample receiving actor based on my own Actor Definition 1 |
| Actor 1: Sender |
Sample Sending Actor based on my own Actor Definition 1 |
| Actor 1: Test |
Test Actor basdd on my own Actor Definition 1 |
| Actor 2: Receiver |
Receiving actor based on my own 2nd defintion |
| Actor 2: Sender |
Sending Actor based on my own 2nd definition |
| Actor 2: Test |
Test actor based on my own 2nd defintion |
| Actor Definition a: Sender Test |
Actor a: Sender Test |
| Actor Definition b: Receiver Test |
This actor is used to demonstrate receiving capabilities |
| Actor Definition c: Test (unused) |
Actor c: Test (unused) |
| B) Patient B 1 |
Simple Instance |
| Obligation 1a: send exactly |
Obligation 1a: send exactly the data as specified |
| Obligation 1b: store equivalent |
Obligation 1b: store the data as an equivalent |
| Obligation 1c: store exactly |
Obligation 1c: store exactly the data as specified |
| Obligation 2a: send exactly |
Obligation 2a: send exactly as specified |
| Obligation 2b: store equivalent |
Obligation 2b: store data in form of an equivalent |
| Obligation 2c: store exactly |
Obligation 2c: store exactly as specified |