hl7 / us-core Goto Github PK

review summary narrative to make sure they align with the structural changes in R4

consider referencing VSAC for race and ethnicity too

check that vitals references link to fhir core in R3

http://build.fhir.org/ig/HL7/US-Core-R4/clinical-notes-guidance.html includes important guidance for working with clinical notes. http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-diagnosticreport-note.html and http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-documentreference.html should mention and link to this page in their introductory text.

https://build.fhir.org/ig/HL7/US-Core-R4/clinical-notes-guidance.html#using-expand isn't linked to from the profiles, and it's unclear whether servers are required to support $expand. (And if so, on all context values, or just on a few specific ones?)

Without $expand, a client has no way to query for all DiagnosticReport resources, since GET /DiagnosticReport?patient=[] is not defined (the only query requires a patient and a code, and a client has no way to know/guess all possible codes that a server might be using, without $expand). Even with $expand it's not clear whether this operation would be required to return all codes used across all DiagnosticReports available across all Patient records, or just a kind of "preferred" list (in which case, again clients would have no way to locate all DiagnosticReports).

add capabilties for Clinical Notes or make separate one

Multiple pages state:

The following search parameters, search parameter combinations and search parameter modifiers, comparators, chains and composites SHALL be supported. the modifiers, comparators, chains and composites that are listed as optional SHOULD be supported.

At the very least, . the should be . The. But even with that tweak, I'm not sure what's intended; the text seems to state SHALL and then SHOULD in rapid succession, and in many cases I don't even see any modifiers, comparators, chains or composites in the examples themselves. The boilerplate language is unclear.

See how works for allergy codes.

https://build.fhir.org/ig/HL7/US-Core-R4/general-guidance.html#syntax-for-searches-limited-by-patient has incorrect capitalization on some of the examples ("Subject" instead of "subject") and is missing ?patient=Patient/[id].

Apply US Core R3 update from #14492

consider referencing VSAC for race and ethnicity too see how works for allergy codes.

Problem: This project uses a project structure that will no longer be supported by SUSHI, as of SUSHI 2.0.0. If your project uses the HL7 IG Autobuild, auto builds will fail after SUSHI 2.0.0 comes out of beta.

Preferred Solution: The preferred way to fix this problem is to update your project to use the supported project structure and configuration (e.g., standard IG template project structure with an input/fsh folder). We suggest following the Migrating from Older Versions instructions on FSH School.

Alternate Solution: If it is not feasible to make these changes in a timely manner, you can "lock in" the version of SUSHI that the IG Publisher uses by creating or updating a fsh.ini file at the root of your project. For example, the following fsh.ini file would tell the IG Publisher to always use SUSHI 1.3.2, even after SUSHI 2.0.0 is released:

[FSH]
sushi-version=1.3.2

Timeline: In order to avoid being affected by the official SUSHI 2.0.0 release, we recommend you implement one of the above solutions by July 6, 2021.

More Information / Questions: For more information about SUSHI 2.0, you can read the
SUSHI 2.0.0 Beta 1 Release Notes. For more information about updating your project to the supported project structure, see Migrating from Older Versions on FSH School. If you have questions, you can reach out to the SUSHI team via the #shorthand stream on Zulip or by logging an issue on SUSHI.

http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-diagnosticreport-lab.html#mandatory-search-parameters uses an example with a specific category (LAB). Is this the only category for which a server needs to support search? If so, should add this to the header that currently just says ("SHALL support searching using the combination of the patient and category search parameters")

(And... what should a server do if another category is supplied by the client?)

It looks like some attribute extensions mimic CodableConcept types. For example, ombCategory and detailed in us-core-race are modeled as containing a string and a Coding. The CodeableConcept data type has a string element and a list of Codings. Is there a reason why these extensions aren't modeled using CodableConcept or is it purely historical? If historical, is there a plan to migrate them to use CodableConcepts? If there was a reason for specifically not using CodeableConcept, is there some documentation of that decision we'd be able to reference?

There are several issues for clients looking to fetch all DiagnosticReports on a patient (see #21). The simplest and most robust fix would be to add a required query like GET /DiagnosticReport?patient=[id].

http://build.fhir.org/ig/HL7/US-Core-R4/clinical-notes-guidance.html says:

Specifically, this implementation guide defines the exchange of the following five “Common Clinical Notes”.

Consultation Note (11488-4)
Discharge Summary (18842-5)
History & Physical Note (34117-2)
Procedures Note (28570-0)
Progress Note (11506-3)

and SHOULD support the DiagnosticReport categories:

Cardiology (LP29708-2)
Pathology (LP7839-6)
Radiology (LP29684-5)

Is "and SHOULD support" supposed to be saying something about "this implementation guide", or about servers (or clients) implementing the guide? I'm confused; looks like maybe some copy/paste editing.

Hi @brettmarquard noticed this when looking for information on Data Absent Reason. Happy to make a pull request if you'd like.

from US-Core-R4/source/pages/general-guidance.md:

{
  "resourceType" : "Patient",
       ...
       "name":[
         "extension" : [
         "url" : "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
         "valueCode" : "unknown"
          }]
          ]
        "telecom" :
        ...
     }

The actutal data absent reason extension above is invalid JSON. it should be:

{
  "resourceType" : "Patient",
  ...
  "name":[{
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
      "valueCode" : "unknown"
    }]
  }]
  "telecom" :
  ...
}

updates to Cap statement make it unecessary in R4

Update https://build.fhir.org/ig/HL7/US-Core-R4/general-guidance.html#missing-data to read "the data element is omitted from the resource as described above."

Apply US Core R3 update from #144503

Did we ever land the discussion about MedicationStatement vs MedicationRequest? It seemed for a while like we'd have guidance to just focus on one (MedicationRequest, if I understood correctly). Currently I'm not seeing any high-level guidance at http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-medicationstatement.html or http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-medicationrequest.html (or on the general guidance page). I might just be missing the guidance if present (in which case, let's link to it from the profile pages I mentioned above) -- or perhaps there is no agreement sufficient for us to offer guidance?

http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-documentreference.html#mandatory-write-capability has some stray characters:

see US Core -R3

#27

#17