SMART Verifiable IPS for Pilgrimage
1.0.0 - ci-build
This page is part of the SMART Verifiable IPS for Pilgrimage (v1.0.0: Releases Draft) based on FHIR (HL7® FHIR® Standard) v4.3.0. This is the current published version. For a full list of available versions, see the Directory of published versions
This page outlines the minimum set of data corresponding to different points of the workflow within the identified business processes. This data set can be used on any software system and lists the data elements relevant for service delivery and executing decision-support logic, as well as for populating indicators and performance metrics.
The following table includes data elements for the registration workflow.
Activity ID | Data Element ID | Data Element Label | Description and Definition | Multiple Choice Type (if applicable) | Data Type | Input Options | Calculation | Quantity Sub-Type | Validation Condition | Editable | Required | Skip Logic | Linkages to Aggregate Indicators | Notes | ICD-11 Code | ICD-11 URI | ICD-11 Comments / Considerations | ICD-11 Relationship | ICD-10 Code | ICD-10 Comments / Considerations | ICD-10 Relationship | ICD-9 Code | ICD-9 Comments / Considerations | ICD-9 Relationship | LOINC version 2.68 Code | LOINC version 2.68 Comments / Considerations | LOINC version 2.68 Relationship | ICHI (Beta 3) Code | ICHI URI | ICHI Comments / Considerations | ICHI Relationship | ICF Code | ICF Comments / Considerations | ICF Relationship | SNOMED GPS Code | SNOMED GPS Comments Considerations | SNOMED GPS Relationship | Snomed CT International Version Code | Snomed CT International Version Comments / Considerations | SNOMED CT Relationship | HL7 FHIR R4 - Resource | HL7 FHIR R4 - Values | HL7 FHIR R4 Code | HL7 FHIR R4 Relationship |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
IPS.PILGRIMAGE.4.0 Break the Glass Clinical Encounter | IPS.C1.DE1 | Pilgrimage Registration Number | Unique identifier for the Pilgrim provided by the Host Country to the Pilgrim via the National Pilgrimage Authority | N/A | ID | N/A | N/A | N/A | Minimum and maximum number of characters based on local policy | No | R | None | Not classifiable in ICD-11 | Not classifiable in ICD-10 | Not classifiable in ICD-9 | Not classifiable in LOINC | Not classifiable in ICHI | Not classifiable in ICF | Not classifiable in SNOMED-GPS | Identifier (property) (qualifier value) | Equivalent | Patient.identifier | Equivalent |
The following table describes how to read the data dictionary, including keys and colour coding. For full notes, see the Web Annex of the DAK.
Data dictionary column | Constrained input options (if relevant) | Description of what to include for each unique data element |
---|---|---|
Activity ID | Include the activity ID under which that data will first be collected. It is important that key data are collected only once. Even if that specific piece of data will be needed again in a later activity, it will be important to note when that data is actually first provided to the provider. | |
Data Element Label | The label of the data element written in a way that end-users can easily understand – e.g. “education level”, “weight”, “height”, “reason(s) for coming into facility”, “which medication(s) is the client taking?” The data element label in this column is what will be used in the digital form: the digital register should not simply replace the paper registers, but it should also streamline processes and link duplicated data elements. | |
Description and Definition | The description and definition of the data element, including any units that define the field (e.g. weight in kilograms [kg]). Provide a clear explanation of what this data field is requesting. | |
Multiple Choice | If the data element is indicative of a multiple choice question (e.g. symptoms), then indicate the type of multiple choice question here. The types would be: | |
Select one | Select one – only one input can be chosen | |
Select all that apply | Select all that apply – more than one input option can be chosen | |
Input Option | Each individual answer option should be listed in the Input Options column and be classified with one of the data types listed below | |
Data Type | The data types are as follows: | |
Boolean | Boolean (i.e. True/False, Yes/No) | |
String | String (i.e. a sequence of Unicode characters – e.g. name) | |
Date | Date (e.g. date of birth) – used for when only the date is recorded | |
Time | Time (e.g. time of delivery) – used for when only the time is recorded | |
DateTime | DateTime (e.g. appointment) – used for when you need to record the date and the time | |
ID | ID (e.g. unique identifier assigned to the client) | |
Quantity | Quantity – a number that is associated with a unit of measure outlined in the standard for Unified Code for Units of Measure (UCUM). Quantities include any number that is associated with a unit, such as “number of past pregnancies”, where “past pregnancies” is the unit of measure (1). – If the data type is a “Quantity” there should be an associated sub-type listed in the “Quantity sub-type” column. |
|
Signature | Signature (e.g. supervisor’s approval) – an electronic representation of a signature that is either cryptographic or a graphical image that represents a signature or a signature process | |
Attachment | Attachment (e.g. image) – additional data content defined in other formats | |
Coding | Coding (e.g. symptoms, reason for coming to the facility, danger signs) – multiple-choice data elements for which the input options are Codes. | |
Codes | Codes (e.g. pregnant, HIV positive, combined pill) – data elements that are input options to multiple-choice data elements, which are none of the above data types. | |
Although the list above should be sufficient to relay this information to a health informaticist or technology vendor, there are many more data codes that can be applied to achieve a more precise classification – for other possible data types, please refer to the HL7 FHIR guide on Data Types (2) | ||
Input Options | For multiple-choice fields only – for other fields, leave this column blank. Write the list of responses from which the health worker may select. Each of these options should be labelled with a Data Type as indicated above. | |
Calculation | If a calculation is needed to define the data element, write the formula here. Leave this column blank if no calculation is needed. Write the formula using standard mathematical symbols and the Data Element Label included in the formula (e.g. for the body mass index calculation (BMI), “Weight/(Height^2)”). | |
Quantity Sub-type | N/A | Quantity data types can include any number that is associated with a unit of measure. However, there are many sub-types of Quantity that should be listed here: |
Integer quantity | Integer quantity – a whole number (e.g. number of past pregnancies, pulse, systolic blood pressure, diastolic blood pressure) | |
Decimal quantity | Decimal quantity – rational numbers that have a decimal representation (e.g. exact weight in kilograms, exact height in centimetres, location coordinates, percentages, temperature) | |
Duration | Duration – duration of time associated with time units (e.g. number of minutes, number of hours, number of days) | |
Validation Condition | With digital systems, it is possible to incorporate “data entry validation” to ensure that the data entered into that field is accurate at the time of data entry. For example, if a health worker accidentally enters the height of an individual as 1650 cm instead of 165 cm, the system should notify the health worker that an erroneous height has been entered. This feature will help increase the fidelity of data entry. This should contain the range of acceptable responses, if validation is required (e.g. for a phone number, only 10 digits allowed; for a birthday, only past dates allowed). |
|
Editable | Indicate whether the end-user, or health worker, would be able to edit the field after it has been input to the system: “Yes” or “No” | |
Required | Note whether or not this field is: | |
R | Required – R | |
O | Optional – O | |
C | Conditional on answers from other data fields – C | |
Skip Logic | If the field is Conditional on answers from other data fields (C), denote what the skip logic is here. This is common for data elements that are a part of follow-up questions. For example, if the input of one data element field has a value lower than a certain threshold, then some data inputs can be skipped. Those input data elements will have skip logic that is defined by a preset threshold. Skip logic can also sometimes be referred to as “Relevance”, as the logic described in this field sometimes determines whether or not that specific data element is “relevant”. | |
Linkages to aggregate indicators | List the indicators here, if applicable | |
Notes | This column should be used for any other notes, annotations or communication messages within the team | |
Mapping to code systems (standardized terminologies and classifications) | Depending on which systems the digital system is planned to interoperate with, other columns will need to be added to map to code systems for standardized terminologies/classifications used in the other systems (e.g. ICD-11, SNOMED, LOINC). One column should be used for each type of code system | |
Mapping to code systems, Considerations/comments | This column should be used for any other notes, annotations related to the concept maps. | |
Mapping to code systems, Relationship | For data elements that can be mapped, this column should be used to identify the relationship between the original intent of the data element (i.e. “source concept”) with the terminology mapping available in existing code systems (i.e. “target concept”) (3). The field should indicate: | |
Related to | The concepts are related to each other, but the exact relationship is not known. | |
Equivalent | The definitions of the concepts mean the same thing. | |
Source is narrower than target | The source concept is narrower in meaning than the target concept. | |
Source is broader than target | The source concept is broader in meaning than the target concept. | |
Not related to | This is an explicit assertion that the target concept is not related to the source concept. |