Nictiz Care Provider Registry

To	Patient Administration TC, HL7.org
From	Alexander Henket, HL7 Lead Nictiz, Co chair Administrative Management HL7 Netherlands, mailto:alexander.henket@enovation.nl
Subject	Care Provider Registry
Date	May 17, 2010

1 Introduction
2 Goal of the document
3 Goal of the Care Provider Registry
4 How does it work
5 Organization Registry - use cases
6 Human Resources Registry - use cases
7 Application Registry - use cases
8 Interaction diagrams - Organization Registry
9 Interaction Diagrams - Human Resource Registry
10 Interaction Diagrams - Application Registry

Introduction

Nictiz is the national ICT institute for care in The Netherlands (http://www.nictiz.nl - English text available) and delivers a national infrastructure based on HL7 Version 3. This infrastructure is called the AORTA with a national switch point (LSP) in the centre.

Goal of the document

The LSP handles routing, authentication, authorization, logging, and other services. One of the other services is a concept called the Care Provider Registry (Dutch: Zorgadresboek or ZAB). This document lays out what the Care Provider Registry does, and how it does it when it comes to HL7V3. This should help the Patient Administration committee in their requirements analysis necessary to move forward on administrative registries.

Goal of the Care Provider Registry

The Care Provider Registry has at its core only one purpose: to be able to find the software application address to send your message to. This address is in the form of a device id (ApplicationID) that you may use to put into the Receiver.Device.id attribute of a transmission wrapper.

In order to find the correct address, you need to know about the capabilities that you need this application to have, the organization it is tied to, and sometimes also the persons tied to the organization.

How does it work

The Care Provider Registry consists of three separate registries: Organization, Human Resource, and Application. In the backend the Organizations, and Human Resources are copied over from the national Certificate Authority that you have to have been registered with in order to do anything on the AORTA. This CA, called CIBG under the Ministry of Health, provides the server certificates and smartcards to do necessary SSL/TLS encryption of the transmission layer, and authentication.

The three separate registries can be combined into the desired functionality, and this is done at the client applications. The AORTA does not offer a layer on top of the registries.

Organization Registry - use cases

Candidate Query for organizations based on: Organization name, organization address, organization type, organization status, and last update time.

Last update time allows you to retrieve updated records after a certain date.

Detail query for organizations based on: Organization.id

Human Resources Registry - use cases

Details query for providers (human resources) based on: Provider id, provider type, organization id, provider name, provider address, provider status, last update time.

Last update time allows you to retrieve updated records after a certain date.

Application Registry - use cases

Get Applications of an AssignedEntity based on: AssignedEntity id (organization, human resources, organization parts), AssignedEntity scoper id (organization id), AssignedEntity type (organization, human resource), InteractionID, QualifiedRoleType.

InteractionID allows you to find applications capable of receiving/sending a certain interaction, e.g. a medication order QualifiedRoleType allows you to find applications capable to support a certain role with all mandatory underlying interactions.

Get Application Detail Query based on: QualifiedDeviceID, QualifiedRoleType, AssignedEntity id (organization, human resources, organization parts)

QualifiedDeviceID is the application-id the device that fulfilles the QualifiedRoles has. We use this id in the transmission wrapper for sender/receiver QualifiedRoleType allows you to find applications capable to support a certain role with all mandatory underlying interactions.

Add Application Request, Update Application request are used to allow system to add themselves to the AORTA and manage their status (pending, active, suspended). They are only allowed to do so if they are qualified, and have been assigned at least an application-id. In test environments that is about all they need. In production environments they also need to supply their id assigned in the qualification process (VerificationEvent.id).