Pesquisar

Artigo
· 1 hr atrás 3min de leitura

Aspectos destacados de OAuth para FHIR (2024.3+) – Guía rápida para nuevos clientes

También en versiones anteriores podíais definir vuestro servidor FHIR para aceptar solicitudes mediante OAuth 2.0 (por ejemplo, para un cliente SMART on FHIR), pero hoy en día, con la versión v2024.3, que se lanzó hace ya un tiempo, existe una nueva funcionalidad que permite hacerlo de forma más sencilla: el OAuth FHIR Client QuickStart.

Este “QuickStart” es un asistente tipo wizard que os permite conectar vuestro servidor FHIR a un servidor OAuth y habilitar la autenticación y autorización OAuth para las solicitudes FHIR en 5 sencillos pasos (en realidad, solo 3…).

  • Paso 1 – Crear o elegir un servidor FHIR

Puede que ya tengáis un servidor FHIR (endpoint) definido, o puede que todavía no hayáis definido ninguno y queráis hacerlo ahora como parte de este QuickStart.

  • Paso 2 – Seleccionar servidor FHIR

Si elegisteis “Usar uno existente”, se os mostrarán los endpoints disponibles por namespace. Por ejemplo:

Si elegís “Crear nuevo”, se os mostrará un pequeño formulario para crear un nuevo endpoint.

Esto es similar a lo que veríais si crearais el endpoint previamente por vuestra cuenta:

  • Paso 3 – Seleccionar el tipo de servidor OAuth

Podéis elegir usar un servidor OAuth externo (por ejemplo, Auth0 de Okta) o utilizar el servidor OAuth integrado en InterSystems IRIS.

Si queréis usar IRIS como vuestro servidor OAuth, necesitaréis configurar IRIS como un servidor OAuth que soporte FHIR. También disponéis de un “atajo” para ello: un método que podéis llamar y que realizará esta configuración por vosotros.

Tened en cuenta que es necesario configurar la comunicación segura para que esto funcione.

  • Paso 4 – Configurar el servidor OAuth

Si elegisteis usar un servidor OAuth externo, se os pedirá que indiquéis su Issuer Endpoint:

Si ya habíais definido uno, podéis seleccionarlo del desplegable; si no, podéis escribirlo (o pegarlo).

En cualquier caso, podéis probar este endpoint del servidor OAuth, por ejemplo:

  • Paso 5 (o 4 si elegisteis el servidor OAuth interno de IRIS) – Confirmar

Veréis una breve información de confirmación y un botón “Confirmar”.

Por ejemplo (al elegir crear un nuevo servidor FHIR y usar el servidor OAuth interno de IRIS):

O por ejemplo (al elegir un endpoint FHIR existente y un servidor OAuth externo):

Si todo va bien, veréis un mensaje indicando que se creó correctamente.

Si no, recibiréis un mensaje adecuado.

Entre bastidores, deberíais poder observar algunas cosas:

  • Veréis el cliente definido dentro de los clientes OAuth (con sus detalles):

  • Veréis el cliente definido en vuestro endpoint FHIR:

  • En la sección general de Seguridad del Management Portal, bajo OAuth 2.0, también podréis encontrar una Definición de Cliente con su Configuración de Cliente.

Suponiendo que todo lo anterior funcione, podéis comenzar a usar OAuth (y específicamente SMART on FHIR) para comunicaros con vuestro servidor FHIR.

Más sobre esto… en un artículo futuro…

Discussão (0)1
Entre ou crie uma conta para continuar
Anúncio
· 1 hr atrás

[Video] Advancing Healthcare Interoperability - Strategy and Vision

Hey Community,

Enjoy the new video on InterSystems Developers YouTube:

⏯ Advancing Healthcare Interoperability - Strategy and Vision @ Ready 2025

Join us for a detailed look at InterSystems' healthcare interoperability strategy and its impact on healthcare data exchange. Learn about the latest innovations in FHIR, HL7v2, CDA, and API-based interoperability in Health Connect and InterSystems IRIS for Health. Explore our roadmap, including FHIR strategies, AI-driven transformations, and next-generation solutions.

🗣 Presenter: ​​​@Daniel Franco, Senior Manager, Healthcare Data Platform at InterSystems

Looking for fresh ideas? Watch the video and subscribe!

Discussão (0)1
Entre ou crie uma conta para continuar
Artigo
· 2 hr atrás 4min de leitura

Namespaces and databases - basics of inner workings of InterSystems IRIS

InterSystems IRIS is built on an architecture that separates the logical organization of data (namespaces) from its physical storage location (databases). Understanding this separation and the distinction between Namespaces and Databases is crucial for effective data management, security, and especially, high-performance data sharing.

In this article, I will discuss these foundational components and provide a practical guide on leveraging global mappings to share native data structures (globals) across different logical environments.

Databases: Physical Reality

A database represents the physical reality of where the data is stored on the disk. First and foremost, it’s a file in a file system called IRIS.dat (e.g., <Install folder>\mgr\user\IRIS.DAT). The maximum size of this file is 32TB. It is the container for all the actual data and the code. Databases are managed by the IRIS kernel, which handles caching, journaling, and transaction logging at the physical file level.

When you install InterSystems IRIS DBMS, the following databases are installed automatically:

When you’re working in a production environment, it’s strongly recommended that you create a separate dedicated database or several to store your data and code.

To create a new database, go to System > Configuration > Local Databases > Create New Database and provide a name and a directory where it should be stored:

Namespaces: Logical Sandbox

A namespace in InterSystems IRIS represents a self-contained, logical work environment. It is analogous to a schema in a relational database or a project workspace. It defines the scope of all application elements: persistent classes (objects), routines (code), and most importantly, globals (native data structures). Moreover, applications running in one namespace are logically isolated from those in another. This prevents conflicts between different applications or development environments (e.g., Development, Staging, Production). From the developer's perspective, everything, data and code, resides within the confines of the namespace to which they are connected. Each IRIS application process runs in one namespace. If you want to access data/code in another namespace, you need to change it explicitly.

When you install InterSystems IRIS DBMS, the following namespaces are set up automatically:

  • %SYS
  • USER

Mapping Logic to Physics

The link between a Namespace and a Database is established through a Mapping. Every Namespace has a defined set of mappings that specify which physical database(s) should be used to store its elements.

For example, we have several databases:

  • Clients – contains data about clients
  • Finances – contains financial data that allows working with both clients and vendors
  • Vendors – contains data about vendors

and two namespaces:

  • Billing – has mapping to clients and some or all info from finances that allows the applications that work with this namespace to get all necessary info to deal with clients
  • Purchasing – has mapping to vendors and some or all info from finances that allows the applications that work with this namespace to get all necessary info to deal with vendors

At the same time, each namespace has a default database for data and code.

In this example, it could be:

You set up which database should be the default for the namespace when you create a namespace (System > Configuration > Namespaces > New Namespace):

Database for temporary storage will be IRISTEMP by default.

The database for Globals stores data, while the database for Routines stores code and class descriptions.

If you wish to add more mappings to data to other databases, go to System > Configuration > Namespaces > (Choose the namespace) > Global Mappings > New and add a new mapping:

As you can see, you are able to set up access in minute detail – including the subscripts of particular globals.

The same can be done to Routine mappings.

Apart from user-defined mappings, there are also system mappings. System-level code and data (like system class definitions, routines, and system-specific globals starting with ^%) are mapped to system databases (e.g., IRISLIB, IRISSYS). This ensures that application data doesn't interfere with the core system components.


By separating the logical Namespace from the physical Database, and by using mappings, you can gain fine-grained control over data location, security, and performance.

Discussão (0)1
Entre ou crie uma conta para continuar
Resumo
· 3 hr atrás

InterSystems Developers Publications, Week January 05 - 11, 2026, Digest

Articles
Announcements
Questions
January 05 - 11, 2026Week at a GlanceInterSystems Developer Community