<name of alternate coding system (IS)>
Definition: This field contains the ID number and name of the resource being
requested or scheduled for an appointment. This field is used to identify a
specific resource being requested, or a specific resource that has been
scheduled for an appointment. If the specific resource is not known but the
type of resource is, AIG-4-resource type is used to identify the type of
resource required or scheduled.
At a minimum, the ID number component should be supplied to identify either the
specific resource being requested or the specific resource that has been
scheduled. For inter-enterprise communications, for which a shared ID number
may not be available, the minimum components required to uniquely identify a
resource may be defined by site-specific negotiations.
This field is conditionally required for this segment. In new schedule request
messages, it is required if the request asks that a specific resource be
scheduled. For all other request messages, the specific resource should be
identified if the information is available (either because a specific resource
was initially requested, or because the filler application returned the ID of
the specific resource that has been scheduled).
This field is required for all unsolicited transactions from the filler
application.
This field is optional for all query transactions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the role of the resource requested/scheduled
for this appointment. For requests, if a specific resource is not identified
in AIG-3-Resource ID, then this field identifies the type of resource
that should be scheduled by the filler application. At a minimum, the type of
the identifier component should be valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the requested resource as a member of the
indicated group. If, in a Schedule Request Message (SRM), no specific resource
is requested, but a resource type is requested, this field can be used to
further qualify the type of resource being requested.
Definition: This field contains the quantity of the specified resource or resource type identified in either or both of the preceding two fields. If it is not valued, this field defaults to a value of one (1).
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units of the resource requested, whose
quantity is given in the preceding field. This field should be valued
according to the recommendations in Chapters 2 and 7. If this field is not
valued, the unit of each (code "ea") will be assumed. Refer to Chapter 7,
Figures 7-6 through 7-9, for a list of ISO and ANSI+ unit codes.
Definition:
This field contains the date and time this service needs for the appointment.
This field allows the application to identify that the service is required for
the appointment at a different time than the appointment's start date/time
This field is conditionally required. If a value for AIG-9-Start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIG-9-Start
date/time offset and any valid time unit code in AIG-10-Start date/time
offset units.
Definition:
This field contains the offset that this resource needs for the appointment,
expressed in units of time relative to the scheduled start date/time. This
field indicates to the application that the resource is required for the
appointment at a different time than the appointment's start date/time. The
first component indicates the offset amount. An offset of zero (0), or an
unvalued field, indicates that the resource is required at the start date/time
of the appointment.
A positive offset (an unsigned or positive number) indicates that the resource
is required after the appointment's start date/time. Specifying a negative
offset indicates that the resource is required prior to the specified start
date/time of the appointment. Negative offsets are allowed, and sites should
clearly define the effect of a negative offset on the appointment's start
date/time.
This field is conditionally required. If a value for AIG-8-Start date/time
is not provided, then a value is required for this field. To specify that
there is no difference between the appointment's start date/time and the
resource's start date/time either replicate the appointment's start date/time
into this field, or specify an offset of zero (0) in AIG-9-Start date/time
offset and any valid time unit code in AIG10-Start date/time offset
units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code describing the units of time used for
expressing AIG-9-Start date/time offset. This field should be valued
according to the recommendations made in Chapters 2 and 7. If this field is
not valued, the ISO base unit of seconds (code "s") will be assumed.
Refer to Chapter 7, Figures 7-6 through 7-9, for a list of ISO
and ANSI+ unit codes.
This field is conditionally required. If a value for AIG-9-Start date/time
offset is provided, then a value is required for this field.
Definition:
This field contains the duration for which the resource is requested/scheduled
for this appointment, if it is different than the overall duration of the
requested/scheduled appointment. This field indicates to the application that
a resource is required for a different amount of time than the appointment's
overall duration. An unvalued duration indicates that the resource is required
from its start date/time offset (specified in the previous two fields) until
the end of the appointment. If no start date/time offset is specified, then
the resource is required for the full duration of the appointment.
This field must be a positive, non-zero number. A negative number or zero (0)
is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code describing the units of time used for
expressing the AIG-11-Duration field. This field should be valued
according to the recommendations in Chapters 2 and 7. If this field is not
valued, the ISO base unit of seconds (code "s") will be assumed. Refer
to Chapter 7, Figures 7-6 through 7-9, for a list of ISO and
ANSI+ unit codes.
Definition:
This field contains a code indicating whether the identified resource can be
substituted with an equivalent resource by the filler application. Refer to
User-defined Table 0279 - Allow substitution codes for suggested
codes.
This field is conditionally required. It is required for all request messages.
It is optional for all unsolicited transactions, and for all query messages.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code that describes the requested/scheduled
status of scheduling resource or activity, from the point of view of the filler
application. Refer to User-defined Table 0278 - Filler status
codes for suggested codes.
This is a conditionally required field. Because the information contained in
this field is only appropriate in transactions originating from a filler
application, it is required for those messages. This includes all unsolicited
transactions originating from a filler application, as well as all response
messages originating from a filler application. This field is optional for all
transactions originating from placer, querying and auxiliary applications. It
is recommended that this field be left unvalued in transactions originating
from applications other than the filler application.
The
AIL segment contains information about location resources (meeting rooms,
operating rooms, examination rooms, or other locations) that can be scheduled.
Resources included in a transaction using this segment are assumed to be
controlled by a schedule on a schedule filler application. Resources not
controlled by a schedule are not identified on a schedule request using this
segment. Location resources are identified with this specific segment because
of the specific encoding of locations used by the HL7 specification.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
00902 |
Set ID - AIL |
||
2 |
3 |
ID |
C |
0206 |
00763 |
Segment Action Code |
|
3 |
80 |
PL |
C |
00903 |
Location Resource ID |
||
4 |
250 |
CE |
R |
00904 |
Location Type-AIL |
||
5 |
250 |
CE |
O |
00905 |
Location Group |
||
6 |
26 |
TS |
C |
01202 |
Start Date/Time |
||
7 |
20 |
NM |
C |
00891 |
Start Date/Time Offset |
||
8 |
250 |
CE |
C |
00892 |
Start Date/Time Offset Units |
||
9 |
20 |
NM |
O |
00893 |
Duration |
||
10 |
250 |
CE |
O |
00894 |
Duration Units |
||
11 |
10 |
IS |
C |
0279 |
00895 |
Allow Substitution Code |
|
12 |
250 |
CE |
C |
0278 |
00889 |
Filler Status Code |
Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.
Definition:
This field contains the action to be taken when updating or modifying
information in this segment from previously sent interface transactions. Refer
to HL7 Table 0206 - Segment action code in Chapter 2, Section <IP_ADDRESS>,
"Action code/unique identifier mode update definition," for valid values
This field is conditionally required. It is required for all updating or
modifying trigger events.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains a coded identification of the location being
requested or scheduled for an appointment. This field is used to identify a
specific location being requested, or a specific location that has been
scheduled for an appointment. If the specific location is not known but the
type of location is, AIL-4-Location type-AIL is used to identify the
type of location required or scheduled. Please see Section 2.9.29, "PL -
person location," in Chapter 2 for a description of each component.
This field is conditionally required for this segment. In new schedule request
messages, it is required if the request asks that a specific location be
scheduled. For all other request messages, the specific location should be
identified if the information is available (either because a specific location
was initially requested, or because the filler application returned the coded
identification of the specific location that has been scheduled).
This field is required for all unsolicited transactions from the filler
application. It is optional for all query transactions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the role of the location requested/scheduled
for this appointment. For requests, if a specific location is not identified
in AIL-3-Location resource ID, then this field identifies the type of
location that should be scheduled by the filler application. At a minimum, the
type identifier component should be valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the requested resource as a member of the
indicated group. If, in a Schedule Request Message (SRM), no specific location
is requested, but a location type is requested, AIL-5-Location group can
be used to further qualify the type of resource being requested.
Definition:
This field contains the date and time this service needs for the appointment.
This field allows the application to identify that the service is required for
the appointment at a different time than the appointment's start date/time
This field is conditionally required. If a value for AIL-7-Start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIL-7-Start
date/time offset and any valid time unit code in AIL-8-Start date/time
offset units.
Definition:
This field contains the offset this resource needs for the appointment,
expressed in units of time relative to the scheduled start date/time. This
field indicates to the application that the resource is required for the
appointment at a different time than the appointment's start date/time. The
first component contains the offset amount. An offset of zero (0), or an
unvalued field, indicates that the resource is required at the start date/time
of the appointment.
A positive offset (an unsigned or positive number) indicates that the resource
is required after the appointment's start date/time. Specifying a negative
offset indicates that the resource is required prior to the specified start
date/time of the appointment. Negative offsets are allowed, and sites should
clearly define the effect of a negative offset on the appointment's start
date/time.
This field is conditionally required. If a value for AIL-6-Start date/time
is not provided, then a value is required for this field. To specify that
there is no difference between the appointment's start date/time and the
resource's start date/time either replicate the appointment's start date/time
into this field, or specify an offset of zero (0) in AIL-7-Start date/time
offset and any valid time unit code in AIL-8-Start date/time offset
units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code describing the units of time used for
expressing the AIL-7-Start date/time offset field. This field should be
valued according to the recommendations made in Chapters 2 and 7. If this
field is not valued, the ISO base unit of seconds (code "s") will be
assumed. Refer to Chapter 7, Figures 7-6 through 7-9, for a list
of ISO and ANSI+ unit codes.
This field is conditionally required. If a value for AIL-7-Start date/time
offset is provided, then a value is required for this field.
Definition:
This field contains the duration for which the resource is requested/scheduled
for this appointment, if it is different than the overall duration of the
requested/scheduled appointment. This field indicates to the application that
a resource is required for a different amount of time than the appointment's
overall duration. An unvalued duration indicates that the resource is required
from its start date/time offset (specified in the previous two fields) until
the end of the appointment. If no start date/time offset is specified, then
the resource is required for the full duration of the appointment.
This field must be a positive, non-zero number. A negative number or zero (0)
is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code describing the units of time used
associated with AIL-9-Duration. This field should be valued according
to the recommendations made in Chapters 2 and 7. If this field is not valued,
the ISO base unit of seconds (code "s") will be assumed. Refer to
Chapter 7, Figures 7-6 through 7-9, for a list of ISO and ANSI+
unit codes.
Definition:
This field contains a code indicating whether the identified location can be
replace with an equivalent substitute location by the filler application.
Refer to User-defined Table 0279 - Allow substitution codes for
suggested codes.
This field is conditionally required. It is required for all request messages.
It is optional for all unsolicited transactions, and for all query messages.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code that describes the requested/scheduled
status of the location, from the point of view of the filler application.
Refer to User-defined Table 0278 - Filler status codes for
suggested codes.
This is a conditionally required field. Because the information contained in
this field is only appropriate in transactions originating from a filler
application, it is required for those messages. This includes all unsolicited
transactions originating from a filler application, as well as all response
messages originating from a filler application. This field is optional for all
transactions originating from placer, querying and auxiliary applications. It
is recommended that this field be left unvalued in transactions originating
from applications other than the filler application.
The
AIP segment contains information about the personnel types that can be
scheduled. Personnel included in a transaction using this segment are assumed
to be controlled by a schedule on a schedule filler application. Personnel not
controlled by a schedule are not identified on a schedule request using this
segment. The kinds of personnel described on this segment include any
healthcare provider in the institution controlled by a schedule (for example:
technicians, physicians, nurses, surgeons, anesthesiologists, or CRNAs).
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
00906 |
Set ID - AIP |
||
2 |
3 |
ID |
C |
0206 |
00763 |
Segment Action code |
|
3 |
250 |
XCN |
C |
Y |
00913 |
Personnel Resource ID |
|
4 |
250 |
CE |
R |
00907 |
Resource Role |
||
5 |
250 |
CE |
O |
00899 |
Resource Group |
||
6 |
26 |
TS |
C |
01202 |
Start Date/Time |
||
7 |
20 |
NM |
C |
00891 |
Start Date/Time Offset |
||
8 |
250 |
CE |
C |
00892 |
Start Date/Time Offset Units |
||
9 |
20 |
NM |
O |
00893 |
Duration |
||
10 |
250 |
CE |
O |
00894 |
Duration Units |
||
11 |
10 |
IS |
C |
0279 |
00895 |
Allow Substitution Code |
|
12 |
250 |
CE |
C |
0278 |
00889 |
Filler Status Code |
Definition: This field contains a number that uniquely identifies the information represented by this segment in this transaction for the purposes of addition, change or deletion.
Definition:
This field contains the action to be taken when updating or modifying
information in this segment from previously sent interface transactions. Refer
to HL7 Table 0206 - Segment action code in Chapter 2, Section <IP_ADDRESS>,
"Action code/unique identifier mode update definition," for valid values.
This field is conditionally required. It is required for all updating or
modifying trigger events.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or
III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)>
^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the ID number and name of the person being
requested or scheduled for an appointment. This field is used to identify a
specific person being requested, or a specific person who has been scheduled as
a resource for an appointment. If the specific person is not known, but the
type of resource is, AIP-4-Resource role is used to identify the type of
personnel resource required or scheduled. Refer to Chapter 2, Section 2.9.52,
"XCN - extended composite ID number and name for persons," for a description of
the components contained in the XCN data type.
At a minimum, the ID number component should be supplied to identify either the
specific person being requested or the specific person who has been scheduled.
For inter-enterprise communications, for which a shared ID number may not be
available, the minimum components needed to uniquely identify a person may be
defined by site-specific negotiations.
This field is conditionally required for this segment. In new schedule request
messages, it is required if the request asks that a specific person be
scheduled. For all other request messages, the specific person should be
identified if the information is available (either because a specific person
was initially requested, or because the filler application returned the ID of
the specific person who has been scheduled).
This field is required for all unsolicited transactions from the filler
application. This field is optional for all query transactions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the role of the personnel
requested/scheduled for an appointment. For requests, if a specific person is
not identified in the AIP-3-Personnel resource ID field, then this field
identifies the type of person that should be scheduled by the filler
application. At a minimum, the AIP-4-Resource role component should be
valued.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the requested resource as a member of the
indicated group. If, in a Schedule Request Message (SRM), no specific resource
is requested, but an AIP-4-Resource role is requested, the
AIP-5-Resource group field can be used to further qualify the type of
resource being requested.
Definition:
This field contains the date and time this service needs for the appointment.
This field allows the application to identify that the service is required for
the appointment at a different time than the appointment's start date/time.
This field is conditionally required. If a value for AIP-7-Start date/time
offset is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIP-7-Start
date/time offset and any valid time unit code in AIP-8-Start date/time
offset units.
Definition:
This field contains the offset this resource needs for the appointment,
expressed in units of time relative to the scheduled start date/time. This
field indicates to the application that the resource is required for the
appointment at a different time than the appointment's start date/time. The
first component contains the offset amount. An offset of zero (0), or an
unvalued field, indicates that the resource is required at the start date/time
of the appointment.
A positive offset (an unsigned or positive number) indicates that the resource
is required after the appointment's start date/time. Specifying a negative
offset indicates that the resource is required prior to the specified start
date/time of the appointment. Negative offsets are allowed, and sites should
clearly define the effect of a negative offset on the appointment's start
date/time.
This field is conditionally required. If a value for AIP-6-Start
date/time is not provided, then a value is required for this field. To
specify that there is no difference between the appointment's start date/time
and the resource's start date/time either replicate the appointment's start
date/time into this field, or specify an offset of zero (0) in AIP-7-Start
date/time offset and any valid time unit code in AIP-8-Start date/time
offset units.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code describing the units of time used for
expressing AIP-7-Start date/time offset. This field should be valued
according to the recommendations made in Chapters 2 and 7. If this field is
not valued, the ISO base unit of seconds (code "s") is assumed. Refer
to Chapter 7, Figures 7-6 through 7-9, for a list of ISO and
ANSI+ unit codes.
This field is conditionally required. If a value for AIP-7-Start date/time
offset is provided, then a value is required for this field.
Definition:
This field contains the duration for which the resource is requested/scheduled
for an appointment, if different from the overall duration of the
requested/scheduled appointment. This field indicates to the application that
a resource is required for a different amount of time than the appointment's
overall duration. An unvalued duration indicates that the resource is required
from its start date/time offset (specified in the previous two fields) until
the end of the appointment. If no start date/time offset is specified, then
the resource is required for the full duration of the appointment.
This field must be a positive, non-zero number. A negative number or zero (0)
is nonsensical in the context of a duration.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code describing the units of time used
associated with AIP-9-Duration. This field should be valued according
to the recommendations made in Chapters 2 and 7. If this field is not valued,
the ISO base unit of seconds (code "s") will be assumed. Refer to
Chapter 7, Figures 7-6 through 7-9, for a list of ISO and ANSI+
unit codes.
Definition:
This field contains a code indicating whether the identified personnel
resource can be replaced with an equivalent substitute personnel resource by
the filler application. Refer to User-defined Table 0279 - Allow
substitution codes for suggested codes.
This field is conditionally required. It is required for all request messages.
It is optional for all unsolicited transactions, and for all query messages.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a code that describes the requested/scheduled
status of the personnel resource, from the point of view of the filler
application. Refer to User-defined Table 0278 - Filler status
codes for suggested codes.
This field is conditionally required. It should not be valued in any request
transactions from the placer application to the filler application. It is
required for all transactions from the filler application. It is optional for
query transactions.
This is a conditionally required field. Because the information contained in
this field is only appropriate in transactions originating from a filler
application, it is required for those messages. This includes all unsolicited
transactions originating from a filler application, as well as all response
messages originating from a filler application. This field is optional for all
transactions originating from placer, querying and auxiliary applications. It
is recommended that this field be left unvalued in transactions originating
from applications other than the filler application.
The
APR segment contains parameters and preference specifications used for
requesting appointments in the SRM message. It allows placer applications to
provide coded parameters and preference indicators to the filler application,
to help determine when a requested appointment should be scheduled. An APR
segment can be provided in conjunction with either the ARQ segment or any of
the service and resource segments (AIG, AIS, AIP, and AIL). If an APR segment
appears in conjunction with an ARQ segment, its parameters and preference
indicators pertain to the schedule request as a whole. If the APR segment
appears with any of the service and resource segments, then its parameters and
preferences apply only to the immediately preceding service or resource.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
80 |
SCV |
O |
Y |
0294 |
00908 |
Time Selection Criteria |
2 |
80 |
SCV |
O |
Y |
0294 |
00909 |
Resource Selection Criteria |
3 |
80 |
SCV |
O |
Y |
0294 |
00910 |
Location Selection Criteria |
4 |
5 |
NM |
O |
00911 |
Slot Spacing Criteria |
||
5 |
80 |
SCV |
O |
Y |
00912 |
Filler Override Criteria |
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate parameters and preferences to
the filler application regarding the selection of an appropriate time slot for
an appointment. The first component of this field is a code identifying the
parameter or preference being passed to the filler application. The second
component is the actual data value for that parameter.
For example, if a filler application allows preference parameters to be passed
to specify a preferred start time, a preferred end time, and preferred days of
the week for the appointment, it may define the following parameter class codes
and valid data sets.
Parameter Class |
Description: Valid Values |
|---|---|
Prefstart |
The preferred start time for the appointment request, service or resource. Any legal time specification in the format HHMM, using 24-hour clock notation |
Prefend |
The preferred end time for the appointment request, service or resource. Any legal time specification in the format HHMM, using 24-hour clock notation |
Mon |
An
indicator that Monday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Tue |
An
indicator that Tuesday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Wed |
An
indicator that Wednesday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Thu |
An
indicator that Thursday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Fri |
An
indicator that Friday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Sat |
An
indicator that Saturday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Sun |
An
indicator that Sunday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Given
this set of parameter class codes and valid value sets, a placer may indicate a
preferred start time of 8:00 AM on Monday, Wednesday or Friday by specifying
the following in APR-1-Time selection criteria:
...|PREFSTART^0800~MON^OK~WED^OK~FRI^OK~TUE^NO~THU^NO~SAT^NO~SUN^NO|...
The valid set of preferences should be determined by the placer and filler
applications during implementation of the interface.
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate parameters and preferences to
the filler application regarding the selection of an appropriate resource for
an appointment. The first component of this field is a code identifying the
parameter or preference being passed to the filler application. The second
component is the actual data value for that parameter.
Refer to Section <IP_ADDRESS>, "APR-1 Time selection criteria (SCV) 00908," for
an example illustrating how this mechanism works within an interface.
The valid set of preferences should be determined by the placer and filler
applications during implementation of the interface. Refer to
User-defined Table 0294 - Time selection criteria parameter class
codes for suggested examples.
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate parameters and preferences to
the filler application regarding the selection of an appropriate location for
the appointment. The first component of this field is a code identifying the
parameter or preference being passed to the filler application. The second
component is the actual data value for that parameter.
Refer to Section <IP_ADDRESS>, "APR-1 Time selection criteria (SCV) 00908," for
an example of how this mechanism works within an interface.
The valid set of preferences should be determined by the placer and filler
applications during implementation of the interface. Refer to
User-defined Table 0294 - Time selection criteria parameter class
codes for suggested examples.
Definition:
This field is used in queries returning lists of possible appointment slots,
or other lists of slots. If the filler application allows it, the querying
application may indicate the spacing of the slots returned to the querying
application, in relation to the requested start date/time in the ARQ segment.
The value in this field should be a positive integer, representing the number
of minutes between slot starting times that is returned in the query.
For example, if there is a request that an appointment with a duration of 1.5
hours be scheduled some time between 9:00 AM and 11:30 AM, and the
APR-4-Slot spacing criteria field contains a value of 15, then the list
of slots returned should read as follows:
9:00 - 10:30
9:15 - 10:45
9:30 - 11:00
9:45 - 11:15
10:00 - 11:30
Components:
<parameter class (IS)> ^ <parameter value (ST)>
Definition: This field is used to communicate override parameters to the
filler application. These override parameters allow placer applications to
override specific features of filler applications such as conflict checking.
It is assumed that the placer and filler applications will pass enough
information to determine whether the requestor is allowed to override such
features. This chapter does not provide any security or permission
information.
The first component of this field is a code identifying the parameter being
passed to the filler application. The second component is the actual data
value for that parameter.
Refer to Section <IP_ADDRESS>, "APR-1 Time selection criteria (SCV) 00908," for
an example illustrating how this mechanism works within an interface.
The valid set of parameters should be determined by the placer and filler
applications during implementation of the interface.
The
patient has been seen by his primary care physician, Dr. Jones, and requires
treatment by a cardiologist. The PCP requests a new appointment with Dr.
Jensen at the North Office. The patient has requested that the appointment be
scheduled for a time between January 2nd and January 10th, 1994, and between
8:00 AM and 5:00 PM. Dr. Jensen's office responds to the request with an
appointment at the North Office at 9:30 AM on January 6, 1994.
MSH|^~\&|JONES|EWHIN|SPOCARD|EWHIN|199401010800||SRM^S01|090849JONES|P|2.4|||AL|AL|||<cr>
ARQ|19940047^SCH001|||||047^Referral||NORMAL|||199401020800^199401101700||||0045^Jones^Harold^S^^^MD||||3372^Effenbach^Thomas||||<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
DG1|001|I9|786.5|CHEST PAINS|199401010730|W|||||||||||||<cr>
DG1|002|I9|412|OLD MYOCARDIAL
INFARCTION|199401010730|W|||||||||||||<cr>
RGS|001|<cr>
AIP|001|032^JENSEN^HELEN|002^CARDIOLOGIST|||||||NO|<cr>
AIL|001|^NORTH OFFICE|002^CLINIC|||||||YES|<cr>
MSH|^~\&|SPOCARD|EWHIN|JONES|EWHIN|199401010802||ACK|021244SPOCARD|P|2.4||||||<cr>
MSA|CA|090849JONES||||<cr>
MSH|^~\&|SPOCARD|EWHIN|JONES|EWHIN|199401010810||SRR^S01|0934849SPOCARD|P|2.4|||||||<cr>
MSA|AA|090849JONES||||<cr>
SCH|1994047^SCH001|1994567^SCH100|||||047^Referral|NORMAL|30|min|^^^199401060930^199401061000^^^^|0045^Jones^Harold^S^^^MD|555-4685|||087^Jensen^Helen^M^^^MD|555-9255||||BOOKED<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
RGS|001|<cr>
AIP|001|032^JENSEN^HELEN|002^CARDIOLOGIST|||||||NO|BOOKED<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>
MSH|^~\&|JONES|EWHIN|SPOCARD|EWHIN|199401010812||ACK|434532JONES|P|2.4||||||<cr>
MSA|CA|0934849SPOCARD||||<cr>
The
patient has asked Dr. Jensen to reschedule his January 6th appointment. Dr.
Jensen's scheduling application (the filler application) sends the PCP, Dr.
Jones, a notification that the original appointment has been rescheduled,
followed by a notification of the new appointment on January 9th at 1:00 PM.
MSH|^~\&|SPOCARD|EWHIN|JONES|EWHIN|199401040800||SIU^S13|021244SPOCARD|P|2.4|||AL|ER||<cr>
SCH|1994047^SCH001|1994567^SCH100|||||047^Referral|NORMAL|30|min|^^^199401091300^199401091330^^^^|0045^Jones^Harold^S^^^MD|555-4685|||087^Jensen^Helen^M^^^MD|555-9255||||BOOKED<cr>
NTE||The patient is going to be on vacation so cannot make previous
appointmentscheduled on January 6.<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
RGS|001|<cr>
AIP|001|032^JENSEN^HELEN|002^CARDIOLOGIST|||||||NO|BOOKED<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>
MSH|^~\&|JONES|EWHIN|SPOCARD|EWHIN|199401010802||ACK|035324JONES|P|2.4||||||<cr>
MSA|CA|021244SPOCARD||||<cr>
The
patient has been seen by his specialist, Dr. Smith, and requires treatment by a
physical therapist, Helen Morgan. Dr. Smith's office requests a one-hour
appointment each day for the next five days. Ms. Morgan's office responds to
the request with an appointment at 9:30 AM on June 20th through June 24th,
1994.
The patient has been seen by his specialist, Dr. Smith, and requires treatment
by a physical therapist, Helen Morgan. Dr. Smith's office requests a one-hour
appointment each day for the next five days. Ms. Morgan's office responds to
the request with an appointment at 9:30 AM on June 20th through June 24th,
1994.
MSH|^~\&|SMITH|EWHIN|MORGAN|EWHIN|199406190800||SRM^S01|03432SMITH|P|2.4|||AL|AL||<cr>
ARQ|19940347^SCH001|||||047^Referral||NORMAL|060|min|199406200930||Q1D|D5|00335^Smith^Harry^A^^^MD||||A3423^Jones^Fred||||<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport Highway^Mead^WA^99021||555-4685|||M||999-99-4413||||||||||<cr>
DG1|001|I9|833.00|Closed dislocation
wrist|199406190700|||||||||||||<cr>
RGS|001|<cr>
AIP|001|064^MORGAN^HELEN|097^PHYSICAL THERAPIST|||||||NO|<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|<cr>
MSH|^~\&|MORGAN|EWHIN|SMITH|EWHIN|199406190802||ACK|546644MORGAN|P|2.4||||||<cr>
MSA|CA|03432SMITH||||<cr>
MSH|^~\&|MORGAN|EWHIN|SMITH|EWHIN|199406190810||SRR^S01|0654544JONES|P|2.4||||||<cr>
MSA|AA|03432SMITH||||<cr>
SCH|1994037^SCH001|1994297^SCH100|||||047^Referral|NORMAL|60|min|^Q1D^D5^199406200930^199406240930^^^^|0335^Smith^Harry^A^^^MD||||064^Morgan^Helen|||||BOOKED<cr>
PID||4875439|484848||Peterson^Joseph^^Jerome^SR|Brown|19401121|M|Jayjay||N 1234
Newport
Highway^Mead^WA^99021||555-4685|||M|||999-99-4413|||||||||||<cr>
RGS|001|<cr>
AIP|001|064^MORGAN^HELEN|097^PHYSICAL THERAPIST|||||||NO|BOOKED<cr>
AIL|001|103^NORTH OFFICE|002^CLINIC|||||||NO|BOOKED<cr>
MSH|^~\&|SMITH|EWHIN|MORGAN|EWHIN|199406190800||ACK|045742SMITH|P|2.4||||||<cr>
MSA|CA|0654544JONES||||<cr>
This chapter implies that the relationship of the repeating resource and service specific segments has a logical "and" relationship. In other words, if more than one AIP segment is sent in a transaction, it is logical to assume that both specified personnel resources are required for the appointment. Currently, there is no way to specify an "or" relationship between the resource and service segments. It is possible to specify a resource type and achieve a similar (but not equivalent) effect. See Section 10.9.1, "Logical relationship of resource and service segments" for a further discussion.
When
implementing the transactions defined in this chapter with multiple placer
applications, one must consider the implications of a situation when more than
one placer application asks to book, hold, lock, or otherwise reserve the same
slot or set of slots on a particular schedule.
This chapter makes no attempt to define attribute ownership (e.g., based on
application roles). Ownership is the right to create or update attribute
content. If two or more applications attempt simultaneously to update the same
attribute(s), deadly update collisions may occur, causing data corruption,
unless robust mechanisms for bidding and locking such attributes are in place
between applications. This chapter makes no attempt to address data ownership
issues or to define attribute bidding and locking mechanisms.
This chapter assumes that the placer and filler applications have put such
mechanisms into place, therefore resolving any contention or collision issues
at the application level. Further, if such mechanisms have not been
implemented by the applications, then this chapter assumes that procedural
solutions have been implemented by the healthcare provider organization to
resolve contention and collision issues.
An
implementor of a ballot draft specification of this chapter realized the need
to logically AND and OR multiple resources for a single appointment. For
example, they wished to specify the following condition:
((Resource-1 and Resource-2) or (Resource-3 and (Resource-4 or Resource-5)))
The current message structure for any kind of transaction does not address the
need for any of the service or resource detail segments (AIS, AIG, AIL, or
AIP).
They have proposed an extension to the Standard that would allow Lisp-like
logical syntax within messages such as the Schedule Request message. This
syntax makes use of a BEGIN and an END segment to logically group segments, and
an AND and an OR segment to logically connect segments. To achieve a request
as in the example above, the implementation of these logical grouping and
connecting segments would read as follows:
BEGIN|<cr>
BEGIN|<cr>
AIG|Resource-1...<cr>
AIG|Resource-2...<cr>
AND|<cr>
END|<cr>
BEGIN|<cr>
AIG|Resource-3...<cr>
BEGIN|<cr>
AIG|Resource-4...<cr>
AIG|Resource-5...<cr>
OR|<cr>
END|<cr>
AND|<cr>
END|<cr>
OR|<cr>
END|<cr>
This would translate to:
((Resource-1 Resource-2 AND) (Resource-3 (Resource-4 Resource-5 OR) AND)
OR)
This is the RPN or Lisp-like logical notation for the example in the first
paragraph. This syntax could encompass and support groupings of several
different resource and service types.
This proposal was presented to the Control/Query Technical Committee. Their
initial response was that this proposal is outside of the scope of
Control/Query for the current Standard 2.3 ballot and response cycle. If
necessary, this proposal will be resubmitted to the Control/Query Technical
Committee by the implementing organization for future versions of the Standard.
None.
HL7 trigger events are not strictly limited to this definition; however, most trigger events do define state transitions.


{% extends '_layouts/layout_2-3_no_title_block.html' %} {% block page_title %} Stomach ache symptoms and conditions - NHS.UK {% endblock %} {% block pageTitle %} Book an appointment with a GP {% endblock %} {% block pageIntro %} {% endblock %} {% block content %}
To book an appointment with your GP online you must already be registered with a GP surgery.
You will need to tell us:
If you don’t have a GP, you can find and register with a GP.
{% endblock %} {% block emergencyContent %} {% endblock%} {% block mutedCallout%} {% endblock%} {% block body_after %} {% endblock %}


Lightweight javascript browser library to lazy load images as they enter viewport. Has no big dependencies and weighs less than 2KB.
Average website usually comes with lot of images that are downloaded well before users actually have a chance to see them. Lazy loading of images can help with your performance budget. Late images is a small library with simple api. It does not rely on jQuery but comes with convenient adapter.
Next few images should fade in as you scroll down:
Late images come with jQuery adapter included - to lazy load this images we had to write was following code.
$('.lateImage').lateImages();
Html was structured like so:
Image fade in was achieved via simple css animation that was trigged when new class was applied to element.
Same result in plain javascript (without jQuery) is achieved like so:
var elements = Array.prototype.slice.call(
document.getElementsByClassName('lateImage')
);
elements.forEach(function(element) {
new LateImage(element);
});
Library options are passed via second parameter to constructor. If we want to start loading images 100 pixels before user scroll position we setup call like so:
// when used via jQuery plugin facade
$('.lateImage').lateImages({threshold: 100});
// plain js
new LateImage(element, {threshold: 100});
Image lazy load can be stopped at any time by obtaining late image instance and calling destroy method on it.
// get instance via jQuery
var lateImage = $('.lateImage').lateImages().data('lateImage');
// or
var lateImage = new LateImage(element);
// sometime later
lateImage.destroy();
Every late image instance will work with following defaults merged with options you passed to constructor.
LateImage.defaults = {
srcAttribute: 'data-src',
altAttribute: 'data-alt',
doneCallback: null,
failCallback: null,
threshold: 0,
loadingClass: 'lateImageLoading',
loadedClass: 'lateImageLoaded',
errorClass: 'lateImageError',
enableViewportCheck: true
};
Late images is packaged as UMD library so you can use it in CommonJS and AMD environment or with browser globals.
// install via npm
npm install late-images --save
// if you use bundler
var LateImage = require('late-images');
// or just using browser globals
var LateImage = window.LateImage;
For browser usage browse dist folder - if working with build tools go with src folder. Download library files from github repo, get them via bower (bower install lateImages) or via npm (npm install late-images)


