This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Proposed new Topic: Application Registry

From HL7Wiki
(Redirected from PRPM - AORTA use cases)
Jump to navigation Jump to search

Use-case: AORTA, the Dutch national healthcare IT infrastructure, maintains a registry of applications. Note: this is about software applications such as Lab systems, HIS systems, EHR applications etc. A software application is modeled as a Device entity in the HL7 RIM; Device should however (in the context of this use-case) not be interpreted as a 'medical device' in the regulatory sense.

The aim is to have registry of softewra applicatiosn with the aim of:

  • linking healthcare provider IDs to Application IDs (and vice versa); "yellow pages / LDAP / DNS" use-case
  • capturing the Application Roles (IHE: Actors) that a software appliction fulfills
  • capturing the list of Interactions supported by a software application.

Application Topic

Application registry (new topic), based on current PRPM D-MIM, with extensions

High-level walkthrough: the top half of this model is new, the bottom half is based on the current PRPM D-MIM. The tophalf of the model has been added to associated the parties (AssignedEntity) with the application(s) (QualifiedApplicationRole) that they use to exchange interactions (identified by InformEvent). The Inform class plays the linking pin in the model: it expresses that the AssignedEntity expects to inform, and expects to be informed, using a certain software application, by means of a set of interactions.

R-MIMs

Entry point for query response, based on AssignedEntity's capabilities
Entry point for Application registry (new topic)

Discussion

  • 20090112 Q2, Orlando: PA feels that, even when there are areas of overlap (this static model is covered by the PM D-MIM, it fits in the general registry pattern, the PM D-MIM suggests it was the intent of PM to create such registries) that this is out of scope of the PM material. This is not about medical devices, so this is out of scope of the Devices WG. Maye Shared Messages might be appropriate. For technical reasons this proposal is rejected: there is no second implementer that would commit to implementing the proposed solution.