Page tree
Skip to end of metadata
Go to start of metadata

Contents

  1. https://jira.hl7.org/browse/FHIR-28375 – Must Support Over Interpreted. 1
  2. https://jira.hl7.org/browse/FHIR-28376 – CareTeam.participant.member Reference Choice. 3
  3. https://jira.hl7.org/browse/FHIR-28378 – DiagnosticReport.performer for Lab Reference Choice. 4
  4. https://jira.hl7.org/browse/FHIR-28379 – DiagnosticReport.performer for Note Reference Choice. 4
  5. https://jira.hl7.org/browse/FHIR-28380 – DocumentReference.author Reference Choice. 5
  6. https://jira.hl7.org/browse/FHIR-28381 – MedicationRequest.reportedReference Reference Choice. 5
  7. https://jira.hl7.org/browse/FHIR-28382 – MedicationRequest.requester Reference Choice. 6
  8. https://jira.hl7.org/browse/FHIR-28383 – Provenance.agent.who Reference Choice. 6
  9. https://jira.hl7.org/browse/FHIR-28384 – Observation.subject in Vital Signs Profile Reference Choice. 7
  10. https://jira.hl7.org/browse/FHIR-28385 – DiagnosticReport.effective[x] for Lab Data Type Choice. 7
  11. https://jira.hl7.org/browse/FHIR-28387 - DiagnosticReport.effective[x] for Note Data Type Choice. 8
  12. https://jira.hl7.org/browse/FHIR-28388 – Immunization.occurrence[x] Data Type Choice. 8
  13. https://jira.hl7.org/browse/FHIR-28389 – Observation.effective[x] for Lab Data Type Choice. 9
  14. https://jira.hl7.org/browse/FHIR-28390 – Observation.value[x] for Lab Data Type Choice. 9
  15. https://jira.hl7.org/browse/FHIR-28391 – Observation.hasMember Vital Signs Panel Profile Reference Choice  10
  16. https://jira.hl7.org/browse/FHIR-28392 – Encounter.serviceProvider Must Support and Encounter.location.location Optional 11
  17. https://jira.hl7.org/browse/FHIR-28393 – DocumentReference.custodian to be Optional 11
  18. https://jira.hl7.org/browse/FHIR-28394 - Observation for Lab Vital Signs Profile. 12
  19. https://jira.hl7.org/browse/FHIR-28395 - MedicationRequest.medication[x] 12
  20. https://jira.hl7.org/browse/FHIR-28396 - Use of US Core Profile when not explicitly referenced when using Contained resources 13

https://jira.hl7.org/browse/FHIR-28375 – Must Support Over Interpreted

We are very concerned that the FHIR US Core R3.1.0/R4 Build Must Support construct remains too ambiguous and not granular enough as it yields interpretations of what is required to support as a communication profile AND adds as new functions/capabilities to the underlying data source/EHR per ONC’s policy declaration that supporting “mandatory” and “must support” elements includes that the underlying EHR supports collection, storage, and management of those elements.  Particularly the latter is not reasonable to require by way of a communication standard to access and exchange available EHI. Specifically, US Core has not sufficiently documented its intent, thus creating  ambiguity, for data types as to whether choices (e.g., references and data types) and data type components are actually all required to be supported, inherited from the Must Support statement on the attribute, or actually have the flexibility that a choice list or the data type definition referenced in the base standard implies.  As we understand, the intent of the Must Support at the attribute level was not to require all elements/components within the data type to be required, but rather that IF the underlying data is available in the underlying systems to make it available without requiring to add such data to the underlying system if that capability just does not exist.  The specific inclusion of certain reference or data type choices and selective profiling of some but not all data type elements and overall absence of documented intent has created the interpretation that everything is Must Support unless otherwise indicated where the reverse was the intent.

This JIRA focuses on the overall definitions of Must Support and ambiguity it introduces, and a proposed update to provide an interim solution until the ambiguity has been fully addressed, and then points to a specific set of JIRAs that have been submitted to address each individual attribute where we identified attributes where reference and data type choices result in data source documentation requirements that are not appropriate at this stage. 

The proposals also consider that FHIR US Core and C-CDA should align on these topics as they represent alternative methods to access the same USCDI data.  I.e., it would not benefit users that USCDI is available through one, but not the other method, or expected to be available through one where it cannot be provided by the data source as that data is not EHI.