Syllabus
Principles of object-oriented programming: Object-Oriented Programming Paradigm, Basic Concepts of Object- Oriented Programming, Benefits of OOPs, Object-Oriented Languages, Applications of OOP, C++ Statements, Class, Structure of C++ Program, structure verses objects oriented. Introduction, Tokens, Keywords, Identifiers Basic Data types, Constants, Declaration of Variables Scope Resolution Operator, Type Casting.


A gallery of examples showcasing complications that arise in mass digitisations of books
Pages where OCR engines detect "texts" that do not actually exist
Examples where OCR engines arbitrarily introduce paragraph breaks in text
Texts in page margins like header, page number, footer, footnotes, etc.
Complex layouts such as tables, double or triple column layouts, etc.
Structured lists with and without numbers/bullet points
Quoted texts either in blocks or inline, verses, etc.
Text recognised by the OCR engine from regions of page containing non-textual content like images, plots, etc.
Text in more than one language, either in separate paragraphs or interspersed within the text.


This package contains the static resource loader, and the static resources themselves for the profiler UI.


57 children receive intestinal infections at Smiltene’s secondary school
by LETAAccording to deputy principal of Secondary School in Smiltene Inese Raiskuma, 57 children have received virus-induced intestinal infections.
She said that last week children had experienced vomiting and diarrhoea at home in the evening. This condition remained on the next day at school. This prompted the school to call in epidemiologists and cancel all celebrations associated with the national holiday.
«Samples of food products and samples of different surfaces were taken. We are waiting for answers. Additional disinfection was performed over the weekends. Parents have been advised on measures to the performed for affected children,» said Raiskuma.
Smiltene Secondary School’s principal Ilze Vergina reports that all infected children may return to school only once their family doctor declares they are healthy.
There are 314 children, including 185 primary school children and 129 pre-school children, study at this school.
Disease Prevention and Control Centre (SPKC) public relations head Ilze Arāja has confirmed the centre is aware of the incident in Smiltene. Results of laboratory tests will be reported within one day’s time.
Food and Veterinary Service expanded control measures following the incident in Sigulda, when intestinal infections were found in multiple kindergartens, where infected poultry produced by Polish Cebrob S.A. was used to prepare meals.
Salmonella enteritidis bacteria were found in samples taken from poultry served by SIA Gaļsaimnieks, as well as SIA EVBL.
Read also: Monitoring reveals 46 of Sigulda’s residents suffer from intestinal infections
As previously reported, while performing increased control of intestinal infections in Sigulda, SPKC also uncovered cases of salmonella infections. Children who went to two kindergartens in Sigulda (Ieviņa and Tornīši) were infected with salmonella.
At the beginning of October, stomach infections were found for approximately 50 employees of Stockman supermarket. Catering services for Stockman employees during Trakajās dienas were provided by SIA Baltic Restaurants Latvia.


