Stream: argonaut
Topic: Approved and Proposed Changes to the Vitals Signs Profile
Eric Haas (Oct 23 2017 at 00:59):
Since the US Core is derived from Argonaut data query and US Core reference the FHIR Vitals Profile. I wanted to may everyone aware of several changes that have been proposed and some approved to the Vitals profile. Some are technical and some cut to the very core of the profile... Your comments and feedback are welcome as we move forward with both US Core Profiles and FHIR R4
Approved changes to Vitals Profile
-
GF#13897 Will change invariant vs-4 to slicing using the fixed values for category.system and category.code as a discriminator. technical change and should have no net effect on validation.
-
GF#13796 (Reopen and reconsider) Will propose loosen the constraint on .related to any allow any Observation and any value type and add constraint to vitals panel using slicing with a discriminator on the profile. net effect allow related observations which don't conform to vitals profile.
Pending trackers
-
GF#14037 vitals profile fixes type to 'member-of' propose to remove constraint here and add to vitals panel as slice discriminator see GF#13796 above. net effect allow related observations which are are different types such as "derived-from"
-
GF#13964 Add system (in addition to code) as discriminator for code slicing . There could be a need for multiple codes with the same value from different systems. technical change and should have no net effect on validation unless you have identical codes from different code systems
- These are the most controversial in terms of US Core. -
-
GF#13801 The proposal is to remove body length since is a specialization of height and could be captured as a more specific translation on height. Nutrition folks have express concern in removing it since they use length a lot for early childhood calculations. One option is to carve out of FHIR core and add to US Core....
-
GF#13652 - This one is a pitted battle with the HL7 Devices WG who propose to remove the requirements of the LOINC reference codes since they prefer to use MDC codes. Published mappings to MDC and the LOINCs have been suggested to mollify and allow for translations but there is still a lot of resistance due to the nature of highly regulated devices using firmware and their own set of standards. If the LOINC constraints are relaxed then we will need to decide whether to go along with that or create own profile in US Core keeping the codes intact.
Last updated: Apr 12 2022 at 19:14 UTC
