Nepal HMIS FHIR Implementation Guide – 🚨 DRAFT VERSION
0.0.1-ballot - ci-build Nepal flag

Nepal HMIS FHIR Implementation Guide – 🚨 DRAFT VERSION - Local Development build (v0.0.1-ballot) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

ArchiMate Diagram

This specification utilizes a subset of ArchiMate notation to visually represent and structure the authoring processes. This distinguishes between the functional description (application layer) and the physical artifacts (technology layer).

This specification uses:

  1. ArchiMate's layering concept, distinguishing between application and technology layers.
  2. ArchiMate relations, namely aggregation, composition, and the labeled "related to" relationship.
  3. Representation of starting artifacts as technology artifacts (e.g., files or data objects).
  4. Display of processes within the application layer, illustrating how functional processes transform L2 inputs into L3 outputs.

ArchiMate Notation Overview

Layers

  • Application Layer: Offers a functional description, typically illustrating processes, functions, and services. This is represented by blue elements.

  • Technology Layer: Represents actual artifacts, like files, resource instances, or other data objects. This is represented by green elements.

Relations

The relations are represented by arrows

  • Aggregation: Illustrates that an object groups several other objects.

  • Composition: Indicates that an object is composed of one or more other objects, implying a stronger, "whole-part" relationship compared to aggregation.

  • Access (Read/Write): Indicates that a process has an artifact as input, or as output.

  • Related To: A generic relationship with a label specifying the nature of the connection.

  • Flows to: A relationship where an activity (process) is followed by another activity

Data Model Data Elements Code System Concept L2: GenericPersonas Create Persona Data Element ValueSet Create CQL NextActivity Aggregation- Illustrates that an object or processgroups several other objects/processes.Example: A Data model aggregates several Data Elements.The Data Elements can exist without the Data Model. Composition- Indicates that an object or processis composed of one or more other objects/processes.Example: A CodeSystem is composed of Concepts.If the CodeSystem is deleted, the Concepts cease to exist. Access (Read/Write)- Indicates that a process has an artifact as input or output.Example: To Create a Persona has L2 Generic Personas as input. Related To- A generic relationshipwith a label specifying the type of connection.Example: A ValueSet is related to a Data Element. ActivityFlows toActivity- A relationship where one activity follows another.Example: "Create CQL" flows to "Encode CQL".

Example Diagram

The diagram below represents the process for creating an indicator:

  • The input artifact is an L2 definition of an indicator (in a spreadsheet)
  • The main process is to create an L3 Measure artifact
  • To define the Measure, there's a subprocess where the L3 author adds population and stratifiers, by consulting the cqf-measures-guidance.
  • The next step (as part of the Create Measure process) is then to create CQL definitions
  • Following that, the L3 author encodes CQL into libraries.
  • The output of this is the L3 library that is referenced by the Measure resource


Artifact Authoring Processes

The diagrams capture the essence of transforming an L2 input into the corresponding L3 artifacts through processes. These processes can use different tooling or technologies; however the criteria for output and for process are defined.

Data Object Details with PlantUML

To describe the content L3 authors are supposed to produce, the key content of the output artifacts is modeled with PlantUML diagrams. This diagram summarizes the data that is part of an object definition. For example, the diagram below shows that for a ValueSet, the L3 author is required to have a status, a name, an identifier and a URL.

ValueSetidentifier 1..*url 1..*status 1..1name 1..1title 1..1experimental 1..1description 1..1Data needsfor value sets(seelegend)

Content Types ArchiMate Diagram

The SMART Guidelines define the provision of guidance and monitoring using a structured, standardized representation of knowledge of different types, which are represented in L2 and L3. The diagram and table here represent those concepts in a visual manner.

Note: This diagram is not representative of the component/artifact names across L2 or L3, but is an abstract overview of concept types involved in the definition of SMART Guidelines.


Content Type Description
Health Interventions Initiatives about prevention, monitoring or addressing medical conditions.
Generic Personas An archetype representing a person interacting with the system. This aids in understanding the motivations and potential actions of users within scenarios.
User Scenarios A narrative or situation where users interact with a system, environment, or service. User scenarios guide many subsequent knowledge representation processes to ensure coverage and focus.
Business Process A collection of related tasks or activities that achieve a specific organizational goal. Business processes often encompass or give rise to multiple user scenarios, especially in complex systems.
Requirement A detailed specification of a system’s needs, derived from user scenarios, personas, and business processes. It forms the foundation for system design and testing.
Decision Table A structured method for representing complex decision logic. This is a basis for developing business processes and transformation logic.
Scheduling Logic The rules used to schedule tasks and interventions
Indicators Metrics used to measure the performance or outcomes of business processes and health interventions, and guide decision-making.
Data Object A comprehensive representation of information, often deriving from business processes or requirements. They encapsulate multiple data elements.
Data Element An atomic piece of data, often a part of data objects. Elements get transformed, coded, or mapped as per transformation logic or coding systems.
Coding The assignment of codes to data elements, where applicable, using standard terminologies and mapped to other codes as needed. Coding aids in ensuring that data elements are universally understood and interpretable.
Code Mapping Mapping the codes from one system to another, ensuring that multiple representations, when possible, are documented and accessible.
Forms A tool for data collection, often driven by the requirements of business processes or the need to collect specific data.
Transformation logic The rules applied to change data from one format or structure to another. Often influenced by decision tables, coding, and mapping to ensure data integrity.
Test Case A set of conditions for which a system is assessed, often derived from requirements and user scenarios. They ensure the system performs as expected.
Test Data Specific data used to execute test cases, often derived from data objects and elements, ensuring testing of system functionalities.

The L2 content is presented in the artifacts represented in the ArchiMate diagram below:



The L3 artifacts are represented in the ArchiMate diagram below: