2021-01 Vulcan - Medication Definition

Rik Smithies rik@nprogram.co.uk>; Peter Bomberg pbx@soundfound.com

The recording of the session is here: Vulcan Medication Definition Orientation 2020-12-17.mp4

Objectives

The intent of the Connectathon track is twofold:

To enable the FHIR community to familiarize themselves with the Medication Definition resources and to get advice from the participants on the usage, direction, and any other resource related question they may have.

Additionally, to enable the participants to ensure that the approach and models being used to represent the resources meets the business objectives.

The description of detailed product or product related information, including the products themselves, packages, the actual drug items (e.g., tablets), and ingredients, as well as aspects related to regulation of products.

To assist the server will be populated with examples that can freely be used as starting points.

Log the data items that have been used here (should not need a login):

Ideas

The participants are encouraged to work with the resources in any way they would like, some potential ideas have been listed below as inspiration.

• Create a product and associate package definitions to the product
• Create a Substance Definition
• Create a links between product(s), ingredient(s) and substance(s)
• Update an existing product to increase the scope or details, such as adding additional package types
• Create regulated authorizations

Connectathon Scenario

To further/mature the Medication Definition resources scenarios that fully or partially represent medicinal products should be tested during the Connectathon. The intent is gain general experience with the resources thereby identifying issues and concerns.

This would be done by creating /updating one or more of the following resources, any of the following can be used and the step number does not represent an order it is solely included to assist with references, as in some cases the attributes point to existing resources and some aspects of the resources build upon other resources.

1. MedicinalProductDefinition
   1. Optionally browse the server for existing product data
   2. Create your own product, using provided example data, or your own, to populate as much content as possible.
      Examples: product names, dose form, classifications, characteristics, legal status, manufacturers, relationships to other products and so on. Note that some data can be described using other linked resources, as below.
   3. Track leads and other participants can advise on mappings
   4. Resources can be reviewed by others, in XML format (or JSON)
   5. Resources can be uploaded to the server(s) where they can be viewed, downloaded and reviewed by others
   6. Repeat for other products
   7. Extend the product definition using other linked resources, as below
2. PackagedProductDefinition
   1. Add a package description to a product from step 1
   2. Use provided data, or your own to populate as much data as possible
      g., just the basics – the name of a package (e.g., “WonderDrug 20mg 50 tablet pack”), or the full package configuration (using PackagedProductDefinition.package) to show pack contents, materials etc.
   3. Usually the package references (“links to”) the MedicinalProductDefinition using PackagedProductDefinition.subject
   4. Upload this to the server, review.
   5. Repeat for another package type for the same product, or a different one.
3. ManufacturedItemDefinition
   1. Add a manufactured packaged item (e.g., a tablet, liquid, or co-packaged device) to the package from step 2. Upload, review, repeat etc
4. Ingredient
   1. Add an ingredient to a manufactured item from step 3 (via PackagedProductDefinition.package.containedItem) , or directly to a product (from step 1) using MedicinalProductDefinition.ingredient
5. SubstanceDefinition
   1. Add a substance definition and optionally link to the Ingredient from step 4
6. AdministrableProductDefinition
   1. Add a resource describing the “ready to administer” form of the product and link it to the product from step 1 via administrableProduct.product (or by using AdministrableProductDefinition.subject)
7. RegulatedAuthorization 
   1. Add the record of a regulated authorization and link it to the relevant product or substance definition from step 1 or 5 respectively using RegulatedAuthorization.subject.
   2. Establish observations on a facility resource and then adding a RegulatedAuthorization to describe them. This represents a simulated site inspection and the results.
   3. Try applying for licences relating to controlled substances, regulated parties, or regulated activities.
8. ClinicalUseIssue
   1. Add information related to an indication or contraindication for the product.
9. DeviceDefinition
   1. Add information related to a device accompanying the administrable product and assign it to the packaged product as well as a contained item.

Data

Due to the information access model on this Proof of Concept environment it is critical that everyone uses artificial information (i.e. no real people, products, organizations, etc. should be included in the information provided or used).

Security and Privacy Considerations:

The server requires a login.  A number of free accounts have been created and will be issued to participants. Please ask for one if you need it.