1. 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 2

3. Project context 3 RHEA Phase 1FRED v1FRED 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. 4

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 5

6. Architectural context 6 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) 7

8. Interoperability context 8 Service Pattern A Information Model A Service Pattern A Information Model A REST json Service Pattern A Information Model A SOAP CDAr2 Service Pattern A Information Model B REST json Service Pattern X Information 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? 9

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? 10

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 11

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 12

13. Roadmap 13 FRED v1 1 2 3 4 FRED v2 Adopt the HSD information model; develop a conformant API spec Implement conformant Facility Registry and maybe Resource Registry ref. impl. Implement Provider Registry and Organization Registry services Develop an IHE 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) 14 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 15 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 16

17. Roadmap 17 3 Organization Registry Resource Registry Interlinked Registries Referrals Queue 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 18 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 19

20. Questions… 20 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?) 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?

21. Appendix: HL7 Interlinked Registries ERD