Standardized Medication Profile (SMP) FHIR IG
1.0.0-ballot - STU1 Ballot United States of America flag

This page is part of the US Standardized Medication Profile (SMP) (v1.0.0-ballot: STU1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. . For a full list of available versions, see the Directory of published versions

Formal Specification

Page standards status: Informative

This section of the implementation guide defines the specific conformance requirements for systems wishing to conform to Standardized Medication Profile implementation guide. The RESTful exchanges of resources is the primary means of information exchange but in some situations, a Bundle containing the primary Medication List resources and all of the reference SMP Medication Statements may optimize the exchange.

Context

Pre-reading

Before reading this formal specification, implementers should first familiarize themselves with two other key portions of the specification:

  • The Use Cases & Overview page provides context for what this formal specification is trying to accomplish and will give a sense of both the business context and general process flow enabled by the formal specification below.

  • The Technical Background page provides information about the underlying specifications and indicates what portions of them should be read and understood to have the necessary foundation to understand the constraints and usage guidance described here.

Conventions

This implementation guide uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:

  • SHALL indicates requirements that must be met to be conformant with the specification.

  • SHOULD indicates behaviors that are strongly recommended (and which may result in interoperability issues or sub-optimal behavior if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.

  • MAY describes optional behaviors that are free to consider but where there is no recommendation for or against adoption.

Systems

This implementation guide sets expectations for both clients and servers during the transition of care and the exchange of Standardized Medication Profiles. In a transition of care, one FHIR Server for an organization may act as a client to a FHIR Server for a second organization (with additional system configurations and intermediaries possible). For the use case where the organization responsible for patient following the transition is known, the pre-transition organization may push information to the destination. In all cases, the pre-transition organization must be able to support queries for previous medication lists.

Profiles

This specification makes significant use of FHIR profiles and terminology artifacts to describe the content to be shared as part of prior authorization requests and responses.

The full set of profiles defined in this implementation guide can be found by following the links on the Artifacts page.

Integration with other Implementation Guides

  • Along with the profiles defined in the SMP implementation guide, implementations SHALL also support the US Core R4 profiles for Patient, Practitioner, PractitionerRole, Condition, and Allergy. They SHOULD support any other profiles relevant to the transition process (this includes other implementation guides such as PACIO Personal Functioning and Engagement, other guides will be identified in the forthcoming Transitions of Care IG).

Detailed Requirements

Summary

The primary interaction supported by this implementation guide is POST and GET

The interactions can be comprised of completely RESTful operations for the storage and retrieval of resources but there are situations where the submission of a transaction Bundle containing the primary List resource and all of the associated MedicationStatement resources would be appropriate.

The first entry in the Bundle SHALL be a List resource complying with the MedicationList defined in this IG to ensure the content is sufficient to appropriately populate a full medication list.

All GUIDs used SHALL be unique, including across independent prior authorization submissions - with the exception that the same resource instance being referenced in distinct prior authorization request Bundles can have the same GUID.

All resources SHALL comply with their respective profiles. FHIR elements not marked as 'must support' MAY be included in resources, but client systems should have no expectation of such elements being processed.

This IG treats everything that happens beyond the defined operations endpoint receiving the FHIR bundle as a black box. This black box includes any business associate(s), clearinghouse(s), payers, contracted review entities, and other intermediaries that may be involved in the PA request and response. It is up to that black box to ensure that any regulatory requirements are met and to perform all processing within the allowed timeframe.

All transactions in SMP are synchronous and SHALL require one of the following HTTP responses:

HTTP Responses
  • 2XX – transaction submission succeeded
  • 4XX – transaction failed – bad request - failures are not recoverable by resubmission of the transaction. There will be an OperationOutcome returned that can be reviewed to determine the actual failure
  • 5XX – transaction failed – service unavailable or timeout - failures that may be temporary and resubmission may result in successful processing. NOTE that no OperationOutcome will be returned in this instance

If an OperationOutcome is received, it may have information regarding errors that should be addressed in the future, but did not cause the transaction to fail. NOTE: These errors should not be returned to the provider but should be reviewed and addressed by technical staff.

OperationOutcome Data Elements
Element Cardinality Datatype Information
Severity 1..1 code fatal, error, warning, information
Code 1..1 code IssueType
Details 0..1 CodeableConcept additional code that clarifies the issue type
Diagnostics 0..1 string addl information (response from validation, TA1, 999)
Expression 0..* string FHIRPath of element(s)

SMP Workflow Diagrams

Using the base use case scenarios, the following diagrams show the information flows across multiple transitions of care and the use of the SMP profiles to support and enhance the information exchange

The abbreviations that appear in the following workflows are defined as:

Abbrev. Expansion
EHR Electronic Health record system
HDM Health Data Manager (a repository or exchange to help locate a patient's records)
HHA Home Health Authority
SNF Skilled Nursing Facility

A: Home - Pre-stroke

A placeholder
Figure A.1 - Home Health recording medications




Figure A.2: HomeSocial WorkerSocial WorkerFieldAppFieldAppHealth DataManagerHealth DataManagerCollect medication infoPOST SMP-Bundle-Tx(Medication List and Medication Statements)ConfirmationAdd new medicationsPOST SMP-Bundle-Tx(updated list and Medication Statement)Confirmation

In the initial diagram the capture of the patient medications, including both prescription and non-prescription items is performed and the information is record via a List resource and MedicationStatement resources as needed

B: Hospital

A placeholder
Figure B.1 - Admission to Hospital following stroke



Figure B.2: Hospital TreatmentCare TeamCare TeamHospital EHRHospital EHRHealth DataManagerHealth DataManagerRequest medication infoGET SMP-Bundle (Query)existing Medication ListsMedication Orders for patientGenerate Administration Medication Listloop[for each order]Add order to Admin listRevise orders (as necessary)


Following the stroke event the patient is admitted to hospital, previous medications (via the list created in A.1) are reviewed and based on treatment, the hospital administration list is created. When the patient is stabilized and ready for discharge to the rehabilitation facility, the discharge list is created.

Figure B.3: Hospital DischargeCare TeamCare TeamHospital EHRHospital EHRHealth DataManagerHealth DataManagerSkilled Nursing FacilitySkilled Nursing FacilityDefine medications for dischargeGenerate Discharge Medication Listloop[for each medication]Add medication to Discharge listalt[Connection to HDM]POST SMP-Bundle-Tx (Discharge Medication List)[Connection to SNF]POST SMP-Bundle-Tx (Discharge Medication List)


C: Skilled Nursing Facility (SNF) - Rehabilitation

A placeholder
Figure C.1 - Admission to SNF for Rehab



Figure C.2: SNF AdmissionSNFCare TeamSNFCare TeamSkilled Nursing FacilityEHRSkilled Nursing FacilityEHRHealth DataManagerHealth DataManagerRequest medication infoalt[Previous Lists are requested]GET SMP-Bundle (Query)The Hospital DischargeMedication List may beavailable at the SNF butother lists including theDiscontinued Medicationsmay form part of this queryexisting Medication ListsMedication Orders for patientGenerate Administration Medication Listloop[for each order]Add order to Admin listRevise orders (as necessary)


The hospital discharge list is reviewed and revised to create the administration list for the Skilled Nursing facility (SNF). This list is updated during the patients stay in the facility. As medications are removed from the administration list, they are added to the discontinued medication list.


Figure C.3: SNF DischargeSNFCare TeamSNFCare TeamSkilled Nursing FacilityEHRSkilled Nursing FacilityEHRHealth DataManagerHealth DataManagerHome Health AuthorityEHRHome Health AuthorityEHRCommunityPharmacyCommunityPharmacyDefine medications for dischargeGenerate Discharge Medication Listloop[for each medication]Add medication to Discharge listalt[Connection to HDM]POST SMP-Bundle-Tx (Discharge Medication List)[Connection to HHA]POST SMP-Bundle-Tx (Discharge Medication List)[Connection to Community Pharmacy]POST SMP-Bundle-Tx (Discharge Medication List)


When rehabilitation in the SNF is complete the patient is ready to be returned to the home setting. Here the care team at the SNF prepare the SNF Discharge Medication list.

D: Return to Community/Home

A placeholder
Figure D.1 - Return to Community/Home Health



Figure D.2: Return to Home CareHHACare TeamHHACare TeamHHAEHRHHAEHRHealth DataManagerHealth DataManagerRequest medication infoalt[Previous Lists are requested]GET SMP-Bundle (Query)The SNF DischargeMedication List may beavailable at the HHA butother lists including theDiscontinued Medicationsmay form part of this queryexisting Medication ListsRevise orders (as necessary)


Back in the community, the home care team for the patient review the discharge medication list from the SNF (and may also review previous administration lists and the discontinued medication list), making any recommendations as appropriate and create the new home medication list.

E: Medication Reconciliation in the Community

A placeholder
Figure E.1 - Medication Reconciliation in the Community



Figure E.2: Fill Medications in CommunityCommunityPharmacistCommunityPharmacistPharmacySystemPharmacySystemHHAEHRHHAEHRHealth DataManagerHealth DataManagerCaregiverCaregiverHome MedicationsMedication Orders and theHome Medication Listmay be pushed to thecommunity pharmacy ondischarge from SNFRequest medication infoRequest Prior medication listsQuery - MedicationList by PatientMedicationListsMedication Historymedication reconciliationMake order recommendationsOrder recommendationsRequest Medicationinformation from portal


The Primary caregivers go to the community pharmacy, the home care team for the patient review the discharge medication list from the SNF (and may also review previous administration lists and the discontinued medication list), making any recommendations as appropriate and create the new home medication list. The community pharmacist provides the medications to the caregiver with instructions, the caregiver can also the current home medication list from the patient portal of the Home Health Authority system.

Testing Requirements

It is the intent of this implementation guide to provide specifications for the exchange of medication information in a way that is conducive to developing test scripts and a reference implementation (RI) that can be used to validate/exercise the IG at connectathons and during piloting and production deployment. It is also the intent of this guide that any test scripts will include testing of:

  1. resources and profiles defined in this guide
  2. artifacts used from referenced IGs such as:
  3. testing of conformance to the underlying FHIR standards for the associated release (e.g. FHIR R4)