The sections referenced are currently published/available in:

The following two Must Support Statements in these published and build versions clearly acknowledge that the data source system may not have certain data and what to do in that situation:

  • In situations where information on a particular data element is not present and the reason for absence is unknown, US Core Responders SHALL NOTinclude the data elements in the resource instance returned as part of the query results.
  • When querying US Core Responders, US Core Requestors SHALLinterpret missing data elements within resource instances as data not present in the US Core Responder’s system.
  • NOTE: The above definition of Must Supportis derived from HL7v2 concept “Required but may be empty - RE” described in HL7v2 V28_CH02B_Conformance.doc.

I.e., in the context of reference and data type choices there should be no expectation either that the data source ever has data that uses either of the reference or data type choices as their system may never document such data.  The sections also further indicate that it aims to model Must Support closely after the HL7 v2 RE construct which is informative to the missing elements in the FHIR US Core guidance.

However, FHIR US Core does not provide clear, unambiguous, complete guidance that extends beyond the attribute level into the data types used.  E.g., in CarePlan.category there is clarity that there be at least one code and system but unclear whether all other components are truly optional or still implied to be Must Support since CarePlan.category is Must Support., And for CareTeam.participant.role and many other attributes that use CodeableConcept, there is no clarity what the minimum set is that is required under the attribute’s Must Support flag as it points to the FHIR R4 base definition for that data type without further clarification on which components are Must Support or not.    It would be unreasonable to expect that ALL CodeableConcept data type components are Must Support.  There are numerous examples like that where there is no explicit indication what components are actually subject to Must Support. For some attributes the data type was clearly profiled, but for most it is not, thus leaving ambiguity what the expectations are, and whether it requires data sources to support it, or that it only indicates whether it should be able to be communicated if present: two different perspectives that are mixed ambiguously.

We note that we have also experienced with HL7 v2 implementation guidance the need to be more specific as guides started to be used for certification and conformance testing.  The lesson learned was that any complex data type component cannot be assumed to be RE based on the RE attribution of the segment/field as  It was necessary to define optionality at every component level in the context of the implementation guide/profile to avoid ambiguity and drive consistency.  Tedious, but necessary to avoid any confusion and ambiguity when it comes to conformance testing and claims.

Recognizing the current ambiguity yet need for that clarity to avoid any confusion, we propose that Must Support guidance be updated with the following additional statement:

  • Must Support SHALL apply to the attribute level only. Unless attribute components are fully decomposed with specific cardinality and Must Support statement on each (sub-)component, or the Description & Constraints specifically indicates that certain components are Must Support, attribute components are considered as optional as the underlying standard allows.

With that statement in place, every Must Support attribute must be updated to fully specify Must Support on the components and choice lists to be explicit and unambiguous.

We must recognize this has not fully occurred to date with limited implementation experience to understand all the implications as more organizations are embarking on fully implementing FHIR US Core and be subject to certification and conformance testing.  This impacts not only how to enable access to EHI/USCDI actually available, but also whether the underlying data source is obligated, or not, to add more documentation capabilities that are otherwise not necessary/relevant for the system at hand.  We have therefore entered the following JIRAs focusing on attributes with the greatest need to make updates accordingly while recognizing more may be needed to get the necessary clarity as we collectively understand the implications and realities that we need to balance.

Related JIRAs: [List]


https://jira.hl7.org/browse/FHIR-28376 – CareTeam.participant.member Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Reference list be limited to US Core Practitioner Profile and all other base standard choices be optional.

The USCDI definition only states that Care Team members are "person(s) who participate or are expected to participate in the care team". Consequently, Organization should be optional rather than Must Support as other resources listed in the base standard.  We also suggest to not include Patient as Must Support. In many systems, Patient is solely the subject of the care and not documented as a participant with a particular role, thus the data source system would not have the ability need to document the patient as part of the care team in a particular role.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the care team in a particular role beyond the subject.  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-careteam.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-careteam.html

https://jira.hl7.org/browse/FHIR-28378 – DiagnosticReport.performer for Lab Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Reference list be limited to US Core Practitioner Profile and all other base standard choices be optional.

A human being is the primary party of interest as the performer.  The data source should not be required to just be able to document an Organization.  Therefore, Organization should remain optional with the other choices allowed by the base standard.  We also note that CLIA required data on medical director and performing lab is communicated be at the Observation level (see HL7 v2 and HL7 C-CDA as well), further reducing the need to require Organization as a Must Support on DiagnosticReport.performer.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the diagnostic report for lab results.  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-diagnosticreport-lab.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-diagnosticreport-lab.html

https://jira.hl7.org/browse/FHIR-28379 – DiagnosticReport.performer for Note Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Reference list be limited to US Core Practitioner Profile and all other base standard choices be optional.

A human being is the primary party of interest as the performer regardless of the organization they are with.  The data source should not be required to just be able to document an Organization.  Therefore, Organization should remain optional with the other choices allowed by the base standard.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the diagnostic report for a note.  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-diagnosticreport-note.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-diagnosticreport-note.html

https://jira.hl7.org/browse/FHIR-28380 – DocumentReference.author Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Reference list be limited to US Core Practitioner Profile and all other base standard choices be optional.

A Practitioner reflects the role who would be creating a note.  Within the current scope of USCDI and the use of FHIR, patients would not actually create clinical documents for themselves (they can contribute data, but a practitioner would be involved in making that part of the record).  If and when patient generated document note writes are required scope, then a Patient would be required.  As write operations are not in scope in the g(10) criterion in the final rule, it should be optional along with other choices allowed by the base standard.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the document reference.  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-documentreference.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-documentreference.html

https://jira.hl7.org/browse/FHIR-28381 – MedicationRequest.reportedReference Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the data type list be limited to Boolean and all other base standard choices be optional.

Current systems would at least know whether it was reported, but not necessarily also who reported it.  We also note that for FHIR R5 the field is planned to be split to enable capture of both rather just one, where the reportedReference becomes .informationSource (see https://jira.hl7.org/browse/FHIR-19640).

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the medication request.  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-medicationrequest.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-medicationrequest.html

https://jira.hl7.org/browse/FHIR-28382 – MedicationRequest.requester Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Reference list be limited to US Core Practitioner Profile and all other base standard choices be optional.

For legal prescriptions that are not reported, a Practitioner must be the actual requester of a medication request. For reported and other requests where there is no legal authorization there is not enough trusted context to require documentation of the requester, thus should not have it as Must Support for those cases as that may yield forced documentation of unverified data, although  the other choices are reasonable without being required to be Must Support.  Further, an Organization as a requester would be illogical in most scenarios as a human practitioner makes the request. Both US Core Organization and US Core Patient should be removed as Must Support and left as optional for systems that support those edge cases. 

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the medication request.  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-medicationrequest.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-medicationrequest.html

https://jira.hl7.org/browse/FHIR-28383 – Provenance.agent.who Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Reference list be limited to US Core Practitioner Profile and all other base standard choices be optional.

Including the US Core Patient Profile implies we must support patient stated provenance, and that is not in scope of USCDI. Further, given our current understanding of the provenance requirement (send the last person to touch the data regardless of role, etc.) a patient could never be that, even if they contributed data to the chart, it would always need to go through review/approval by a clinical user to actually become part of the record as API  writes, including patients using API writes to contribute/update data directly, are out of scope of the g(10) criterion in the final rule.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the provenance.  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-provenance.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-provenance.html

https://jira.hl7.org/browse/FHIR-28384 – Observation.subject in Vital Signs Profile Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Reference list be limited to US Core Patient Profile rather than having it covered under the general “should” statement to use US Core profiles, while also indicating that Device, Location and Group are not supported as other choices.

For purposes of vital signs, the observation subject never can be device, location, or group, rather always is a patient.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a device, location and group as part of the vital signs observation subject.  Additionally, C-CDA does not impose this requirement either.

While this JIRA is posted to US Core/Cross-Project Workgroup, we strongly urge the project to work with the Orders & Observations workgroup and FMG to resolve how to ease the restrictions put in the base profile to accommodate US Core requirements.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/index.html

https://build.fhir.org/ig/HL7/US-Core-R4/index.html

http://hl7.org/fhir/R4/observation-vitalsigns.html

https://jira.hl7.org/browse/FHIR-28385 – DiagnosticReport.effective[x] for Lab Data Type Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the attribute definition be reverted back to the underlying FHIR R4 definition and that this attribute not be marked as Must Support.

We note that the definition of DiagnosticReport.effective[x] substantially changed compared to the FHIR R4 base definition.  We believe this to be an error which has led to attempting to use this attribute for a purpose that is already supported by .issued.  

As the field effectively represents the earliest and latest date of content referenced within DiagnosticReport that is should not be Must Support as that information can be fully derived from its content.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to enable Period as part of DiagnosticReport.effective[x].  Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-diagnosticreport-lab.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-diagnosticreport-lab.html

https://jira.hl7.org/browse/FHIR-28387 - DiagnosticReport.effective[x] for Note Data Type Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the attribute definition be reverted back to the underlying FHIR R4 definition and that this attribute not be marked as Must Support.

We note that the definition of DiagnosticReport.effective[x] substantially changed compared to the FHIR R4 base definition.  We believe this to be an error which has led to attempting to use this attribute for a purpose that is already supported by .issued. 

As the field effectively represents the earliest and latest date of content referenced within DiagnosticReport that is should not be Must Support as that information can be fully derived from its content.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to enable Period as part of bDiagnosticReport.effective[x]. Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-diagnosticreport-note.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-diagnosticreport-note.html

Watchers: Hans Buitendijk, Drew Torres, Michelle Miller, Kathy Pickering, Kevin Power, Doug Pratt

https://jira.hl7.org/browse/FHIR-28388 – Immunization.occurrence[x] Data Type Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Data Type list be limited to dateTime while also indicating that string is an optional choice.

Considering current systems in place, it is unreasonable to require systems that already provide structured data support for dateTime to also now have to step back and support a string instead.  In fact, doing so would violate immunization reporting standards to public health that already require structured datetime format  In those use cases, fuzzy dates where only part of the datetime is known are already addressed  by the dateTime data type String should be optional for systems that need it, but not a hard requirement to support if unnecessary.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to enable Period as part of Immunization.occurrence[x]. Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-immunization.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-immunization.html

https://jira.hl7.org/browse/FHIR-28389 – Observation.effective[x] for Lab Data Type Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Data Type list be limited to dateTime while also indicating that Period is an optional choice.

Laboratory observations are measurements and simple assertions which, by nature, are at a point in time and not periods.  If there is interest in a period, e.g., how long a culture was incubated before measuring, that would not be captured in .effective.  While the description states that this reflects the specimen collection date/time, as that is for lab tests the physiologically relevant date/time, if specimen collection took some time then that period would be the specimen collection date time in Specimen.collection.collected[x] where a Period is available.  Observation.effective would use a reasonable point in time reflecting that collection.  Note that also in HL7 v2, which typically would transmit the source data to the EHR, there is no support for Period for an effective date/time of the observation (OBX-14). 

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to enable Period as part of Observation.effective[x]. Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-observation-lab.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-observation-lab.html

https://jira.hl7.org/browse/FHIR-28390 – Observation.value[x] for Lab Data Type Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the intent is for any data type from the base standard to be valid, but that the Query Responder only needs to support those data types and their components where it actually manages and maintains data in the data type format.  We also propose that the intent is clarified that if there is no binding for the data at hand when using CodeableConcept then only .text is required.  

The intent was not to require underlying systems to add new functionality to manage additional data formats they currently do not support, rather to make the data they do have available using the appropriate data type that FHIR has available to express that.  For example, Integer is a Quantity without a unit.  Labs don’t result a ratio or a range in a separate low/high field.  Those would likely be a CodeableConcept or a string.  Booleans would likely be expressed as CodeableConcept.  Laboratories that outsource their testing will not be able to meet all the date type requirements, because interfaced tests are usually configured as a string only. 

EHRs typically do not save and forward (via API or other means) raw, unvalidated sampled data (SampledData), e.g., for ECG. Rather, a clinician first validates the data within specialized systems, upon which time it is appropriate to make available via API based on an EHR while a specialized system may have the need to expose the sampled data.  Consequently, it is more likely that EHRs would connect to other systems to enable accessing/viewing such data using dedicated viewers/capabilities provided by other specialized systems.  Therefore, while some specialized systems may have use for this, others such as EHRs should not be encumbered to support that data type as well.

Other non-Lab data may have a need for SampledData, but those are out of scope, e.g., EKG, and not every system would necessarily need to manage the raw data as per above

The Period data type is not relevant for lab results as there are no known lab results that have a value of a date range.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to enable SampledData and Period as part of Observation.value[x]. Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-observation-lab.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-observation-lab.html

https://jira.hl7.org/browse/FHIR-28391 – Observation.hasMember Vital Signs Panel Profile Reference Choice

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the Data Type list be limited to Observation while also indicating that MolecularSequence and QuestionnaireReponse are not supported.

MolecularSequence is not an appropriate choice for vital signs as vital signs are not biological sequences, and would not be members of a vital sign or vital sign panel. 

QuestionnaireResponse is not appropriate either for capturing individual vital signs as that is done by way of observations.  The Observation resource is used primarily for capturing data elements that are "true" observations - lab measurements, vital signs and allows for easy inclusion of reference ranges and interpretations.

The Vital Signs is in STU status without clear Must Support guidance, thus too immature to include fully as a Must Support in its current state.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the provenance.  Additionally, C-CDA does not impose this requirement either.

While this JIRA is posted to US Core/Cross-Project Workgroup, we strongly urge the project to work with the Orders & Observations workgroup and FMG to resolve how to ease the restrictions put in the base profile to accommodate US Core requirements.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/index.html

https://build.fhir.org/ig/HL7/US-Core-R4/index.html

http://hl7.org/fhir/R4/observation-vitalsigns.html

https://jira.hl7.org/browse/FHIR-28392 – Encounter.serviceProvider Must Support and Encounter.location.location Optional

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that service provider is the better attribute to be Must Support rather than location. 

We note that the service provider is more important.  There is a bigger need to obtain the organization responsible, which is the .serviceProvider. We recognize that for home visits the home location would be relevant, but not every system documents home or school visits while the serviceProvider would be clear and relevant.  If we only have location for those visits, as .location.managingOrganization would be irrelevant, we do not know who is responsible and can be contacted as needed.  Knowing who is responsible is more critical, hence .serviceProvider should be Must Support, and use US Core Organization Profile as the reference, while .location should be optional.

Links to pages:

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-encounter.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-encounter.html

https://jira.hl7.org/browse/FHIR-28393 – DocumentReference.custodian to be Optional

We propose that the DocumentReference.custodian is marked optional rather than Must support.  This information can be obtained from the encounter so requiring it here is redundant; also structured documents may also contain it within the document.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the provenance.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-condition.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-documentreference.html

https://jira.hl7.org/browse/FHIR-28394 - Observation for Lab Vital Signs Profile

In context of https://jira.hl7.org/browse/FHIR-28375 we propose to clarify that the Vital Signs sub-profiles do not need to all be supported.  Particularly we suggest that the Vital Signs Panel is not required, while others would be fine.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the provenance.

While this JIRA is posted to US Core/Cross-Project Workgroup, we strongly urge the project to work with the Orders & Observations workgroup and FMG to resolve how to ease the restrictions put in the base profile to accommodate US Core requirements.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/index.html

https://build.fhir.org/ig/HL7/US-Core-R4/index.html

http://hl7.org/fhir/R4/observation-vitalsigns.html

https://jira.hl7.org/browse/FHIR-28395 - MedicationRequest.medication[x]

In context of https://jira.hl7.org/browse/FHIR-28375 we propose that MedicationRequest.medication[x] does not require both the .medicationCodeableConcept and .medicationReference.

We note that the current construct where within .medicationReference only the .code is required thus effectively being the same as medicationCodeableConcept, while also systems only need to convey the code without the other details. A system that only maintains the medication code (RxNorm) would be required, under current requirements, to “support” both options for sending the exact same information. Therefore, .medication as a reference should be optional and available for use in systems that store and need to convey the additional, optional information (as per US Core) that comes into play with compounded medications.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to capture a patient as part of the provenance.

Links to pages:

http://hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-medicationrequest.html

https://jira.hl7.org/browse/FHIR-28396 - Use of US Core Profile when not explicitly referenced when using Contained resources

In context of FHIR-28375 - Getting issue details... STATUS we propose that it be made more clear that (1) “contains” are free to be used for any reference within a US Core Profile as desired since the IG does not dictate when they may or may not be leveraged, and (2) that when a developer elects to leverage a contain, the US Core Profile conformance is technically optional

  • No labels