Details
-
New Feature
-
Status: Closed
-
Non-Essential
-
Resolution: Fixed
-
None
-
None
-
Medium
Description
(Epic Story: work should be done on sub-tickets.)
As visits are added to the data model (TRUNK-48), we know that there are going to be many different needs for visit details across implementations. For example, HL7 has evolved to having two visit segments (PV1 and PV2) with over 100 visit attributes. These could include account or billing information, patient disposition, length of stay, etc.
Rather than trying to anticipate and hardcode every possible need into the data model, we would like to add "visit attributes" to the model just as we have done with person attributes.
Approximate design:
visit_attribute_type visit_attribute_type_id name description handler visit_attribute visit_attribute_id visit_id visit_attribute_type_id value
The VisitAttributeTypeHandler could perform functions such as:
- Optionally provide choices
- Provide input constraints - e.g., allowable pattern(s)
- Validation - e.g., for the value itself and/or allowing or preventing repeats or duplicates
Gliffy Diagrams
Attachments
Issue Links
- depends on
-
TRUNK-48 Add 'Visit' to data model
-
- Closed
-
-
TRUNK-2243 Add AttributeTypeHandler to the API, which can be used by multiple classes that need to support user-defined Attributes
-
- Closed
-
-
TRUNK-2244 Domain object, liquibase, and hibernate mapping for VisitAttributeType
-
- Closed
-
-
TRUNK-2245 Service and DAO for VisitAttributeType
-
- Closed
-
-
TRUNK-2246 Domain object, liquibase, and hibernate mapping for VisitAttribute
-
- Closed
-
-
TRUNK-2247 Update Visit to include VisitAttributes
-
- Closed
-
-
TRUNK-2249 Management Visit Attribute Types pages
-
- Closed
-
- is depended on by
-
TRUNK-2134 Refactor PersonAttributeType to use a "datatype" and "handler_config" instead of a "format"
-
- Closed
-
- mentioned in
-
Page Loading...