FRED Interlinked Registries DRAFT roadmap for consideration.

FRED Interlinked Registries

DRAFT roadmap for consideration

2

Project context

• The phase 1 RHEA facility registry is the starting point for the FRED project

• The FRED project’s goal is to move the technology forward to a v2 and to begin to engage with other stakeholders regarding national facility registry initiatives

• It is expected that these facility registry initiatives would “set the table” for larger national meHealth infrastructure projects; these would be catalytic initiatives

3

Project context

RHEA Phase 1 FRED v1 FRED v2

RHEA Phase 2

…

4

Notes & Definitions

• FRED V1: The current inSTEDD Resource Map code base; may not completely satisfy the original Facility Registry spec of the Rwandan MoH for RHEA (which can be revised by field needs)

• FRED v2: [Will require name change] A standards-based family of interlinked registries (Facility, Resource, Provider and Agency) working together to support the set of service functions described in the HL7 spec document.

5

Architectural context

• On the RHEA project, the facility registry plays a “service-oriented” role within the overall Rwandan health information infrastructure

• Facility registry services are invoked as part of runtime transactions orchestrated by the interoperability layer [REST based using Mulesoft]

• Use cases for phase 1 of the RHEA project are rudimentary; they do not involve more than CRUD of facility registry “attribute” information and validation of facility codes at runtime

6

Architectural context

openHIM

7

Interoperability context

• There is a pervasive mandate to achieve interoperability of donor-funded meHealth implementations

• Service-oriented designs allow “behavioural” interoperability to be de-coupled from the message constructs; message-based interoperability is achieved by the “HIX” layer supporting multiple message formats

• Interoperability is more readily achieved using Implementation Guide (IG) based specifications (e.g. IHE) vs. mere message specs (e.g. HL7v2)

8

Interoperability context

Service Pattern AInformation Model A

Service Pattern AInformation Model A

REST json

Service Pattern AInformation Model A

SOAP CDAr2

Service Pattern AInformation Model B

REST json

Service Pattern XInformation Model A

SOAP CDAr2

9

FRED v2 Targets

• Ideally, FRED v2 should…– Satisfy the use cases of RHEA phase 2

• Standards-based family of interlinked registries working together to support service functions in the HL7 spec document

• Conformant service API

– Provide a value proposition for new stakeholders and “set the table” for national infrastructure initiatives

– Embrace interoperability• Questions:

– How would we get from where we are now to a FRED v2 that satisfies those goals?

– What might this mean for current FRED project scope? How far will we be able to go?

10

RHEA phase 2

• CRUD for facility registry attributes• Runtime validation of facility codes

• Support referral logic– A care intervention requires a combination of

resources and/or caregivers • Where is the closest facility with the necessary

combination of resources and providers, and when?• When is the soonest the combination of resources and

providers can be found, and where?

11

Value to new stakeholders

• Facility registry CRUD– Consolidate data from disparate systems into a

national registry– Adopt and enforce standardized coding– Support rudimentary queries

• Support more sophisticated data management re: resources and resource calendars

• Support discussions re: healthcare enterprise architecture

12

Interoperability • HSD-based “behavioural” interoperability

spec– Service patterns

• Preconditions • End state• Error handling

– Information models• Required content• Optional content

• IHE-compatible Implementation Guide– Transport (REST, SOAP, etc.)– Payload (json, XML, etc.)– Data types– Code systems

13

Roadmap

FRED v1

1 2 3 4

FRED v2Adopt the HSD

information m

odel; develop a conform

ant API spec

Implem

ent conformant Facility Registry

and maybe Resource Registry ref. im

pl.

Implem

ent Provider Registry and O

rganization Registry services

Develop an IH

E profile; validate/ballot and successfully test at a Connectathon

Current FRED Project?

14

Roadmap

• HSD-based data model– Restrict focus to only the Facility and Resource data

dictionary specs (Appendix C: 17.1.28-17.1.46)– Specify data types and code system references

• HSD-based service model – Restrict focus to only the Location and Resource

registry functions– Specify message-level interactions (API)

• Transport • Payload (including data types and codes, as above)

1

15

Roadmap

• Develop FR/RR reference implementation conformant to the API specs from step 1

• Develop demonstrable client interfaces which consume the services [Reference Implementation]– Illustrate “HIX” based calls – demonstrate the ability for the twin

services to operate within the architectural context (e.g. RHEA infrastructure)

– Illustrate end-user applications using the services; provide example UI’s that put a “face” on the services

2

RESULT: A standards-based Facility Registry & Resource Registry pair comparable to FRED v1 with a solid underlying information/data model, and a conformant service API which is a subset of the full HL7 API (including rudimentary calendar features)

16

FRED V1.2 Milestone Deliverables

• Functional business requirements & use cases • API with Implementation Guide specification

(e.g. IHE) for facility registry and possibly resource registry

• Reference implementation – Host – Two subscriber examples

Leverage specifications from HL7 and Gap Analysis

17

Roadmap 3

Organization Registry

Resource Registry

Interlinked Registries

ReferralsQueue management

Resource planning

18

Roadmap

• Document lessons learned deploying the Interlinked Registry specification as an IHE Profile

• Undertake the IHE’s ballot process– Engage with the international implementer

community– Collaborate with multiple partners to demonstrate

and certify profile conformance at an IHE Connectathon

4

19

FRED V2 Milestone• FRED v2…

– Satisfies the use cases of RHEA phase 2 and contemplates even more functionality as Rwanda becomes ready for it

– Facility registry and resource registry can be related to two more registries (Provider and Agency/Organization registries) to provide the full suite of interlinked registry capability described in HL7 specifications

– Standards-based interlinked registry set that supports the service functionality described in the HL7 spec document

– Provides a value proposition for new stakeholders and “sets the table” for highly functional, architecture-based national infrastructure initiatives

– Demonstrates leadership regarding standards-conformant interoperability and gets us engaged with the IHE community as influential participants

20

Questions…

FRED v1

1 2 3 4

FRED v2[Needs new name]

Can we get to here with our existing FRED project resources/time?

Will resources become available to support the completion of and Connectathon

demonstration of an Interlinked Registry?Will require a separate concept note (by

IntraHealth & others?)

Current FRED Project?

Appendix: HL7 Interlinked Registries ERD