Fullname
Street
House
E-Mail
Payment options Credit Card Debit Card Paypal Swish Male Female Non-binary Undisclosed


#import <ESFindFriendsViewController.h>
Interface of the ESFindFriendsViewController, used to find new friends and other users.
| - (NSIndexPath *) _indexPathForPaginationCell |
|
|
|
Fixing a bug in the Parse SDK when calling the LoadMoreCell in a section based tableview.
| - (void) backButtonAction: |
|
(id) |
sender |
|
Dismissing the viewcontroller.
| - (void) filterResults: |
|
(NSString *) |
searchTerm |
|
Filtering the results: we search for users that contain the searchTerm
| - (void) inviteFriendsButtonAction: |
|
(id) |
sender |
|
Invite friends to join the social network.
| - (void) presentMailComposeViewController: |
|
(NSString *) |
recipient |
|
Presenting a mail composer with the recipient's email as prefilled address.
- Parameters
-
| recipient | recipient's email |
| - (void) presentMessageComposeViewController: |
|
(NSString *) |
recipient |
|
Presenting a message composer with the recipient's number.
- Parameters
-
| recipient | the recipient's number |
Toggle the followstatus in the friendcell from following to unfollowing and vice versa.
- Parameters
-
| cell | the cell containing the respective follow button |
| - (ESFindFriendsFollowStatus) followStatus |
|
readwritenonatomicassign |
Followstatus between the current user and the respective users in the different cells.
Header of the UITableView
| - (NSMutableDictionary*) outstandingCountQueries |
|
readwritenonatomicstrong |
Mutable dictionary of outstanding photo count queries.
| - (NSMutableDictionary*) outstandingFollowQueries |
|
readwritenonatomicstrong |
Mutable dictionary of follower queries still outstanding.
| - (UISearchBar*) searchBar |
|
readwritenonatomicstrong |
The searchbar that is displayed at the top of the tableview.
| - (UISearchDisplayController*) searchController |
|
readwritenonatomicstrong |
Search controller used to display the filtered result of users.
PFQuery gathering the users based on the search keys.
| - (NSMutableArray*) searchResults |
|
readwritenonatomicstrong |
The results of the search query.
| - (NSString*) selectedEmailAddress |
|
readwritenonatomicstrong |
If the user wants to invite another user per mail, we store the recipient's email here.
The documentation for this class was generated from the following files:


{% extends "easydmp/plan/base.html" %} {% load crispy_forms_tags %} {% block content %}
Locking a plan means setting it to read only. It will not be editable anymore and you will have to create a new version to make it editable again.
By clicking "Yes" below the plan will be locked.
Do you want to lock this plan now?
{% crispy form %}


--- layout: documentation title: NeighborSolicitationOptionsType ---
Neighbor Solicitation messages include zero or more options, some of which may appear multiple times in the same message.
| Field Name | Type | Description |
|---|---|---|
| Src_Link_Addr0..1 | NDPLinkAddrType |
Src Link Addr characterizes the Source Link-Layer Address option. |


Payment Options:
Google Pay
PayTM
NEFT/RTGS/IMPS transfer
Name
Vikas Keyal
Bank
Axis Bank
Account Number (SB)
911010050556052
Branch
MG Road, Bangalore
IFSC
UTIB0000009


