Stream: united states
Topic: US Core
Grahame Grieve (Feb 12 2020 at 12:15):
Hey @Mark Kramer can you provide a list of all the fields in US Core that have a minimum cardinality or must-support that creates problems for your work please?
Mark Kramer (Feb 12 2020 at 15:25):
@Grahame Grieve The only US Core profiles we use in mCODE are US Core Condition, US Core Observation Lab, US Core Diagnostic Report, US Core Patient, and US Core Procedure. On US Core Patient, mCODE doesn't care about these MS elements: communication.language, address.line, .city, .state, .period, contact, race.text. On US Core Diagnostic Report, we don't want to require the user to implement US Core Organization (referenced in DiagnosticReport.performer). The other MS flags are pretty minimal and don't create additional burden on the mCODE user.
Grahame Grieve (Feb 12 2020 at 19:26):
ok thanks.
Grahame Grieve (Feb 12 2020 at 19:28):
specifically, why do you not require US Patient? I understand that mCode mightn't have it's own requirements for those things, but if those are general regulation based requirements, why not have them anyway? is mCode international?
Mark Kramer (Feb 18 2020 at 15:31):
mCODE is US realm, and we do require US Core Patient. However, mCODE for its own purposes doesn't need communication, address, etc (as above). If mCODE had the ability to independently assign its own MS flags, these would not be MS.
Eric Haas (Feb 18 2020 at 20:53):
Why US Core organization a problem. It's name, Identifier, phone and address?
Eric Haas (Feb 18 2020 at 20:55):
And is this pushback from the implementers or from the profilers/modelers perspective?
Grahame Grieve (Feb 18 2020 at 21:06):
If mCODE had the ability to independently assign its own MS flags, these would not be MS.
I'm thinking about that. If US-Core labels something as must-support, and you use it, what would it mean not to make it must-support?
- it seems to me that this implies that US-Core has a divergent use case?
Mark Kramer (Feb 19 2020 at 12:46):
For example, mCODE doesn't need the details of the patient address, aside from the postal code, because of our use case is learning health care system. We aren't trying to contact the patient. US Core seems to assume that the patient is being treated in a health care system. The address information will probably be available, it is not harmful, but I'm only saying we don't need it.
Lloyd McKenzie (Feb 19 2020 at 16:20):
So the cost of inheriting the mustSupport on the other components is that a system that's only being created for the purpose of mCode is being asked to do things that are unnecessary.
Eric Haas (Feb 19 2020 at 22:22):
asked to do things that are unnecessary.
I think you often pay a price up front for supporting a standard.
I'd really like to know if we are making a correct assumption ... are implementers balking because of US Core? Sounds like the burden falls on the mCode Sender or Responder. The Receiver can just ignore whatever it does not care about. One view is these things are unnecessary and a burden but another implementer might already be set up for US Core so benefits from reuse.
Grahame Grieve (Feb 19 2020 at 22:23):
The Reciever can just ignore whatever it does not care about.
But that's exactly what must-support is about.
Eric Haas (Feb 19 2020 at 22:25):
"US Core Requestors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. In other words US Core Requestors SHOULD be capable of displaying the data elements for human use or storing it for other purposes."
Grahame Grieve (Feb 19 2020 at 22:28):
wooah. The "in other words" is actually, not just an alternative set of words - it says something quite different. And the difference is very relevant to this dsicussion
Eric Haas (Feb 19 2020 at 22:33):
Yes 'in other words' reads 'and'.
- don't fail
- you should process it. - Its purposefully ambiguous as to what to do with the data since we anticipated a wide variety of clients and uses
Igor Sirkovich (Feb 19 2020 at 22:46):
We are facing similar issues with the Patient, Practitioner and other admin resources while developing the Canadian Core FHIR profiles. We consider defining 2 Canadian profiles for each of these resource: a relaxed one (with minimal constraints) for systems were these resources are used as supporting information (e.g. prescriber and dispenser in a pharmacy systems) and a constrained one for systems that are used as a source of truth for this information (e.g. Patient or Provider Registry). For example, for a general Practitioner profile, we would define only name and identifier as Must Support where one instance of the identifier has to be an equivalent of NPI, but for the source of truth system (e.g. Provider registry), we would define a bunch of additional Must Support elements as well as required search parameters.
Lloyd McKenzie (Feb 19 2020 at 23:34):
Essentially, the "mustSupport" wording in US core is currently next to meaningless.
Lloyd McKenzie (Feb 19 2020 at 23:34):
"Don't blow up if data is present" is an exceptionally low must support bar.
Lloyd McKenzie (Feb 19 2020 at 23:35):
It doesn't even say you have to accept the instance - rejecting it in a friendly manner would still seem to be conformant.
Eric Haas (Feb 19 2020 at 23:53):
Essentially, the "mustSupport" wording in US core is currently next to meaningless.
for the Receiver is a pretty low bar, no so for the Sender (Responder) 80% of the MustSupport describes the server requirements.
Eric Haas (Feb 19 2020 at 23:54):
Ask any system getting certified
Mark Kramer (Feb 20 2020 at 23:45):
Another thing that's in play here is timing. It is not clear when US systems must certify as US Core compliant (2 years? 3 years?). But systems are implementing mCODE now. Using US Core as a base for mCODE is good citizenship, but also a bit forward-looking for vendors only looking to implement mCODE right NOW.
Last updated: Apr 12 2022 at 19:14 UTC
