Ooof. Totally legit questions, which I don’t have complete answers for yet. I published a super basic plugin last night, so lets do what we can.
Q: Wow a plugin architecture are you kidding? That is awesome.
Nope, took a while to figure out. Thank you.
Could you tell me what are the 4 plugins you have built in meteor-on-fhir?
symptomatic-videoconferencing #core; incomplete
symptomatic-continuity-of-care #core; incomplete
uhs-calculator #proprietary; client; incomplete
As you can see, we’re only just now beginning to refactor things into plugins. And we haven’t figured out naming conventions, namespaces, etc. But it does support public/private repositories, and provides a way for people to ‘own’ their workflow while using and supporting a common data layer.
Q: Just a little direction would be helpful so I could find the plugins in the codebase and see what you did.
Pull from the latest
development branch, and look at meteor-on-fhir/webapp/packages/plugin-default-landing-page
Q: What kinds of things could we add onto the system with a plugin?
We’re still in the very early stages of the plugin pattern, so I’ve only got page routes set up so far. But menu elements, action buttons, and more will be coming within the next quarter. If I get funding and support, I’d be happy to roll those features out sooner. And I’ll be happy to accept pull requests.
Regardless, here are the relevant files to that compose the plugin pattern:
With those 3 files, a package can expose React components and routes into the app dynamically.
Q: Pages, menu elements?
Yeah, the idea is that we’ll be using that Package scanning approach, and exposing more components via packages. The plan is to support the following arrays:
Q: Also, which config file is the one that we could customize?
Look in the webapp/configs/settings.dev.json is a good place to start.
Q: What kinds of things can we change with change in the config file?
defaultVideo will override the
backgroundImagePath. Generally speaking I’ll always accept pull requests that expand support for
darkroomTextEnabled. There’s a minimally used
palette field also.
Displays sections on the landing page.
Deprecated in favor of
Shows avatars in Patient and Practitioner menus.
Displays mongo _ids as 3 of 9 barcodes in tables.
Experimental hexgrid gamification menu.
Displays the orbital by default. Will eventually be used to display NFC device proximity.
Displays alerts and notifications in the navbar.
Display the searchbar by default. Sometimes used during mobile app layouts.
Display the header and footer navars by default.
Disable the header navbar. Rarely used.
Disable the footer navbar. Useful for scrolling mobile apps, landing webpages, etc.
Inverts the cards for darkroom usage (i.e. radiology apps).
Enabled the slide-in context frame.
Set the default context URL. Popular entries include Wikipedia, Darmouth Health Atlas, and Zygote Avatar.
How many rows should be showed in tables by default.
How many records should be prefetched to the client by default. Important. Adjust this based on your target audience devices. I.e. set lower on mobile devices and laptops; set higher for workstations).
Set the default card opacity level.
The default outbound interface endpoint. Generally the upstream EHR and default FHIR datawarehouse that Meteor on FHIR will be querying from.
The upstream node that a node should sync with. Right now, only supports syncing Organizations. We plan synchronizing default Medicare/Medicaid data through the mesh network; and will eventually be supporting IPFS.
Right now, set to once daily I think.
Enables the data management page.
Enables the Query Epic buttons on some FHIR resources.
Everything under the modules selection will turn on/off a card and subsequent route in the system. Eventually, this will be hooked into the plugin system. But for now, it’s sort of hardcoded. The items in
fhir are much more active than the
modules directory, which is getting a bit stale. Some of these are effectively deprecated.
Turns on/off the app cards in the main index.
Turns on/off the FHIR cards in the main index. Will also enable/disable FHIR REST endpoints.
Default invite code for enrolling a practitioner.
Default invite code for enrolling an admin.
Disables security for testing REST endpoints. Do not use in production.
Clears the database every 24 hours.