Logical model for medication prescription (or some other form of order)

Business identifier(s) for the prescription

Identifier for the group that this prescription belongs to. This might be the common identifier in use cases where one national prescription contains several medication items, which can be handled as separate orders

Time of authoring the prescription/draft in the information system

Time of issuing (signing) the prescription by health care practicioner

The recorder of the prescription/draft in the information system

Question: would we want to add basic Practicioner model?

Category or categories of prescription. For example type of reimbursement, or type of prescription (e.g. hospital, private, etc).

Effective date of the prescription. The prescription is not dispensable before this date. In most cases this information repeats issueDate

The validity period end date. The prescription is not dispensable after this date.

Question: would we want to add basic Patient model?

Status of the prescription, this should not be status of treatment

Reason for the current status of prescription, for example the reason why the prescription was made invalid

Textual reason for the current status of prescription

Prescribed product, branded, generic, virtual, extemporal, etc

Reason for the prescription (typically diagnosis, or a procedure)

Reason for the prescription in textual form. This might not be allowed by some implementations.

Period over which the medication is to be taken (in case of multiple dosaging schemes, this would be the overall period of all dosages.)

Dosaging and administration instructions

Additional instructions about preparation or dispense

Whether and which type of substitution is allowed for this medication treatment line

Whether substitution is allowed or not.

The type of substitution that is allowed.

Reason for the substitution requirement

Additional information or comments

Logical model for medication prescription (or some other form of order)

Business identifier(s) for the prescription

Identifier for the group that this prescription belongs to. This might be the common identifier in use cases where one national prescription contains several medication items, which can be handled as separate orders

Time of authoring the prescription/draft in the information system

Time of issuing (signing) the prescription by health care practicioner

The recorder of the prescription/draft in the information system

Question: would we want to add basic Practicioner model?

Category or categories of prescription. For example type of reimbursement, or type of prescription (e.g. hospital, private, etc).

Effective date of the prescription. The prescription is not dispensable before this date. In most cases this information repeats issueDate

The validity period end date. The prescription is not dispensable after this date.

Question: would we want to add basic Patient model?

Status of the prescription, this should not be status of treatment

Reason for the current status of prescription, for example the reason why the prescription was made invalid

Textual reason for the current status of prescription

Prescribed product, branded, generic, virtual, extemporal, etc

Reason for the prescription (typically diagnosis, or a procedure)

Reason for the prescription in textual form. This might not be allowed by some implementations.

Period over which the medication is to be taken (in case of multiple dosaging schemes, this would be the overall period of all dosages.)

Dosaging and administration instructions

Additional instructions about preparation or dispense

Whether and which type of substitution is allowed for this medication treatment line

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Whether substitution is allowed or not.

The type of substitution that is allowed.

Reason for the substitution requirement

Additional information or comments

Logical model for medication prescription (or some other form of order)

Business identifier(s) for the prescription

Identifier for the group that this prescription belongs to. This might be the common identifier in use cases where one national prescription contains several medication items, which can be handled as separate orders

Time of authoring the prescription/draft in the information system

Time of issuing (signing) the prescription by health care practicioner

The recorder of the prescription/draft in the information system

Question: would we want to add basic Practicioner model?

Category or categories of prescription. For example type of reimbursement, or type of prescription (e.g. hospital, private, etc).

Effective date of the prescription. The prescription is not dispensable before this date. In most cases this information repeats issueDate

The validity period end date. The prescription is not dispensable after this date.

Question: would we want to add basic Patient model?

Status of the prescription, this should not be status of treatment

Reason for the current status of prescription, for example the reason why the prescription was made invalid

Textual reason for the current status of prescription

Prescribed product, branded, generic, virtual, extemporal, etc

Reason for the prescription (typically diagnosis, or a procedure)

Reason for the prescription in textual form. This might not be allowed by some implementations.

Period over which the medication is to be taken (in case of multiple dosaging schemes, this would be the overall period of all dosages.)

Dosaging and administration instructions

Additional instructions about preparation or dispense

Whether and which type of substitution is allowed for this medication treatment line

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Whether substitution is allowed or not.

The type of substitution that is allowed.

Reason for the substitution requirement

Additional information or comments