I was asked why MHD has the requirements to contain a provider and patient in document reference. Why is that necessary?
The containment of Provider and Patient are ONLY for very specific reasons. Some are driven by XDS constraints; but even those constraints are driven by reasonable use-cases.
Patient is the easiest to explain: If one doesn't fill out .sourcePatientInfo, then there would be no contained Patient resource. The .subject is expected to be a non-contained Patient reference. It might be in the bundle, but it isn't contained in the DocumentReference. The reason for this is that the use-case for .sourcePatientInfo is to hold what the patient was known as at the time that the DocumentReference was created. Where a non-contained Patient reference is something that is kept up-to-date. So over-time the details pointed to by .subject will drift from the historic. In a pure FHIR environment, with a service that does implement versioning (not a requirement of all servers), one could just pin .sourcePatientInfo at a specific version of a Patient. This might work, or might not. Meaning there is no guarantee that versioning is supported, or that all possible changes will respect the versioning (e.g. Merge). So by using contained, we assure the data stays unchanged. By using contained, we keep the semantics that are found in XDS. This is discussed in section 3.65.4.1.2.2 -- although I assumed the readership knows XDS well.
Practitioner is contained for similar reason, but really the reason is almost completely XDS focused. The MHD Profile indicates that the .author element will hold a Practitioner that is contained. This because Practitioner resource has all the elements that XDS wants in the .author element, so don't give us other types of resources like Organization, Device, Patient, or RelatedPerson. And contain it because in XDS the .author is static in the Registry. In a pure FHIR environment I would not expect containment, as FHIR servers would be more dynamic without loosing use-case functionality. It is marked as required to be contained because in XDS the registry maintains 'the' information it was given and there is no way to change it (except for Metadata Update which is highly experimental). Thus like with .sourcePatientInfo, it is expected to be factual at the time of registration and is not expected to change over-time. The fixing in time factor is not as critical for .author use-cases; and one might argue that use-cases would likely like it to not be fixed in time. However the information in .author is also not likely wrong, and thus not likely helped by revisions.
In both cases these are a bit more of a soft requirement, more to set expectations for the Document Consumer to expect them to be contained rather than to tell them to fail if they don't find them contained. More to tell Document Sources to put them in as Contained so as to make it easier on XDS environments. There is simply not a normative word (SHALL vs SHOULD) that expresses this concept. Although RFC 6919 does have "Shall but we know you won't", or better yet "OUGHT TO".
The containment of Provider and Patient are ONLY for very specific reasons. Some are driven by XDS constraints; but even those constraints are driven by reasonable use-cases.
Patient is the easiest to explain: If one doesn't fill out .sourcePatientInfo, then there would be no contained Patient resource. The .subject is expected to be a non-contained Patient reference. It might be in the bundle, but it isn't contained in the DocumentReference. The reason for this is that the use-case for .sourcePatientInfo is to hold what the patient was known as at the time that the DocumentReference was created. Where a non-contained Patient reference is something that is kept up-to-date. So over-time the details pointed to by .subject will drift from the historic. In a pure FHIR environment, with a service that does implement versioning (not a requirement of all servers), one could just pin .sourcePatientInfo at a specific version of a Patient. This might work, or might not. Meaning there is no guarantee that versioning is supported, or that all possible changes will respect the versioning (e.g. Merge). So by using contained, we assure the data stays unchanged. By using contained, we keep the semantics that are found in XDS. This is discussed in section 3.65.4.1.2.2 -- although I assumed the readership knows XDS well.
Practitioner is contained for similar reason, but really the reason is almost completely XDS focused. The MHD Profile indicates that the .author element will hold a Practitioner that is contained. This because Practitioner resource has all the elements that XDS wants in the .author element, so don't give us other types of resources like Organization, Device, Patient, or RelatedPerson. And contain it because in XDS the .author is static in the Registry. In a pure FHIR environment I would not expect containment, as FHIR servers would be more dynamic without loosing use-case functionality. It is marked as required to be contained because in XDS the registry maintains 'the' information it was given and there is no way to change it (except for Metadata Update which is highly experimental). Thus like with .sourcePatientInfo, it is expected to be factual at the time of registration and is not expected to change over-time. The fixing in time factor is not as critical for .author use-cases; and one might argue that use-cases would likely like it to not be fixed in time. However the information in .author is also not likely wrong, and thus not likely helped by revisions.
In both cases these are a bit more of a soft requirement, more to set expectations for the Document Consumer to expect them to be contained rather than to tell them to fail if they don't find them contained. More to tell Document Sources to put them in as Contained so as to make it easier on XDS environments. There is simply not a normative word (SHALL vs SHOULD) that expresses this concept. Although RFC 6919 does have "Shall but we know you won't", or better yet "OUGHT TO".
mHealth (FHIR)
- MHD in action -- XDS on FHIR
- Guidance on HTTP Access Denied
- Break-Glass on FHIR solution
- FHIR Oauth Scope
- HEART profiles for review, comment, and approval
- Building a MHD Client before MHD is DSTU2 aligned
- IHE updating FHIR Profiles to align with DSTU2
- Break-Glass on FHIR
- FHIR Security initiatives
- How to set the ConfidentialityCode
- FHIR does not need a deidentify=true parameter
- What is MHD beyond XDS-on-FHIR?
- MHD Connectathon Results
- FHIR Security: Do (Not) Worry
- FHIR Full Steam Ahead
- Define Atom -- Too many definitions in use today
- Healthcare access control scope constraints on OAuth tokens
- mHealth Identities using trusted intermediary
- getting to mHealth solutions - real People
- getting to mHealth solutions - Users
- Internet User Authorization: why and where
- Security Considerations: Healthcare RESTful Resource specifications
- Privacy and Security in Designing an mHealth Application
No comments:
Post a Comment