Profile FHIR Resource Proposal
This page documents an Approved FHIR Resource Proposal
Contents
- 1 Profile
- 1.1 Owning committee name
- 1.2 Contributing or Reviewing Work Groups
- 1.3 FHIR Resource Development Project Insight ID
- 1.4 Scope of coverage
- 1.5 RIM scope
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Examples
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
- 1.13 Issues
Profile
Owning committee name
Conformance_and_Guidance_for_Implementation/Testing (temporarily owned by FHIR Core)
Contributing or Reviewing Work Groups
FHIR Resource Development Project Insight ID
Pending
Scope of coverage
Profile is used to define as well as to define constraints upon FHIR capabilities. Specifically, it allows definition and constraint of: resources, data types, extensions, search criteria, messaging events, services, etc. I.e. Any reuseable FHIR element
Profile subsumes the concepts of static messaging profile, template, detailed clinical model (DCM) and a large part of implementation guide.
Profile *excludes* defining combinations of features for a particular usage - that is left to the Conformance resource.
RIM scope
Profile exists outside the scope of the RIM as it deals with metadata rather than data. It does have correspondence with MIF.
Resource appropriateness
Profiles, templates and DCMs are well understood concept in healthcare. While they may have dependencies, they are each maintained separately.
Profile is on the "large" size due to the large number of capabilities that can be defined within FHIR.
Expected implementations
FHIR uses Profile itself in representing resources and defining all extensions. Profiles will also be used creating constraints of resources for in a variety of contexts such as equivalent of CDA templates and implementation guides, national program implementation guides, etc.
Content sources
- HL7 v3 MIF
- HL7 v2 static profile
- HL7 template requirements
- CDA Implemenation guides
- Open EHR templates
- CDISC ODM
Examples
- All resource definitions are represented using Profile
- Profile showing a chemistry lab panel
- Profile showing definition of extensions, events and search criteria supplementing an existing resource
Resource Relationships
- Profile is used by Conformance to describe capabilities around messaging and documents.
- Profiles can import other Profiles
- Profiles reference ValueSet resources defining the constraints on their terminology elements
Timelines
Initial DSTU
gForge Users
N/A
Issues
- Should we split the "static" and "dynamic" aspects of Profile? Do we need a way to define (and allow reference to) services & additional restful operations?
- need more examples/description on the relationship between conformance and profile
