The terms "core" and "non-core" when associated with "Horus" are not universally defined; their meaning depends entirely on the application in question. The most prominent use refers to the UK's medical Foundation Programme for junior doctors, but it also applies to business process modeling software and software development frameworks. Understanding the context is crucial to distinguishing between the two.
Core vs. Non-Core Horus in Medical Education
In the UK Foundation Programme, Horus is the name of the e-portfolio system used by trainee doctors to log their professional development and competencies. This system distinguishes between core and non-core learning to ensure a balanced educational experience.
Core Learning
Core learning is the mandatory and centrally directed part of the training program. It is directly aligned with the foundational curriculum and requires a minimum number of hours to be completed and logged annually. For example, trainees must complete at least 30 hours of core learning per year.
Examples of core learning include:
- Regional Teaching Days: Formal, structured training days organized by the Foundation School.
- Mandatory Simulation Training: Specific simulation sessions arranged by the foundation team (e.g., SIM 1 and SIM 2).
Non-Core Learning
Non-core learning is not mandatory but is a flexible component that can count towards a trainee's overall learning hours, up to a maximum of 30 hours. It provides trainees with the flexibility to pursue educational activities of personal or departmental interest.
Examples of non-core learning include:
- Departmental Teaching: Planned, formal teaching sessions conducted within a specific hospital department.
- Grand Rounds: Educational lectures or presentations given to hospital staff.
- E-learning Modules: Online courses, though the quality is considered by review panels.
Core vs. Non-Core in Horus Software and Systems
In software and systems development, Horus can refer to different applications, where the core/non-core distinction follows a classic software architecture pattern.
Horus Framework (Software Development)
In software frameworks like the Horus v14 framework mentioned on GitHub, the "core" refers to the foundational and most essential code. This core provides the base functionality, architecture, and principles upon which all other features are built. Non-core aspects are additional plugins, modules, or extensions that add functionality but are not essential to the system's basic operation. For example, a developer might build a non-core plugin to add a specific feature using the core's Python API.
HORUS (Lancer RPG)
In the fictional universe of the Lancer role-playing game, HORUS is a decentralized organization. In this context, "core bonuses" are foundational abilities available to mech pilots who invest in HORUS licenses. These bonuses grant enhanced hacking and electronic warfare capabilities, which are central to the HORUS system. Non-core elements would be the various, specific mech licenses or individual pieces of paracausal technology that aren't tied to the core bonuses.
Core vs. Non-Core in Business Process Modeling
Horus software GmbH provides tools and methodologies for business process analysis. Here, the core vs. non-core distinction refers to essential business processes and their supporting functions.
Core Business Processes
With the Horus Method, core business processes are those that directly define a company's existence and offer a competitive advantage. The core process modeling involves defining procedures, organizational structures, and the flow of critical business objects. Without this fundamental analysis, the business process model is incomplete.
Non-Core Supporting Functions
Non-core functions, while necessary, are supportive tasks that do not directly contribute to the primary strategic objectives. These can be modeled within the Horus framework but are supplementary to the core analysis. Many companies outsource these non-core functions to focus on their core competencies.
Comparison Table: Core vs. Non-Core Horus by Context
| Context | Core Horus | Non-Core Horus |
|---|---|---|
| Medical Education | Mandatory, curriculum-aligned learning hours logged in the e-portfolio (e.g., Regional Teaching). | Optional, flexible learning activities that contribute to the overall total (e.g., departmental teaching, e-learning). |
| Software & Systems | The foundational framework, architecture, and essential code that provide the base functionality. | Add-on modules, plugins, and extensions that provide additional, non-essential features. |
| Business Process Modeling | The central business processes, organizational structures, and procedures that are critical to the company's competitive advantage. | Supportive functions, like administrative support or facilities management, that aid core processes but can often be outsourced. |
Conclusion
In summary, the distinction between core and non-core Horus is a matter of context. In the UK Foundation Programme, it separates mandatory, curriculum-driven training from optional, flexible learning. Within software development, it differentiates the essential framework from optional extensions. In business process modeling, it highlights the difference between mission-critical operations and supporting, often-outsourced, functions. The key takeaway is that the terms refer to the foundational versus the supplementary elements within their specific domains. For more details on the UK Foundation Programme's e-portfolio, you can visit their official site.
- Medical Training: Core learning is mandatory and centrally directed, unlike non-core learning, which is optional and flexible.
- Software Development: Core refers to the fundamental framework, while non-core comprises additional plugins or modules built on top of it.
- Business Process Modeling: Core processes are central to a company's mission and competitive advantage, whereas non-core activities are supportive and can be outsourced.
- Key Distinction: The central difference lies in whether the activity or component is mandatory/foundational (core) or supplementary/flexible (non-core) within its specific system.
- Context is Key: Interpreting "core" and "non-core" Horus requires understanding the specific application, be it an e-portfolio, software framework, or business method.