Question: how do I display MQTT data in EmonCMS? Can I test this on emoncms.org or only if I locally host and install the mqtt module? Is there any further information on MQTT + EmonCMS which I have missed?
Background: I'm starting out building a energy monitor with Arduino -> MQTT -> EmonCMS. I'd like to use EmonCMS to subscribe to a MQTT feed and display the data. It's very similiar to OEM, tailored to my needs.
Progress so far: I've succesfully displayed simple JSON/HTTP data on my emoncms.org account. I can't find any 'subscribe to MQTT' input. I've looked at https://github.com/elyobelyob/mqtt repos but can't find usage / getting started section.
Thanks, Brett.
Re: EMonCMS and MQTT
Hello Brett, best bet is to ask Nick Boyle (elyob) who wrote the MQTT module. I think its tailored for talking to a current cost device at the moment.
I have been playing about a bit with MQTT recently and agree that it would be great to make fully integrated use of it in emoncms.
Re: EMonCMS and MQTT
The only way I am aware of is to write a small app to subscribe to the topic(s) you want, process the feed and submit to EmonCMS via a JSON query ...
At least that is the way I have done it and been running for over 6 months with no problems (aside from me playing with other parts of the system!) ...
Have a look at http://www.harwoodfamily.id.au/index.php/environmental-monitoring/emoncms ... it is pulling information from up to 7 very different types of sensors including current cost, custom open energy monitor (3 phase), gas usage (currently offline due to me working on PoE Arduino components), pool monitoring system - all via MQTT with no direct device to EmonCMS communication.
I am also close to finishing rewriting all my components, aside from devices running Arduino, in C#.Net and using Mono/Xamarin - including some web servers not currently published, Android code (MyCB), and a number of other bits. All previous stuff was in perl, but I couldnt get a reliable code base working with the required multi task and error handling.
Re: EMonCMS and MQTT
Thanks guys.
I checked the MQTT module and it appears to do just that: converts from MQTT (from device) to JSON (to server). As you mentioned is it hardcoded to a specific device. It could be extended and adapted. Seems like you have done a very similar thing, Mal.
I could go this route (ie. write/adapt emonCMS to use MQTT -> JSON), but it seems like re-inventing the wheel (?).
OpenHAB appears to support MQTT already. I see that EMonCMS is perhaps more specific (to energy monitoring), PHP instead of Java. I'm considering using your hardware and arduino side, adapting some of it to MQTT and then using OpenHAB to view (instead of EmonCMS).
Trystan (or others), can you comment on OpenHAB vs EmonCMS for this kind of application?
(Ps Great site, Mal!)
Re: EMonCMS and MQTT
Brett, I just had a look at OpenHAB .. looks like it might be worth installing and having a play with ...
OpenCMS is quite different to OpenHAB .. OpenCMS is really only for capturing and displaying information (as far as I know) ... there is little functionality to control things (although there are some plug-ins starting to move this way lately).
It really depends on what you want to do and achieve ... and since you are down the path of MQTT, you can have it all ;)
The OEM devices do not have standard ability to 'speak' MQTT .. depending on what you want to do with the devices, it is not particularly hard to add the MQTT library and get results ... although if you try to do too much, you start running out of resources in an Arduino and need to look at other ways of skinning that pesky cat :) If you fill out the enquiry form on my web site, Im sure I can find some of my original production code I can send you that did the basic energy monitoring and publishing to a MQTT broker .. probably around 10 months old, so probably some updated libraries and functions, but would get you started.
I had a look at the MQTT page on OpenHAB .. (https://github.com/openhab/openhab/wiki/MQTT-Binding) ... this is the sort of configuration my "MQTTtoEMONCMS" application takes, but in the form of an XML configuration file .. you can set the broker details and subscription topics as well as EmonCMS server details. It is probably a bit hard coded toward my MQTT naming convention at the moment, but could be generalised to suit ... As I mentioned above, it is written as a C# application and (unfortunately for some) requires Mono to run on *nix devices ... I have it runing on RaspPi's with no problems as well as a few other low end servers in my test environment (dont have it running on any Windows boxes!).
Re: EMonCMS and MQTT
I have several monitoring items in my house using mqtt. I've been playing with the mqtt module, but cannot seem to get it to work. I'm using a local instance of emoncms. Anyone been able to get this to work?
Re: EMonCMS and MQTT
Have you thought of using nodered? http://nodered.org
Theres an emoncms node and its simple to link it up to a MQTT input node.
Re: EMonCMS and MQTT
I'm also using node-red, and logging weather data to emoncms. Works great!
Paul
Re: EMonCMS and MQTT
Thanks! I'll have a look. I was hoping that I could do it with just the mqtt module, but if this works..
Re: EMonCMS and MQTT
Has there been any further developments to get a local emoncms [with the mqtt module] subscribing to mqtt messages and having the data as feed/input data into emoncms? I have a test local emoncms installed with the mqtt module, an rsmb server [broker for MQTT and MQTT-SN]. When I configure the mqtt module in emoncms Im expecting the emoncms mqtt module to subscribe on the configured topic to the broker.
This does not happen. There is also little/no documentation on this module.
Btw, I have hacked emontx units [that dramatic - its just other sketches with my mqttsn library and emon lib] that have mqttsn library installed so they publish mqtt-sn messages over RFM12B radio.
I use OpenHAB as my main mqtt client where I send my emon data over mqttsn. I have been doing the energy analytics in OpenHAB but its not designed for that. So I want to have emoncms subscribe to the mqtt feeds, do the analytics and then use the grpahic and dashboards inside openHAB for a one stop shop for home automation and energy monitoring. <rant off>
Thanks
Re: EMonCMS and MQTT
I have achieved this by using mqttwarn (Google for a link, sorry on my phone currently) which subscribes to the topic and transforms the payload into a HTTP POST with a JSON payload and sends to EmonCMS.
Works well and I will be happy to share my code once I return home from holidays if you are interested.
I would be keen to see your mqttsn library for Arduino if possible. I am using PubSubClient currently. I am also a heavy openHAB user so it seems like our use cases overlap quite a bit!
Re: EMonCMS and MQTT
Thanks Summerboy for the offer on the mqttwarn code share which I will take you up on. Nick Boyle has also emailed me a python script to do this, but mqttwarn is more configurable and better documented. It also seems very similar to Openhab [which makes me think that this can probably be done in Openhab as well using the mqtt and http binding and some rules].
Drop me an email, lets see how we can synergise our use cases....and not re-invent any wheels.
Ideally I think there should be a standard Internet of Things protocol/interface in and out of Emoncms, and in my opinion MQTT is it. And it would have been ideal if this was integrated into the same application as module so that I dont need to run another standalone script/application in my quest for home automation.
Sure no problem to seeing/getting the Mqttsn lib code. I havent uploaded the code to GIthub yet as I want to create a few more example sketches and document the readme.md and wiki quite nicely first.
https://github.com/jasonhector/Mqttsn-Mote-Library
Re: EMonCMS and MQTT
Yep - the reason it works so well with openHAB is that I helped write mqttwarn, with the specific thought of using it for openHAB notifications (which I am also heavily involved with). Since then I have been moving as much of my home automation logic/networking to MQTT as possible.
To configure mqttwarn to transform energy reports published to MQTT topics --> EmonCMS JSON packages I am using the HTTP target/service. As you can see it is pretty simple and assumes there is a simple float payload in the MQTT message. It is very easy to add more feeds/nodes.
This could be done using openHAB - with the MQTT/HTTP bindings as you mentioned - but I think this is cleaner since openHAB is completely out of the loop in this case. I do have the MQTT binding in openHAB configured to monitor the various feeds however and display values in my sitemap etc. I have yet to write any rules using them however (still early days).
MQTTWARN.INI
[config:http]
timeout = 5
targets = {
'emoncms' : [ 'get', 'http://<host>/emoncms/input/post.json', { 'node': '{node}', 'json': '{json}', 'apikey': '<apikey>' }, None ]
}
[emontx-grid]
topic = /emontx/grid
targets = http:emoncms
alldata = emontxgrid_to_emoncms()
[emontx-solar]
topic = /emontx/solar
targets = http:emoncms
alldata = emontxsolar_to_emoncms()
FUNCTIONS.PY
# EmonTX feeds
def emontxgrid_to_emoncms(topic, data, srv):
return to_emoncms(data, 2, 'grid')
def emontxsolar_to_emoncms(topic, data, srv):
return to_emoncms(data, 2, 'solar')
# custom function to format a data feed for posting to EmonCMS
def to_emoncms(data, node, name):
if type(data) == dict:
return { 'node' : node, 'json' : json.dumps({name : float(data['payload'])}) }
return None
Re: EMonCMS and MQTT
thanks Sumnerboy! Got it working. :)
Now I just need to get the dashboard/ graphs and/or "processes" emoncms data out of emoncms into openhab. Any ideas?
[This will allow me to do things like load curtailment - switching electircal appliances off when the load is high/ energy units running low]
Re: EMonCMS and MQTT
Not really sorry - my plan was to montior the raw MQTT feeds in openHAB as well and do 'processing' logic in the openHAB rules in order to get the necessary data for switching loads etc.
Keep us posted with how you get on - will be very interested to see how you get on.
I have suggested we use mqttwarn for EmonCMS notifications/events in another thread. By having a simple event/notify module in EmonCMS which just posts to an MQTT topic, then all the message delivery can be handled by mqttwarn and means the EmonCMS module can be pretty simple and not need continuous extending as different 'targets' are requested by users.
What do you think of mqttwarn?
Re: EMonCMS and MQTT
I really like tools that are simple to configure and give lots of flexibility [read interfaces] - and mqttwarn is exactly this.
I bring the habmin [web service addon to openhab] charts into my openhab sitemaps and display the charts there. So my idea is something similar for emoncms charts using openhabs webview.
I would be great to have mqttwarn as an emoncms module for both inputs, as well as outputs, ie. take any mysql data and map to mqtt messages to be published. I dont really know the event/notify mechanism in Emoncms, but Im guessing it binary state notifications on exceeding threashholds.
Would Mqttwarn be able to run queries against the emoncms mysql for "processed"/analytical data and pub that via mqtt?
Re: EMonCMS and MQTT
Not really - mqttwarn is designed soley to monitor MQTT topics and react to them. So it is very much MQTT <in> --> anything <out>. So in order to get mqttwarn to handle EmonCMS outputs we would need to have EmonCMS publishing to MQTT topics (as you mentioned).
But yes, mqttwarn is a fantastic little tool. The key is to get as much data using MQTT as possible - then you can do all sorts of notifications and transformations!
Re: EMonCMS and MQTT
If anyone is interested I have just added a new service/target to mqttwarn specifically for EmonCMS.
https://github.com/jpmens/mqttwarn/blob/master/README.md#emoncms
This should make it nice and easy for those using MQTT to get their feeds forwarded to an instance of EmonCMS. Just a matter of plugging in your server URL, apikey and the node and name for each feed.
Re: EMonCMS and MQTT
Thanks for this update to mqttwarn. Makes life just that little bit easier.... :)
Mqttwarn definately gets my vote for being the interface between mqtt and emoncms.
Re: EMonCMS and MQTT
Glad you are finding it so useful. And glad someone other than me is using the emoncms target ;).
Re: EMonCMS and MQTT
I just found this after I was about to post a question about MQTT and Emoncms.
 I was thinking of having one of these Arduino sensors monitor current, and report the current usage using the emon Arduino library, and have it post this data via ethernet via MQTT, and use Emoncms to pick up this MQTT energy usage data.
Is that basically the setup that you have, @sumnerboy?
Re: EMonCMS and MQTT
I know the question wasnt directed at me, but my setup is exactly that. I have an arduino mega with enj Ethernet module. I run emonlib and nanodeMqtt libs, and all calVI from emonlib I put inside mqtt payloads and send to my RSMB MQTT broker. U ise mqttwarn that translates the mqtt into json for emoncms. this works really nicely.
I also use Openhab that also picks up the energy readings from the arduino mega.
I could share my sketch and mqttwarn config with you if you want?
Then also, I am busy extending the emoncms event module to include mqtt as an action so that any emoncms feed items can also be sent to a MQTT broker to be used elsewhere - in my case to Openhab again.
Are you familiar with MQTT-SN? I have managed to get MQTT-SN messages going over RFM12B radio to my MQTT broker [only RSMB broker can handle MQTT-SN currently]. so I use emontx V2 units and jeenodes that control my lights and plugs using MQTT-SN over RFM12B radios. I use RFM12PI with a custom sketch for the interface from the broker to the radio network
Below is my architecture:
Jason
Re: EMonCMS and MQTT
Could someone explain me how to use it mqttwarn and emoncms?
my config:
[defaults]
hostname = '<IP_ADDRESS>'
port = 1883
; name the service providers you will be using.
launch = file, log, emoncms
[config:file]
append_newline = True
targets = {
'mylog' : ['/tmp/mqtt.log']
}
[config:log]
targets = {
'info' : [ 'info' ]
}
[config:emoncms]
url = <http://<IP_ADDRESS>/emoncms>
apikey = <2a011fe19993818550f93056c6113b26>
timeout = 5
targets = {
'usage' : [ 2, 'usage' ], # [ <nodeid>, <name> ]
'solar' : [ 2, 'solar' ]
}
[/Home/Parter/Garaz/device/Analizator sieci/Faza 3/Irms]
targets = file:mylog, log:info, emoncms:usage
and logfile:
2015-02-12 15:50:56,097 DEBUG [mqttwarn] Service file loaded
2015-02-12 15:50:56,121 DEBUG [mqttwarn] Service emoncms loaded
2015-02-12 15:50:56,122 ERROR [mqttwarn] Service `emoncms' has no config section: invalid syntax (<unknown>, line 1)
2015-02-12 15:54:39,118 INFO [mqttwarn] Starting mqttwarn
2015-02-12 15:54:39,118 INFO [mqttwarn] INFO MODE
2015-02-12 15:54:39,118 DEBUG [mqttwarn] DEBUG MODE
2015-02-12 15:54:39,121 DEBUG [mqttwarn] Service file loaded
2015-02-12 15:54:39,122 DEBUG [mqttwarn] Service log loaded
2015-02-12 15:54:39,146 DEBUG [mqttwarn] Service emoncms loaded
2015-02-12 15:54:39,147 ERROR [mqttwarn] Service `emoncms' has no config section: invalid syntax (<unknown>, line 1)
[Multiple duplicates of this have been deleted. If your post does not appear, read the message that tells you that your post has been held for moderation, and be patient.]
Re: EMonCMS and MQTT
I would imagine you have some sort of funny whitespace in your INI file somewhere. Python is very fussy when it comes to rogue whitespace...
Re: EMonCMS and MQTT
I tried to change the configuration but without success.
Re: EMonCMS and MQTT
Hi all
I've read through this thread and thought I'd use the emoncms function designed by sumnerboy for mqtt. I can see the config element detailed on https://github.com/jpmens/mqttwarn/wiki/emoncms but nothing about the actual items.
My config is as follows:
[config:emoncms]
url = http://localhost/emoncms
apikey = apikey
timeout = 5
targets = {
'temp' : [1, 'temp' ], # [ <nodeid>, <name> ]
My item is then configured as follows:
[Loft/Temp/]
targets = emoncms:temp
I cannot seem to make this work either. Is the back-end conversion actually working? Emoncms shows no nodes created.
Very grateful for any assistance / examples of other emoncms configs.
Thank you.
Re: EMonCMS and MQTT
Are you definitely getting values published to Loft/Temp on your MQTT broker?
Also - I presume you have entered your proper API key?
Re: EMonCMS and MQTT
Yes, MQTT messages are definately being published. I can read them on MQTT.fx and/or MQTTlens without any issue.
The API key I'm using is the read/write key.
Re: EMonCMS and MQTT
Got it working now - typos.
Re: EMonCMS and MQTT
Here is my mqttwarn config. Note the quotes around the URL/API key. Is your mqttwarn definitely running on the same machine as your emoncms?
See if this helps with your config - it definitely works - I have been using this for over a year now!
Check the mqttwarn logs to see if there is anything useful in there?


It appears you are using a browser version which is not supported by RethinkRAW.
You should restart RethinkRAW after upgrading your browser.


Niagara Falls International Marathon
Buffalo NY/USA => Niagara Falls CAN
Website: niagarafallsmarathon.com
Race Winners
(34 runnings)
2:52:17.8 2:56:10.8 2:46:40.9 2:55:26.6 28 Oct
2007
2:33:12.5
3:02:36.3
22 Oct
2006
2:18:12.9
2:43:16.1
23 Oct
2005
2:21:46.4
2:46:41.7
24 Oct
2004
2:22:22.0
2:37:08.6
26 Oct
2003
2:23:13.8
2:54:25.5
27 Oct
2002
2:27:53.5
2:50:18.3
21 Oct
2001
2:24:28.5
2:46:42.4
22 Oct
2000
2:21:45.2
2:38:29.8
24 Oct
1999
2:29:13
2:50:48
25 Oct
1998
2:39:59
3:06:31
26 Oct
1997
2:37:53
2:55:41
1987-1996
---
---
20 Sep
1986
2:17:35
2:50:49
21 Sep
1985
2:30:29
3:07:20
13 Oct
1984
2:19:40
2:55:18
15 Oct
1983
2:21:58
2:56:38
16 Oct
1982
2:22:18
2:58:49
17 Oct
1981
2:18:50
2:40:48
18 Oct
1980
2:17:10
2:54:57
13 Oct
1979
2:17:30.1 2:52:18
21 Oct
1978
2:17:21
2:57:01
22 Oct
1977
2:20:31
3:00:11
16 Oct
1976
2:24:01
2:58:49
25 Oct
1975
2:23:16
3:16:18
26 Oct
1974
2:22:53
2:58:16
Notes: The inaugural year was 1974. This race was known as the Skylon International Marathon for 1974-1982, the
Buffalo Niagara Falls International Marathon for 1983-1986, the Niagara Falls Marathon in 1997
and the Casino Niagara International Marathon for 1998-2008. In the 1985
race, runners were led off course early, several routes were used by runners to get back on course plus other problems,
making times/places rather unreliable.
15 Oct
2017
2:51:07
Stuart Galloway (ON/CAN)
3:29:14
Al Tufano (COL)
30 Oct
2016
2:30:32
David-Savard Gagnon (PQ/CAN)
3:17:28
Lindsay Moreau (ON/CAN)
25 Oct
2015
2:30:55
Taylor Kraayenbrink (ON/CAN)
2:53:11
Paulina Golic (POL)
26 Oct
2014
2:27:58.0
Lucas McAneney-2
2:58:02.8
Stephanie Strittmatter (PA/USA)
27 Oct
2013
2:22:41.6
Lucas McAneney (ON/CAN)
2:48:54.1
Paula WIltse-2
21 Oct
2012
2:26:04.1
Bernard Arasa Onsare (KEN)
2:51:57.5
Paula WIltse (ON/CAN)
23 Oct
2011
2:28:47.7
Brendan Kenny (ON/CAN)
Meggan Franks (CAN)
24 Oct
2010
2:27:48.1
Steve Bohan (CAN)
Jill Gamble (ON/CAN)
25 Oct
2009
2:27:53.9
Andrew Smith (ON/CAN)
Tara Quinn (ON/CAN)
26 Oct
2008
2:27:33.2
Matt Loiselle (ON/CAN)
Elizabeth Primrose (ON/CAN)
Thomas Omwenga (KEN)
Louise Voghel (PQ/CAN)
Simon Njoroge Kariuki (KEN)
Elena Rozhko (UKR)
Matthew McInnes (ON/CAN)
Nicole Stevenson-2
Moses Cheseret (KEN)
Nicole Stevenson (ON/CAN)
Wilson Komen
Kipruto (KEN)
Leslie Carson (ON/CAN)
Badza Shingirai (ZIM)
Cindy Keeler (FL/USA)
Jean-Paul Niyonsaba (BDI)
Danuta Bartosek-2
Joseph Maina
Ngunjiri (KEN)
Danuta Bartosek (ON/CAN)
Smartex Tambala (MAW)
Eriko Asai (JPN)
Brent Forgesson (BER)
Glenda Morris (CAN)
Glen Marttila (CAN)
Katie Dosser (CAN)
not held
not held
Kazuya Nishimoto (JPN)
Maria Grazia Navacchia (ITA)
Mark Coleman (NY/USA)
Charlene MacDonald (ON/CAN)
Rick Mannen (ON/CAN)
Deborah Dye (OH/USA)
Bernie Prabucki (NY/USA)
Vicki Scanlon (ON/CAN)
Terry Stanley-2
Heather Clemenson (ON/CAN)
Terry Stanley (PA/USA)
Nancy Mieszczak (NY/USA)
Peter Pfitzinger (MA/USA)
Leslie Watson (SCO)
David Smith (CA/USA)
Virginia Kraft (USA)
Carl Hatfield (WV/USA)
Jacqueline Gareau (PQ/CAN)
Richard Hughson (CAN)
Susan Kahler (NY/USA)
Bill Stewart (MI/USA)
Patricia Hall
Marty Sudzina (PA/USA)
Eleanor Thomas (CAN)
Russell Pate (SC/USA)
Ellen Turkel (USA)
Most Wins
(1974-date)
Men
2
2
Terry Stanley (PA/USA)
1981-82
Lucas McAneney (ON/CAN)
2013-14
Women
Danuta Bartosek (ON/CAN)
2000-01
.
Nicole Stevenson (ON/CAN)
2004-05
Prize Money
(ADR qualified runners)
Year Men Women Total 2016 $1,050 $935 $1,985 2015 1,595 1,935 3,530 2014 1,870 1,425 3,295 2013 3,440 3,920 7,360 2012 4,935 4,180 9,115 2011 3,625 4,370 7,995 2010 4,770 4,380 9,150 2009 3,805 4,275 8,080 2008 3,830 2,730 6,560 2007 3,390 3,910 7,300 2006 10,665 9,995 20,660 2005 9,685 10,105 19,790 2004 8,100 17,215 25,315 .... 2002 6,615 5,710 12,325 2001 n/a n/a n/a 2000 2,630 2,570 5,200 Sums $70,005 $77,655 $147,660
Race Time Bias (sec/km)
Year Men Women 2000 +1.1 n/c .... 1978 +0.3 n/c Avgs +0.7 n/c
Competitive Level (1990-date)
Year Men Women 2006 47 n/c 2005 69 n/c
Quality Performances
Men <2:18 4 <2:19 7 <2:20 10 Women <2:38 1 <2:40 2 <2:42 4 <2:44 5 <2:46 5 <2:48 8 <2:50 12
Last Updated on 16 Oct 2017
Contributors: Don Mitchell, Maurice Wilson (25), Franco Civai (1), Juraj Gasparovic (1)


MAMAMOO rock orange and black looks in 2nd concept photo for 'reality in BLACK' comeback
by danisurstMAMAMOO is getting closer to their latest comeback!
On November 10 KST, the group's agency RBW Entertainment dropped the second group concept teaser for their first full-length album 'reality in BLACK.' In the image, the group is wearing coordinated orange and black, rounded out by chic gold accents. All four members give the camera a confident stare, only adding to MAMAMOO's trademark 'girl crush' aura.
Meanwhile, 'reality in BLACK,' featuring title track "1st Universe," is set for release on November 14 at 6 PM KST.
Check out the latest concept image below!


|
C++ Actor Framework 0.19
|
Deserializes an inspectable object from a JSON-formatted string. More...
#include <json_reader.hpp>
Public Types | |
| enum class | position { value , object , null , key , sequence , members , past_the_end , invalid } |
| Denotes the type at the current position. | |
| using | super = deserializer |
| using | json_key = std::string_view |
| using | value_type = std::variant< const detail::json::value *, const detail::json::object *, detail::json::null_t, json_key, sequence, members > |
| using | stack_allocator = detail::monotonic_buffer_resource::allocator< value_type > |
| using | stack_type = std::vector< value_type, stack_allocator > |
| Public Types inherited from caf::deserializer | |
| using | super = load_inspector_base< deserializer > |
Public Member Functions | |
| json_reader (actor_system &sys) | |
| json_reader (execution_unit *ctx) | |
| json_reader (const json_reader &)=delete | |
| json_reader & | operator= (const json_reader &)=delete |
| std::string_view | field_type_suffix () const noexcept |
| Returns the suffix for generating type annotation fields for variant fields. | |
| void | field_type_suffix (std::string_view suffix) noexcept |
| Configures whether the writer omits empty fields. | |
| const type_id_mapper * | mapper () const noexcept |
| Returns the type ID mapper used by the writer. | |
| void | mapper (const type_id_mapper *ptr) noexcept |
| Changes the type ID mapper for the writer. | |
| bool | load (std::string_view json_text) |
Parses json_text into an internal representation. | |
| bool | load_file (const char *path) |
Parses the content of the file under the given path . | |
| bool | load_file (const std::string &path) |
Parses the content of the file under the given path . | |
| void | revert () |
Reverts the state of the reader back to where it was after calling load . | |
| void | reset () |
| Removes any loaded JSON data and reclaims memory resources. | |
| bool | fetch_next_object_type (type_id_t &type) override |
| Reads run-time-type information for the next object if available. | |
| bool | fetch_next_object_name (std::string_view &type_name) override |
| Reads run-time-type information for the next object if available. | |
| bool | begin_object (type_id_t type, std::string_view name) override |
| Begins processing of an object, may perform a type check depending on the data format. | |
| bool | end_object () override |
| Ends processing of an object. | |
| bool | begin_field (std::string_view) override |
| bool | begin_field (std::string_view name, bool &is_present) override |
| bool | begin_field (std::string_view name, span< const type_id_t > types, size_t &index) override |
| bool | begin_field (std::string_view name, bool &is_present, span< const type_id_t > types, size_t &index) override |
| bool | end_field () override |
| bool | begin_tuple (size_t size) override |
| Begins processing of a fixed-size sequence. | |
| bool | end_tuple () override |
| Ends processing of a sequence. | |
| bool | begin_key_value_pair () override |
| Begins processing of a tuple with two elements, whereas the first element represents the key in an associative array. | |
| bool | end_key_value_pair () override |
| Ends processing of a key-value pair after both values were written. | |
| bool | begin_sequence (size_t &size) override |
| Begins processing of a sequence. | |
| bool | end_sequence () override |
| Ends processing of a sequence. | |
| bool | begin_associative_array (size_t &size) override |
| Begins processing of an associative array (map). | |
| bool | end_associative_array () override |
| Ends processing of an associative array (map). | |
| bool | value (std::byte &x) override |
Reads x from the input. | |
| bool | value (bool &x) override |
Reads x from the input. | |
| bool | value (int8_t &x) override |
Reads x from the input. | |
| bool | value (uint8_t &x) override |
Reads x from the input. | |
| bool | value (int16_t &x) override |
Reads x from the input. | |
| bool | value (uint16_t &x) override |
Reads x from the input. | |
| bool | value (int32_t &x) override |
Reads x from the input. | |
| bool | value (uint32_t &x) override |
Reads x from the input. | |
| bool | value (int64_t &x) override |
Reads x from the input. | |
| bool | value (uint64_t &x) override |
Reads x from the input. | |
| bool | value (float &x) override |
Reads x from the input. | |
| bool | value (double &x) override |
Reads x from the input. | |
| bool | value (long double &x) override |
Reads x from the input. | |
| bool | value (std::string &x) override |
Reads x from the input. | |
| bool | value (std::u16string &x) override |
Reads x from the input. | |
| bool | value (std::u32string &x) override |
Reads x from the input. | |
| bool | value (span< std::byte > x) override |
| Reads a byte sequence from the input. | |
| Public Member Functions inherited from caf::deserializer | |
| deserializer (actor_system &sys) noexcept | |
| deserializer (execution_unit *ctx=nullptr) noexcept | |
| auto | context () const noexcept |
| bool | has_human_readable_format () const noexcept |
| virtual bool | fetch_next_object_type (type_id_t &type)=0 |
| Reads run-time-type information for the next object if available. | |
| virtual bool | fetch_next_object_name (std::string_view &type_name) |
| Reads run-time-type information for the next object if available. | |
| bool | next_object_name_matches (std::string_view type_name) |
Convenience function for querying fetch_next_object_name comparing the result to type_name in one shot. | |
| bool | assert_next_object_name (std::string_view type_name) |
Like next_object_name_matches , but sets an error on the deserializer on a mismatch. | |
| virtual bool | begin_object (type_id_t type, std::string_view pretty_class_name)=0 |
| Begins processing of an object, may perform a type check depending on the data format. | |
| virtual bool | end_object ()=0 |
| Ends processing of an object. | |
| virtual bool | begin_field (std::string_view name)=0 |
| virtual bool | begin_field (std::string_view, bool &is_present)=0 |
| virtual bool | begin_field (std::string_view name, span< const type_id_t > types, size_t &index)=0 |
| virtual bool | begin_field (std::string_view name, bool &is_present, span< const type_id_t > types, size_t &index)=0 |
| virtual bool | end_field ()=0 |
| virtual bool | begin_tuple (size_t size)=0 |
| Begins processing of a fixed-size sequence. | |
| virtual bool | end_tuple ()=0 |
| Ends processing of a sequence. | |
| virtual bool | begin_key_value_pair () |
| Begins processing of a tuple with two elements, whereas the first element represents the key in an associative array. | |
| virtual bool | end_key_value_pair () |
| Ends processing of a key-value pair after both values were written. | |
| virtual bool | begin_sequence (size_t &size)=0 |
| Begins processing of a sequence. | |
| virtual bool | end_sequence ()=0 |
| Ends processing of a sequence. | |
| virtual bool | begin_associative_array (size_t &size) |
| Begins processing of an associative array (map). | |
| virtual bool | end_associative_array () |
| Ends processing of an associative array (map). | |
| virtual bool | value (std::byte &x)=0 |
Reads x from the input. | |
| virtual bool | value (bool &x)=0 |
Reads x from the input. | |
| virtual bool | value (int8_t &)=0 |
Reads x from the input. | |
| virtual bool | value (uint8_t &)=0 |
Reads x from the input. | |
| virtual bool | value (int16_t &)=0 |
Reads x from the input. | |
| virtual bool | value (uint16_t &)=0 |
Reads x from the input. | |
| virtual bool | value (int32_t &)=0 |
Reads x from the input. | |
| virtual bool | value (uint32_t &)=0 |
Reads x from the input. | |
| virtual bool | value (int64_t &)=0 |
Reads x from the input. | |
| virtual bool | value (uint64_t &)=0 |
Reads x from the input. | |
| template<class T > | |
| std::enable_if_t< std::is_integral< T >::value, bool > | value (T &x) noexcept |
Reads x from the input. | |
| virtual bool | value (float &)=0 |
Reads x from the input. | |
| virtual bool | value (double &)=0 |
Reads x from the input. | |
| virtual bool | value (long double &)=0 |
Reads x from the input. | |
| virtual bool | value (std::string &)=0 |
Reads x from the input. | |
| virtual bool | value (std::u16string &)=0 |
Reads x from the input. | |
| virtual bool | value (std::u32string &)=0 |
Reads x from the input. | |
| virtual bool | value (span< std::byte > x)=0 |
| Reads a byte sequence from the input. | |
| virtual bool | list (std::vector< bool > &xs) |
Adds each boolean in xs to the output. | |
Static Public Attributes | |
| static constexpr std::string_view | field_type_suffix_default = "-type" |
The value value for field_type_suffix() . | |
Additional Inherited Members | |
| Protected Attributes inherited from caf::deserializer | |
| execution_unit * | context_ |
| Provides access to the ::proxy_registry and to the ::actor_system. | |
| bool | has_human_readable_format_ = false |
| Configures whether client code should assume human-readable output. | |
Deserializes an inspectable object from a JSON-formatted string.
|
overridevirtual |
Begins processing of an associative array (map).
begin_sequence(size)
. Reimplemented from caf::deserializer.
|
overridevirtual |
Implements caf::deserializer.
|
overridevirtual |
Implements caf::deserializer.
|
overridevirtual |
Implements caf::deserializer.
|
overridevirtual |
Implements caf::deserializer.
|
overridevirtual |
Begins processing of a tuple with two elements, whereas the first element represents the key in an associative array.
begin_tuple(2)
. Reimplemented from caf::deserializer.
|
overridevirtual |
Begins processing of an object, may perform a type check depending on the data format.
| type | 16-bit ID for known types, invalid_type_id otherwise. |
| pretty_class_name | Either the output of type_name_or_anonymous or the optionally defined pretty name. |
Implements caf::deserializer.
|
overridevirtual |
Begins processing of a sequence.
Implements caf::deserializer.
|
overridevirtual |
Begins processing of a fixed-size sequence.
Implements caf::deserializer.
|
overridevirtual |
Ends processing of an associative array (map).
end_sequence()
. Reimplemented from caf::deserializer.
|
overridevirtual |
Implements caf::deserializer.
|
overridevirtual |
Ends processing of a key-value pair after both values were written.
end_tuple()
. Reimplemented from caf::deserializer.
|
overridevirtual |
Ends processing of an object.
Implements caf::deserializer.
|
overridevirtual |
Ends processing of a sequence.
Implements caf::deserializer.
|
overridevirtual |
Ends processing of a sequence.
Implements caf::deserializer.
|
overridevirtual |
Reads run-time-type information for the next object if available.
The default implementation calls fetch_next_object_type
and queries the CAF type name. However, implementations of the interface may retrieve the type name differently and the type name may not correspond to any type known to CAF. For example. the json_reader returns the content of the @type
field of the current object if available.
type_name
may point to an internal buffer that becomes invalid as soon as calling any other member function on the deserializer. Convert the type_name
to a string before storing it. Reimplemented from caf::deserializer.
|
overridevirtual |
Reads run-time-type information for the next object if available.
Implements caf::deserializer.
|
noexcept |
Returns the suffix for generating type annotation fields for variant fields.
For example, CAF inserts field called "@foo${field_type_suffix}" for a variant field called "foo".
| bool caf::json_reader::load | ( | std::string_view | json_text | ) |
Parses json_text
into an internal representation.
After loading the JSON input, the reader is ready for attempting to deserialize inspectable objects.
json_text
. Hence, the buffer pointed to by the string view must remain valid until either destroying this reader or calling reset
. reset
. | bool caf::json_reader::load_file | ( | const char * | path | ) |
Parses the content of the file under the given path
.
After loading the content of the JSON file, the reader is ready for attempting to deserialize inspectable objects.
reset
. | bool caf::json_reader::load_file | ( | const std::string & | path | ) |
Parses the content of the file under the given path
.
After loading the content of the JSON file, the reader is ready for attempting to deserialize inspectable objects.
reset
. | void caf::json_reader::revert | ( | ) |
Reverts the state of the reader back to where it was after calling load
.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads a byte sequence from the input.
| x | The byte sequence. |
sec::success
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.
|
overridevirtual |
Reads x
from the input.
| x | A reference to a builtin type. |
true
on success, false
otherwise. Implements caf::deserializer.


Lifepak© 20e Defibrillator Simulator Test Cases
Please read carefully
You are about to begin the first of 3 cases that will test your knowledge of how to use the defibrillator. As in the Tutorial Cases, each scenario will start with a Case Description. After you read the Case Description, you can close that box and begin working the case.
Please be advised:
- You will see a case score and a clock displayed in the upper right corner of the screen. The clock starts once the Case Description box appears. You will need to begin working the case as quickly as possible to avoid point deductions. Bear in mind some interventions are time critical and failure to perform a task in an appropriate time frame may result in patient harm.
- Help will not be available during the test cases.
- When each case is over, you will be prompted to advance to the next test case.
Good Luck!
Click here to proceed to test cases


Activities you can try
To gain an insight into the challenges of users with access needs try these activities. You can do them at home, at your desk.
Try this game accessibility through a maze
Not everyone uses a mouse so unplug your mouse or disable your trackpad and try using only your keyboard for an hour
Change your browser zoom to 400% and check the effect of resizing on the webpage you are viewing
Try some of the built in Microsoft Windows accessibility features, such as Windows Narrator
If you have an Apple device, try the Mac accessibility features, such as VoiceOver
The hearing loss simulator demonstrates how different levels of hearing loss are perceived
The dyslexia simulator rearranges the letters within words on a page to give you a feel for what it may be like reading with dyslexia
Colour blindness experience allows you to find out what it is like to live in a colour-blind world and access simulators to find out what your content looks like to someone who is colour blind
The Funkify simulators mimic cognitive; dyslexia; motor and vision conditions. You can experience the web through the eyes of users with these disabilities. Note: you will not be able to do this on your HMRC Surface Pro
Add extensions for accessibility insights to your browser. Note: you will not be able to do this on your HMRC Surface Pro
Try out this fictional service "Record a goose sighting" which contains accessibility issues you need to find. Once in the service, there is a link to a worksheet to help you through the exercise. This was created as a method of “Training people to do accessibility reviews”
Please email us at<EMAIL_ADDRESS>if you have any questions.


class ItunesResult
ItunesResult class representing the response from retrofit
ItunesResult()
ItunesResult class representing the response from retrofit |
var resultCount: Int?
TODO : unused |
|
var results: List<ItunesItem>?
results as List the list of itunes track |


{% extends "console/base_console.html" %} {% load static %} {% block title %}{{ page_title }} - {{ app_user.username }}{% endblock %} {% block local_js_top %} {% endblock %} {% block content %}
A reference was not provided.
{% elif application.reference_contact_datetime %}The reference was contacted on {{ application.reference_contact_datetime }}
{% if not application.reference_response_datetime %}Awaiting reference response.
{% endif %} {% else %}The reference has not been contacted.
{% endif %} {# Reference already responded #} {% if application.reference_response_datetime %}The reference verified the applicant on {{ application.reference_response_datetime }}
{% if application.reference_response_text %}{{ application.reference_response_text }}
{% endif %} {% endif %}Clicking the button below will allow the application to proceed straight to the Final Review stage. The reference check can be skipped if:
No reference provided.
{% else %} {% endif %}


Adds the vanilla reCAPTCHA widget, for testing...
After you click the recaptcha open up console and run grecaptcha.getResponse() to get the generated code and use it on postman.


Consultation outcome
MS Word Document , 1.79MB
If you use assistive technology (such as a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.
PDF , 249KB , 23 pages
If you use assistive technology (such as a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.
This report summarises the responses to the formal consultation.
This consultation ran from
to
The inspection of local areas’ effectiveness in identifying and meeting the needs of children and young people who are disabled and have special educational needs.
PDF , 439KB , 22 pages
If you use assistive technology (such as a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.
MS Word Document , 759KB
If you use assistive technology (such as a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.
PDF , 203KB , 8 pages
If you use assistive technology (such as a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.
PDF , 150KB , 1 page
If you use assistive technology (such as a screen reader) and need a version of this document in a more accessible format, please email<EMAIL_ADDRESS>. Please tell us what format you need. It will help us if you say what assistive technology you use.
This is a consultation on Ofsted and the Care Quality Commission’s proposals for inspecting how effectively local areas fulfil their responsibilities towards children and young people who are disabled and/or have special educational needs under section 20 of the Children Act 2004. The consultation document sets out the principles under which the 2 inspectorates propose to undertake these joint inspections.
We are seeking the widest possible range of views from those who have an interest in, or expertise relating to disability and special educational needs. We particularly want to hear from disabled young people and those who have special educational needs and their parents and carers.
A further version of this consultation is provided to support the contribution of young people.
The consultation documents are available in 2 formats:
The views of young people are very much welcomed.
The closing date for this consultation is 4 January 2016.
Published: 12 October 2015
Updated: 10 March 2016
From: Ofsted Care Quality Commission
Part of: Young people


Dependencies¶
ToFu uses the following generic packages:
python/2.7.3
ipython/1.1.0
dateutil/2.4.0
docutils/0.12.0
distribute/0.6.34
Scientific computing and plotting:
numpy/1.9.1
scipy/0.15.1
matplotlib/1.2.1
polygon2
datetime
Some part of ToFu are coded using Cython, which requires Cython and a compiler:
cython/0.19.1
gcc/4.8
intel/14.0
Testing:
nose/1.3.4
Documentation:
pygments/1.5
To be determined:
pyzmq/13.0.2
tornado/2.4.1
setuptools
mdsplus/5.0_11
pip
git/1.8.4