Stream: implementers
Topic: Vital signs profile
Richard Kavanagh (Jan 17 2017 at 22:07):
I think I previously mentioned on here my disappointment on the mandatory use of LOINC codes in Vital Signs observations. It seems to have fallen on deaf ears.
Today I notice that there is also a mandatory requirement to expose a number of VitalSign related searches - why?
Grahame Grieve (Jan 17 2017 at 22:08):
yes you did
Richard Kavanagh (Jan 17 2017 at 22:10):
If we are using Vital Signs in a document or messaging based solution , how does that work?
Lloyd McKenzie (Jan 17 2017 at 22:22):
@Richard Kavanagh They weren't deaf ears, but they were somewhat unsympathetic to the arguments as presented. The benefits of requiring everyone to support LOINC outweigh the incremental cost of mapping from existing code systems to meet the requirement.
I agree that the wording on the search parameter requirements should make clear they only apply to RESTful services - please submit a change request. And I'm somewhat more sympathetic to concerns about mandatory search behavior. There may be some services that only support a single type of vital sign and aren't capable of more than "what's happened since some date-stamp" or something - those would still be valid and useful services. The criteria here seem to only make sense for EHRs or other general repositories of vital sign information. While that might be the primary focus of attention right now, it's far from the only type of vital signs server that could exist. So I'd be in favor of tightening the scope this applies to for servers. And I'd be in favor of eliminating requirements for clients entirely. Clients shouldn't be required to support a query unless their user interface or requirements drive them to need such a query.
Grahame Grieve (Jan 17 2017 at 22:25):
where do we say these requirements?
Richard Kavanagh (Jan 17 2017 at 22:26):
Well that's unfortunate. Whether RESTful or not we will not be supporting this in the NHS. We are just going to have to be knowingly non conformant in this area. I absolutely do not see how HL7 can mandate terminology and functionality. This is a worrying precedent with FHIR and seems show little regard to affiliate requirements.
Alexander Henket (Jan 17 2017 at 22:31):
I feel that mandating a free, recognized and international system actually helps global interoperability on a very typical use case. We intend to use the profile as-is. What's the alternative? Local stuff? SNOMED CT?
Richard Kavanagh (Jan 17 2017 at 22:37):
Well within England we by policy mandate the use of SNOMED CT and as such would expect to use that as our query terminology. Having the requirement to support LOINC introduces confusion in to our national systems as LOINC is not used nationally. Additionally when using vital signs profiles in a messaging or document scenario (which will have no RESTful capability) also does not appear to make sense. Additionally we have the issue of the definition of what a vital sign is, we may have different observation which we deem to be vital signs and then they would have different characteristics than the ones defined by the US Argonaut project.
Lloyd McKenzie (Jan 17 2017 at 22:40):
@Richard Kavanagh You're free to mandate SNOMED CT. That's not in conflict with HL7 mandating LOINC - systems can support both. And in doing so can ensure interoperability of essential information outside the UK environment. Certainly I'd hope that the NHS wouldn't prohibit implementations from choosing to be FHIR compliant while still meeting NHS's requirements if they want to send both.
Angelica Garcia Gutierrez (Jan 18 2017 at 18:13):
Based on the discussion thread above, if I need to record vital signs using a code system other than LOINC e.g. CPT CAT II 3074F then I am not going to be able to use the Observation vital signs profile and instead create my own profile? is my understanding correct?
Lloyd McKenzie (Jan 18 2017 at 18:17):
You can create another profile, but you could comply with both - i.e. send codes from both code systems. That would be FHIR's expectation
Angelica Garcia Gutierrez (Jan 18 2017 at 18:26):
@Lloyd McKenzie If I create another profile, can I then record vital signs using LOINCs, SNOMEDs, CPTs? or for the case of LOINCs these MUST be recorded in the HL7 vital signs profile?
Grahame Grieve (Jan 18 2017 at 18:35):
we expect that you'll use additional codings to refine/clarify the meaning of observation, or to provide additional translations. But whatever you do, you carry the base LOINC code so that everyone can search for and correctly recognise all the vital signs
Lloyd McKenzie (Jan 18 2017 at 19:24):
So all Observation instances that contain vital signs covered by the HL7 must be compliant against the vital signs profile. However, that doesn't keep you from sending any *additional* codes or elements you wish.
Jonathan Shultlis (Jan 18 2017 at 20:18):
I don't see how mandating LOINC, or any other coding system, eliminates the need for handling multiple code definitions and code mapping, given that code systems (including LOINC) are regularly, and extensively, revised. If systems have to handle data using multiple coding systems, does it really matter whether they are called LOINC-xx and LOINC-yy or SNOMED-zz? Yes, the data is different, and the fewer the coding systems that need to be supported, the better. And yes, often the versions in some coding systems are close, but consider the history of the ICD and DSM codes, where different versions might as well be different systems. Also, if a realm wants to mandate use of a coding system, there is a mechanism for that, but does it belong in the standard?
Richard Kavanagh (Jan 18 2017 at 20:34):
@Jonathan Shultlis I agree. There seems to be a general misconception that if a system receives a resource with a coding that is alien to the code-system that it is designed to use, then it will not only store it for further use but will then also make a RESTFul api available for systems to access that data by. I know that for some systems that might be OK but in my jurisdiction all that would happen is that the receiving system would throw it away. Given that mappings between LOINC and the systems native code-system can be created then if required a system can expose an interface based on LOINC in any case.
Grahame Grieve (Jan 18 2017 at 21:38):
there is no such misconception. This has nothing to do with what happens inside a system. Nor is there any belief that mandating a single LOINC code will mean that there a no other codes, even no other LOINC codes.
Grahame Grieve (Jan 18 2017 at 21:39):
All this is is a statement that theose LOINC codes are used to identify those vital signs on the API, irrespective of where you are (since we expect that vital signs will be shared widely across jurisdictional boundaries in patient repositories), and that also, should you wish to access those vital signs, you can query using those LOINC values.
Grahame Grieve (Jan 18 2017 at 21:41):
systems that don't use LOINC internally don't need to store LOINC internally; they are simply required to be able to identify these vital signs, and mark them accordingly if they expose them
Grahame Grieve (Jan 18 2017 at 21:41):
in practice, we expect vital signs observations to be coded twice - once with the base loinc code, and once with a more specific code (which ever code system it comes from).
Grahame Grieve (Jan 18 2017 at 21:43):
in practice, we could have chosen FHIR assigned magic values, or SNOMED magic codes, or LOINC magic codes. We chose LOINC because this aligns with the most countries. But they are simply magic values and it's fine to treat them as such.
Sadiq Saleh (Jan 19 2017 at 21:19):
I was just wondering about the construction of the webpage for the vital signs profile as it seems to be quite distinct from the standard pages generated for profiles by the build tool.
Is there a way to generate a similar page for grouping profiles of a disease for example (e.g. cancer specific profiles which have a similar overall structure but would have differing codes and constraints)?
Thanks in advance,
Eric Haas (Jan 19 2017 at 22:00):
That page is not an autogenerated page but all hand edited as it is a one-off page. For a view of a Profile page being generated by the IG-publisher tool see the US-Core This is a combination of autogenerated and hand generated narrative including tables.
Sadiq Saleh (Jan 19 2017 at 22:43):
Thanks for the response @Eric Haas
Rob Hausam (Jan 19 2017 at 22:47):
Grahame mentioned that "in practice, we could have chosen FHIR assigned magic values ...". From discussions I've had it appears that would be preferable for the UK. FHIR codes are supported (generally) by everyone using FHIR, whereas LOINC codes, even though broadly supported, still aren't universal. And since in practice we're treating them as "magic values", might it not be best to use FHIR-defined codes for anything that we mandate, and then map to LOINC (or SNOMED CT, or anything else)?
Grahame Grieve (Jan 19 2017 at 23:07):
I think that equates to 'make it harder for everyone else who uses LOINC' because a few countries would have a cosmetic preference agnainst LOINC.
Grahame Grieve (Jan 19 2017 at 23:09):
but as soon as we have enough specific things to say about particular use cases, we should consider having a page. @Sadiq Saleh have you seen http://build.fhir.org/resourceguide.html ?
Eric Haas (Jan 19 2017 at 23:09):
That means no ( Says Captain Barbosa) :-)
Sadiq Saleh (Jan 19 2017 at 23:19):
@Grahame Grieve thanks for directing me this to the page, it definitely clarified some things I did not know before, especially w.r.t. the timing association of the resources. However it does not quite answer my use case, or maybe I am missing something?
We are basically trying to make condition profiles similar to the diagnosticrequest profiles you had shared previously (http://fhir.hl7.org.au/fhir/rcpa/prostate.html) where there is a common theme to the profiles with nuances specific to each cancer type and trying to figure out the best way to do so.
Grahame Grieve (Jan 19 2017 at 23:26):
it doesn't deal with your use case, but it's similar. There's an Australia IG around strutured reporting for Prostate Cancer - see http://fhir.hl7.org.au/fhir/rcpa/index.html - but that's also not quite the same. In practice, Clinical Modeling like this is running a long way behind the FHIR platform, partly because people interested in 'clinical modelling' are mainly pursuing a perfect methodology rather than focusing on getting clinical profiles into FHIR. But also for many other reasons - lack of consensus engagement, the size of the task, the difficulty of the domain....
Rob Hausam (Jan 20 2017 at 00:00):
@Grahame Grieve @Eric Haas How much do we know about what percentage of vital signs instance data that is actually being exchanged is using the particular LOINC codes specified in the VS profile (assuming that LOINC codes are being used at all at present)? If an instance has chosen a different LOINC code, then it will have to be mapped to the profile-specified code, so in that case it wouldn't be any more difficult to map to a FHIR code than to another LOINC code.
Grahame Grieve (Jan 20 2017 at 02:41):
right, it's probably about the same to use a FHIR code instead of a LOINC code for writing. But if you know how to interpret LOINC codes - most do - then LOINC would be preferable, no?
Rob Hausam (Jan 20 2017 at 12:53):
It may be preferable, but probably not strongly so. It would be good to get some implementer input (from those who use LOINC, and those who don't).
Eric Haas (Jan 21 2017 at 05:23):
This issue was supposedly put to bed at the last (Baltimore) WGM. With the deadline for getting STU3 out the door. I feel it is an untimely and unnecessary distraction.
Josh Mandel (May 11 2017 at 16:59):
I'm looking at http://hl7.org/fhir/vitalsigns.html and it seems to be a profile for a single vital sign (a heart rate, or a respiratory rate, or a BP). Someday I'm hoping we might define a profile for a set of vitals altogether. I'm planning to suggest that we rename the existing material to "Vital Sign" unless somebody thinks this is a bad idea...
Grahame Grieve (May 11 2017 at 17:08):
http://build.fhir.org/vitalspanel.html
Josh Mandel (May 11 2017 at 17:15):
Thanks @Grahame Grieve! (For anyone following along, clicking "Profiles" at the top of the spec --> https://www.hl7.org/fhir/profilelist.html --> "Vital Signs Profile". Which in turn links out to a bunch of individual structure definitions.)
Eric Haas (May 12 2017 at 05:35):
I thought it would be handy to profile each vital sign including the panel and present it all in a single table, but if the layout is confusing or misleading any suggestions to make it clearer are appreciated. also to gather a bunch of heart rates, for example, look at the LastN operation
Eric Haas (May 12 2017 at 05:36):
....Suggestions via gforge trackers
Pranitha Sruthi (Aug 10 2017 at 05:12):
Hi all, while creating profiles for some of the vital signs namely fluid intake and output, girth etc, am using the observation resource. Do I have to use the vital-signs profile instead of observation resource? Please let me know. Thank you
Eric Haas (Aug 10 2017 at 14:54):
profile are for the observations listed in profile documentation
Richard Townley-O'Neill (Jul 30 2018 at 04:51):
Should the profiles based on VitalSigns have the same name and title as VitalSigns? For example BodyWeight.
Martijn Harthoorn (Jul 30 2018 at 14:01):
@Richard Townley-O'Neill - No. The name and title should be specific to the derived profile. Take for example: https://simplifier.net/FinnishPHR/fiphr-bodyweight-stu3/~xml. I think the bodyweight from the spec is wrong.
Richard Townley-O'Neill (Jul 31 2018 at 00:07):
Jira issue #17571 created
Lloyd McKenzie (Jul 31 2018 at 00:45):
You had me panicking for a second. We're not on Jira yet... :)
Richard Townley-O'Neill (Jul 31 2018 at 01:00):
:flushed:
GForge issue #17571 created
Eric Haas (Jul 31 2018 at 03:08):
Ok got it.
Richard Townley-O'Neill (Jul 31 2018 at 04:43):
STU3 has a profile of Observations called VitalSigns. There are many profiles based on VitalSIgns, including BodyHeight. These profiles slice Observation.code.coding by code, but the slices leave Observation.code.coding.code optional. In R4 BodyHeight Observation.code.coding.code is 1..1. This is what I expected.
I think that the STU3 slicing is inadequate, as an instance without a value for Observation.code.coding.code would satisify the discriminator. So an instance could satisify both BodyHeight and BodyLength profiles.
This means that references to STU3 VitalSigns cannot be sliced on profile.
I'm using STU3 and want to slice MedicationRequest.supportingInformation to create one slice for body height and another for body weight. I intended to slice by profile (Slice: Unordered, Open by profile:reference.resolve()), but ran into the problem I've just described.
Have others discovered this problem?
Are there widely adopted profiles without this problem?
What is the best way forward?
1/ creating profiles of R3 BodyHeight and BodyWeight which follow the slicing used in R4 BodyHeight with coding, system and code 1..1
2/ slicing on MedicationRequest.supportingInformation by coding (Slice: Unordered, Open by value:reference.resolve().code.coding)
Danielle Tavares (Aug 03 2018 at 00:28):
I think that we should seriously consider deriving new profiles from the STU3 profiles and just tightening up to match with R4.
Lloyd McKenzie (Aug 03 2018 at 00:50):
It's not possible to derive profiles for one version from profiles from another version. The resources aren't compatible and the snapshots for the two versions can't align.
Lloyd McKenzie (Aug 03 2018 at 00:51):
That doesn't mean the profiles won't be retained largely the same. They'll only resolve as necessary to reflect changes to Observation (not sure there's anything relevant) and feedback from implementers (a couple of terminology changes at least).
Richard Townley-O'Neill (Aug 03 2018 at 03:50):
Lloyd, by "follow the slicing used in R4 Body Height" I mean to create a profile on the STU3 BodyHeight profile with Observation.code.coding 1..1 instead of 0..*
Lloyd McKenzie (Aug 03 2018 at 03:59):
Sorry. Didn't read enough of the the thread before responding.
In general we don't make fixes to prior releases. It's difficult for both technical and process reasons
Richard Townley-O'Neill (Aug 03 2018 at 04:08):
Thanks.
Last updated: Apr 12 2022 at 19:14 UTC
